Conteúdo


A arquitetura de referência de integração híbrida em desenvolvimento

Como garantir que seu cenário de integração acompanhe a transformação digital

Comments

Ao longo do tempo, a complexidade da integração aumenta inevitavelmente. Essa complexidade é resultado de uma maior diversidade de recursos que precisam ser integrados, em permutações cada vez maiores de infraestruturas e plataformas. Além disso, as pessoas envolvidas em sistemas de integração não estão mais centralizadas em uma única equipe técnica, elas estão espalhadas em torno da empresa e além de seus limites.

Paralelamente e, em parte, como resultado desse aumento de complexidade, a motivação para vencer a concorrência busca simplificar e racionalizar a integração. As APIs da web amadureceram, tornando-se uma plataforma comum e uma maneira agnóstica de linguagem para a comunicação de aplicativos. A infraestrutura está cada vez mais virtualizada e conteinerizada para liberar os tempos de execução das especificações de hardware e de sistema operacional, permitindo uma orquestração elástica da carga de trabalho. As equipes estão aprendendo a reunir o pessoal de desenvolvimento e de operações de forma mais eficiente e a automatizar desde o desenvolvimento até a implementação, acelerando os ciclos de release.

Os desafios são realmente híbridos em vários sentidos. Locais, equipes, métodos, plataformas e outros itens estão cada vez mais diversificados. A arquitetura da integração nesse ambiente híbrido está se desenvolvendo em um ritmo acelerado.

Este artigo explora como a integração híbrida tem se desenvolvido. Primeiro, examinamos como o escopo da integração foi alterado com a movimentação para a nuvem. Em seguida, definimos as características de alto nível de um recurso de integração híbrida. Em seguida, explicamos como a TI não é considerada uma função central na organização. Continuamos analisando os princípios básicos de uma arquitetura de integração híbrida e como a integração pode ser transformada em produto por meio da economia de API. Finalmente, destacamos como é possível reconhecer e satisfazer às necessidades da equipe digital e melhorar a consistência em todo o ambiente híbrido.

A ampla área de cobertura da integração híbrida

Atualmente, os limites de propriedade de uma empresa estão espalhados muito além de suas paredes, abrangendo ativos de TI em um ambiente verdadeiramente híbrido. Nessa arquitetura, os aplicativos existentes são movidos para a infraestrutura como serviço (IaaS) de provedores em nuvem. Os novos aplicativos geralmente são desenvolvidos na nuvem como plataforma como serviço (PaaS). Alinhado a essa tendência, também está ocorrendo um aumento no uso de software como serviço (SaaS) pré-montado, baseado em nuvem.

Além disso, a interação com partes externas, como clientes ou parceiros comerciais, está cada vez mais automatizada. O grau de automação com essas partes externas geralmente é um diferenciador comercial.

Extended surface area of hybrid integration
Extended surface area of hybrid integration

Dessa forma, qualquer recurso de integração precisa lidar com a conectividade entre os limites da nuvem. Esse recurso também precisa simplificar os problemas de segurança e gerenciamento que gera e adotar as normas que estão surgindo dentro das arquiteturas híbridas.

Geralmente, a integração híbrida é definida de uma maneira simplificada como a capacidade de integrar sistemas locais com sistemas em nuvem. A realidade para a maioria das organizações tem dimensões muito mais amplas. Uma verdadeira integração híbrida considera a integração entre todos os ambientes de propriedade, abrangendo ambientes locais e em nuvem, e se a nuvem é local, dedicada ou pública. Ela também abrange um ambiente autodesenvolvido para plataformas de SaaS. Além disso, ela também precisa considerar como a empresa se conecta com seus parceiros e clientes. A integração híbrida tem um escopo amplo. O principal desafio é como interpretar essa complexidade e encontrar padrões arquiteturais comuns dentro dela que ajudem a simplificar o problema.

Principais recursos da integração híbrida

Em linhas gerais, a integração híbrida é uma estrutura de integração abrangente. Ela vincula perfeitamente todos os ambientes de propriedade, como origens de dados diretas, aplicativos ou APIs, que podem se conectar a eles onde quer que estejam: no local ou em IaaS, PaaS ou SaaS.

Capabilities and scope of hybrid integration
Capabilities and scope of hybrid integration

A integração híbrida precisa conter amplos recursos de conectividade para aplicativos modernos baseados em nuvem e para sistemas de registro (SOR) igualmente importantes, porém mais antigos. Ela precisa contar com ferramentas para simplificar e acelerar a produtividade, como mapeamento e transformação rápidos e flexíveis. De uma perspectiva não funcional, ela também precisa fornecer escalabilidade, segurança e resiliência em nível corporativo e no nível da Internet.

No entanto, embora seja importante definir a integração híbrida como um todo, é necessário considerar de que forma as necessidades de integração estão mudando e reconhecer os dois públicos diferentes que estão envolvidos.

Adoção de TI pela linha de negócios

Há alguns anos, principalmente acelerada pela revolução da mobilidade, a TI centralizada tem divergido em dois campos diferentes: geralmente chamados de TI corporativa e TI digital.

A TI corporativa mantém sua função vital de garantir que os sistemas essenciais para os negócios mantenham seus níveis de serviço e forneçam o tipo de controle de integridade e segurança de dados esperado para os sistemas principais dos quais os negócios dependem. No entanto, esse ambiente fortemente controlado e regulado não atende às necessidades das linhas de negócios (LOBs) que precisam manter a face pública da empresa sempre nova, com novas propostas e inovações, em um mercado que se transforma rapidamente.

As LOBs têm um grande foco em requisitos, como os exemplos a seguir:

  • Agilidade. As LOBs precisam explorar e adaptar, fazendo rápidas iterações em seus protótipos e, quando necessário, falhando rapidamente e passando para a próxima ideia. Essa abordagem implica o uso de diferentes técnicas para desenvolver aplicativos mais baseados em componentes, como uma arquitetura de microsserviços. Isso também significa aumentar o foco em uma cultura de DevOps, na qual a distância entre as mudanças de implementação e a entrega da produção é minimizada.
  • Escalabilidade. Quando um protótipo é lançado, as LOBs precisam ter a capacidade de ajustar sua escala de forma elástica, passando o protótipo dos usuários patrocinados para o mercado aberto, sem precisar de mais esforços significativos de desenvolvimento. As LOBs precisam ter a capacidade de ajustar a escala da infraestrutura, usando um modelo de custo simples e previsível, envolvendo o uso de IaaS ou PaaS e adotando uma arquitetura de aplicativo inerentemente escalável.
  • Latência. As LOBs também podem ter diferentes necessidades com relação à capacidade de resposta em tempo real dos aplicativos que fornecem. A latência necessária para criar uma experiência mobile envolvente pode ser significativamente menor do que a latência fornecida pelos sistemas de registro existentes. A latência pode exigir o uso de dados pré-agregados ou armazenados em cache e um design direcionado pelos problemas desafiadores de duplicação de dados e consistência eventual. Ela também pode exigir um gerenciamento de tráfego adequado para priorizar cargas de trabalho.
  • Disponibilidade. A reputação de negócios que operam principalmente on-line pode ser prejudicada de forma irreversível até mesmo por um período mínimo de tempo de inatividade em um momento errado. A disponibilidade comprovada é um diferenciador. As LOBs precisam de aplicativos projetados para alta disponibilidade contínua. Esses aplicativos geralmente requerem abordagens diferentes da resiliência do que as abordagens mais comuns para aplicativos corporativos internos.

Considerando esses requisitos, é possível observar como os departamentos de Shadow IT surgiram dentro das LOBs e agora estão assumindo novos projetos significativos, usando técnicas diferentes das usadas pelo departamento de TI central. Esses departamentos de TI de LOB estão rapidamente ganhando mais visibilidade e reconhecimento como a equipe de TI digital, responsável por criar a próxima geração de aplicativos. Essa equipe geralmente tem culturas e focos diferentes, recrutando pessoas com mentalidade de negócios e qualificações técnicas em vez de especialistas puramente técnicos. Portanto, o foco da equipe é ganhar renda e participação no mercado usando inovações rápidas. No entanto, os aplicativos que esses indivíduos estão criando representam a face pública da empresa. Portanto, eles também requerem uma estrutura técnica sólida para satisfazer os principais requisitos não funcionais.

Tanto as equipes de TI corporativa quanto as de TI digital têm necessidades de integração. Elas precisam de integração dentro de seus próprios domínios e entre si. Em linhas gerais, esses recursos de integração híbrida parecem similares, como em relação à conectividade, transformação, exposição de API e composição. No entanto, seus detalhes diferem radicalmente.

Conectando a divisão bimodal

Em uma arquitetura de referência simplista para integração, como o exemplo mostrado no diagrama a seguir, uma equipe de TI central pode executar a maior parte da integração. A equipe basicamente conecta a divisão bimodal, conferindo poderes às equipes digitais. Ela executa a integração profunda necessária para aflorar os sistemas de registro, como APIs e eventos, no gateway de API central.

Integrating across bi-modal IT
Integrating across bi-modal IT

Outro aspecto importante, mas sutil, do diagrama é a afinidade de nuvem. Esse conceito representa deliberadamente um contínuo em vez de uma linha divisória na arquitetura. Como foi explicado sobre a área de cobertura da integração híbrida, qualquer parte da arquitetura pode ser local ou totalmente baseada em nuvem. Os componentes próximos da parte inferior do diagrama, como sistemas de registro, têm uma probabilidade maior de serem locais, mas um novo sistema de registro pode ser implementado em uma infraestrutura em nuvem ou até mesmo ser um SaaS. Da mesma forma, os componentes próximos à parte superior do diagrama têm uma probabilidade maior de serem baseados em nuvem, mas inúmeras organizações ainda hospedam seus próprios aplicativos de sistema de engajamento. A realidade de qualquer organização é uma combinação de componentes locais e remotos, portanto, toda arquitetura de integração híbrida precisa ativar a conectividade.

Para essa integração principal da empresa, os requisitos são amplos e conhecidos, apresentando as maiores preocupações:

  • Conectividade de nível baixo entre uma ampla variedade de formatos de dados, transportes e protocolos para assegurar o engajamento com quaisquer sistemas de registro que a empresa possa ter no momento ou adquirir, independentemente da idade ou da diversidade da plataforma.
  • Integridade de dados, usando transações para assegurar que os sistemas de registro permaneçam em um estado consistente.
  • Exposição de API ou serviço técnico para um público limitado de outros aplicativos que estão predominantemente dentro da organização (incluindo origens de dados da TI digital), usando técnicas mais modernas, como APIs RESTful e serviços da web.
  • Recursos de sistema de mensagens corporativo para fornecer uma entrega garantida dos dados essenciais para os negócios entre sistemas, em uma enorme variedade de plataformas.

Ainda neste artigo, esses requisitos serão comparados com os requisitos da TI digital, mas primeiro vamos considerar como eles se relacionam às iniciativas de integração típicas, como a arquitetura orientada a serviços (SOA).

Alguns podem considerar o diagrama de integração bimodal semelhante à SOA, mas com protocolos mais modernos para exposição de serviço ou de API. Na verdade, a evolução da SOA inicial é mais nítida. A sofisticação e o propósito do gateway amadureceram significativamente. Os gateways de API modernos têm uma experiência mais focada no consumidor. Eles fornecem ao desenvolvedor portais para procurar e assinar APIs, analytics sobre o uso de API e modelos de segurança e gerenciamento de tráfego modernos para proteger e controlar o acesso às APIs.

Exposição de API pública

A evolução da complexidade dos mecanismos de fornecimento de APIs tem levado as empresas a explorarem a exposição pública das APIs e a participarem da economia de API. Do ponto de vista da arquitetura, é possível reconhecer essa exposição por um segundo gateway (superior) na arquitetura, como é mostrado no diagrama a seguir. Esta seção analisa de que forma e por qual motivo o gateway público se difere do gateway interno.

Apesar de mostrarmos dois gateways separados nesta arquitetura de referência lógica para enfatizar os dois estilos de exposição, esses gateways podem ser fornecidos pelo mesmo gateway físico em alguns cenários.

Challenges of public API exposure
Challenges of public API exposure

O conceito de sistemas de engajamento geralmente refere-se a aplicativos voltados ao usuário, como aplicativos mobile e aplicativos da web com uma única página. Esses aplicativos atendem a canais digitais modernos por meio de interfaces com o usuário responsivas e de alta tração, que geram novas oportunidades de renda para os negócios. No entanto, cada vez mais é possível introduzir um novo canal de negócios no formato de APIs publicamente acessíveis. Essas APIs são desenvolvidas com os desenvolvedores externos em mente, buscando acelerar a inovação por meio de crowdsourcing para novos modelos de negócios. Embora sejam tecnicamente semelhantes às APIs internas, as APIs públicas são radicalmente diferentes em relação a como, onde, por que e por quem são criadas:

  • Como. As APIs públicas são desenvolvidas e evoluem rapidamente, conforme as tendências do mercado se alteram. Portanto, geralmente elas são desenvolvidas em uma infraestrutura leve e com paradigmas de design, como microsserviços, permitindo mais agilidade e, no caso de sucesso, escalabilidade elástica instantânea.
  • Por quê? É mais correto considerar as APIs públicas como produtos à venda dentro da economia de API, usando vários modelos de financiamento. Geralmente elas são designadas a nichos de consumidores em vez de serem consideradas interfaces genéricas completas e abrangentes.
  • Quem. As APIs públicas geralmente são criadas e mantidas por uma equipe de TI digital separada, mais focada nos negócios ou no mercado, especializada em arquiteturas leves.
  • Onde. As APIs públicas têm uma probabilidade maior de serem desenvolvidas e implementadas na nuvem, usufruindo da rapidez da configuração inicial em novos ambientes e de modelos lineares de custo para ajuste de escala elástico.

Para permitir tecnicamente a exposição de APIs públicas, são necessários recursos mais abrangentes dentro e fora do gateway. Por exemplo, as APIs públicas têm um gerenciamento de tráfego baseado em assinatura mais avançado e robusto. Elas podem contar com portais digitais que os desenvolvedores podem usar para descobrir e assinar APIs. Elas também podem contar com modelos de segurança da Internet (como o OAuth), proteção mais forte contra ameaças, analytics mais focadas no mercado e um mecanismo direto de feedback do desenvolvedor, como fóruns de suporte da comunidade.

Necessidades de integração na TI digital

Para que as equipes de TI digital forneçam APIs novas, envolventes e coerentes, elas precisam fazer mais do que simplesmente reexpor as APIs internas. Elas precisam editar as APIs existentes dentro e fora da empresa para fornecer recursos que possam atender com precisão aos novos canais do mercado. Elas têm um foco muito menor nos problemas de integração de nível baixo relacionados à complexidade de protocolos e à diversidade de plataformas com as quais a TI corporativa lida. Os aplicativos e as APIs que essas equipes criam comunicam-se principalmente usando protocolos de popularidade mais recentes, como o REST (geralmente JSON/HTTP) com pouca dificuldade de integração. Portanto, as equipes podem aumentar o foco na expansão das funcionalidades.

Um aplicativo mobile moderno atende a um grande número de usuários ativos simultâneos, cada um demandando um tempo de resposta de subsegundo. Essa demanda gera a necessidade de aproximar os dados dos limites da empresa, em vez de recuperá-los no tempo de execução de sistemas de registro que não são projetados visando a baixa latência e a escalabilidade massiva do mercado. O resultado é a necessidade de padrões de movimentação de dados, armazenamento em cache e padrões de persistência possivelmente mais complexos, como a consistência eventual.

Geralmente, as equipes digitais usam a comunicação assíncrona e leve internamente para reduzir as dependências diretas e aumentar a resiliência e a escalabilidade. Elas também buscam métodos mais assíncronos externamente, por exemplo, usando um modelo de push versus pull para aplicativos móveis. As equipes digitais geralmente optam pela arquitetura de microsserviços, que ajuda a levar esses padrões de tecnologia para a linha de frente, com o objetivo de melhorar a agilidade, a escalabilidade e a resiliência. Os microsserviços e seus relacionamentos com a integração são muito complexos para serem descritos neste artigo. Para obter uma explicação mais detalhada, consulte Microsserviços, SOA e APIs: amigos ou inimigos?.

Com base na figura a seguir, analisando mais a fundo as necessidades de integração das equipes digitais, vemos uma necessidade de algo a mais do que apenas um gateway para expor suas APIs. Embora esses novos aplicativos e essas novas APIs possam ser criados usando tempos de execução de linguagem bruta, muitos dos desafios de composição são padrões de integração conhecidos, como mapeamento e enriquecimento. Portanto, é interessante usar ferramentas e estruturas simples para acelerar a implementação dessas APIs.

Adding the integration requirements of the digital                     team
Adding the integration requirements of the digital team

Além do gateway externo para APIs, as equipes digitais também têm as seguintes necessidades de integração:

  • Composição de API para permitir a criação de APIs mais sofisticadas, agregando e editando chamadas de APIs existentes, dentro e fora da empresa.
  • Descoberta de API e evento, principalmente para descobrir e consumir os recursos que são expostos pela TI corporativa, da maneira mais simples possível, independentemente dos limites da nuvem.
  • Gerenciamento de parceiro dependente para gerenciar os relacionamentos com dependências externas, lidar com assinaturas, conexões, certificados e credenciais, além de gerenciar e monitorar o uso de maneira apropriada.
  • Sistema de mensagens leve e centrado em aplicativo dentro dos ambientes de aplicativo, com recursos centrados na Internet, como escalabilidade elástica, baixa latência, alta capacidade do assinante, mas também de maneira mais crítica, com a capacidade de conexão com o ambiente do sistema de mensagens corporativo.
  • PaaS de integração para produtividade das equipes digitais. O ideal dessas equipes é eliminar a tarefa de construir uma plataforma. Elas preferem usar uma plataforma existente desde o início e focar na função de seus aplicativos e de suas APIs.

Buscando consistência com flexibilidade

Uma arquitetura de integração híbrida deve permitir uma integração sem atritos em toda a empresa, com as seguintes qualidades:

  • Consistente e simples. Integração consistente entre limites de aplicativos que use somente os elementos de integração necessários em cada contexto
  • Reconhecimento de híbrido. Recursos de integração onde quer que os aplicativos estejam, no local, na infraestrutura baseada em nuvem ou em uma plataforma
  • Agilidade em escala. Agilidade e produtividade, com a flexibilidade necessária para crescer em nível corporativo e na escala da Internet

O conceito de integração pode parecer semelhante para todos os caso, embora as necessidades específicas de cada um possam variar. Para atender a essas demandas simultâneas, deve-se buscar maneiras de simplificar o problema.

Como exemplo, uma maneira comum de alcançar a consistência em uma arquitetura é procurar padrões que se repetem e usá-los para simplificar a arquitetura. Na arquitetura apresentada neste artigo, o padrão que se repete é claramente visível dentro do espaço de integração híbrido e consiste em dois elementos principais:

  • Exposição, que é caracterizada por um gateway que expõe as APIs
  • Implementação, que é tipificada por um tempo de execução no qual as interações de nível inferior podem ser editadas

Esses dois elementos são repetidos em graus variados em todo o cenário de integração, embora a profundidade e a sofisticação necessárias para cada um desses elementos variem em cada cenário.

Por exemplo, nas camadas inferiores mostradas no diagrama a seguir, ao fazer uma conexão profunda com os sistemas de registro existentes, provavelmente será necessário usar uma caixa de ferramentas de recursos. Agora, compare essa disposição com as camadas superiores do diagrama. Aqui, as equipes digitais que expõem novas APIs, com base na composição de APIs internas existentes e em padrões externos, podem apenas precisar do gateway e de alguns dos recursos de composição mais leves. As equipes que criam novos aplicativos podem precisar de um pouco mais que um gateway para expor suas APIs e acessar as APIs internas já expostas.

Repeating exposure and implementation across the hybrid                     landscape
Repeating exposure and implementation across the hybrid landscape

Essa visualização da arquitetura fornece uma análise de um conjunto muito mais abrangente de oportunidades de simplificação. Focando elementos de consistência, como os mostrados aqui, recomendamos um padrão comum, mas flexível, para executar a integração. Simplificamos e racionalizamos a arquitetura sem perder a capacidade. Pretendemos explorar mais essas áreas de consistência com flexibilidade em futuros artigos do developerWorks.

Conclusão

Este artigo explorou a evolução da integração híbrida. Foi explicado como a integração híbrida ampliou os limites de propriedade de uma empresa. Foram definidos os principais recursos da integração híbrida, além da função e dos requisitos das linhas de negócios. Em seguida, foi demonstrado como a equipe de TI central conecta a divisão bimodal, conferindo poderes à equipe digital. Foi feita uma diferenciação entre APIs públicas e APIs internas. Por último, este artigo demonstrou a importância de atender às necessidades da equipe digital e de garantir a consistência com flexibilidade no ambiente híbrido.

Neste artigo, evitamos fazer referências explícitas aos produtos IBM, mas como você pode imaginar, temos uma opinião bastante firme com relação a eles. Ao longo de 2016, assista as postagens no blog IBM Integration Developer Center que conecta a arquitetura de referência às ofertas da IBM. Essas postagens explicarão como muitos de nossos clientes estão vencendo os desafios reais da integração seguindo essa arquitetura de integração abrangente.

Agradecimentos

Agradecemos às pessoas a seguir pelas suas contribuições e revisões do material neste artigo: Andy Garratt, Peter Broadhurst, Carsten Bornert, Guy Hochstetler e Carlo Marcoli.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere, Cloud computing
ArticleID=1035988
ArticleTitle=A arquitetura de referência de integração híbrida em desenvolvimento
publish-date=08162016