Há algum tempo, solicitaram-me a elaboração de um documento destinado aos fornecedores, com o propósito de servir como referência para arquiteturas de integração. Achei o documento final interessante pra ser compartilhado e talvez possa ajudar alguém no futuro... Depois deixem seus comentários sobre o que acharam/sugestões...

Esse mesmo post estará no meu https://andredemattosferraz.substack.com/ (completo). Porém, lancei em primeira mão pra vocês aqui! Me sigam no substack para me ajudar a manter mais posts assim!

---

Arquitetura de Integrações, Uma Referência

Este texto apresenta princípios para garantir consistência e a qualidade das decisões tecnológicas relacionadas as integrações entre sistemas/aplicações.

Os princípios orientam para o melhor cenário de integração (tomada de decisão). Cada princípio conterá uma descrição, justificativa e suas implicações.

Desacoplamento de Aplicações/Sistemas

Descrição

Obtenha independência tecnológica de sistemas por meio de middleware (channel adapters, veja imagem a seguir), microsserviços/APIs (interfaces de programação de aplicativos) e integrações orientadas a mensagens assíncronas.

Justificativa

• A arquitetura de integração deve ser planejada para reduzir o impacto das mudanças tecnológicas e da dependência do fornecedor por meio de desacoplamento. O desacoplamento deve envolver integrações entre sistemas através de Middleware, Microserviços/APIs (Interfaces de Programação de Aplicações) e sistemas de Mensagens Assíncronas.
• Cada decisão tomada relativa às tecnologias que permitem a integração dos sistema irá aumentar a dependência dessas tecnologias. Portanto, este princípio pretende garantir que os sistemas não dependam de tecnologias específicas para se integrarem. A independência das aplicações em relação à tecnologia de suporte permite que as aplicações sejam desenvolvidas, atualizadas e operadas com a melhor relação custo-benefício. Caso contrário, quando a tecnologia ficar obsoleta e dependente do fornecedor, o foco mudará para ela, em vez das necessidades do usuário.
• Evitar a integração ponto a ponto, pois envolve dependência tecnológica dos respetivos sistemas de informação e forte acoplamento entre os sistemas envolvidos.

Implicações

• Microsserviços/APIs reutilizáveis serão desenvolvidos para permitir que aplicativos legados interoperem com outros.
• Os microsserviços/APIs devem ser desenvolvidos e implantados de forma independente, possibilitando agilidade.
• O middleware (adapter) deve ser usado para desacoplar aplicações/sistemas.
• As partes problemáticas da aplicação/sistema devem ser isoladas, corrigidas e mantidas, enquanto a parte maior pode continuar sem qualquer alteração.
• Deve-se ser escalável verticalmente ou horizontalmente.
• Este princípio também implica documentar padrões de tecnologia e especificações e métricas de API para melhor compreender o custo operacional.
• Os benchmarks da indústria devem ser adotados para fornecer métricas comparativas de eficiência e ROI.
• Microsserviços/APIs devem ser implementados com maior disponibilidade que os demais componentes já existentes (aplicações/sistemas), por exemplo, 24 horas x 7 dias.

Integração de dados e aplicação

Descrição

Categorize os casos de uso de integração como: integração de dados ou integração de aplicações.

Justificativa

• A Integração de Dados se concentra em reconciliar fontes de dados e conjuntos de dados diferentes em uma visão única dos dados compartilhados por toda a empresa. Muitas vezes é um pré-requisito para outros processos, incluindo análise, relatórios e previsões.
• A Integração de Aplicativos está focada em alcançar eficiência operacional para fornecer dados (quase) em tempo real aos aplicativos e manter os processos de negócios em execução. Não envolve reconciliar diferentes fontes de dados num modelo de dados coerente e partilhado para obter uma visão holística de todos os conjuntos de dados (por exemplo, finanças, vendas, etc.).
• Tanto a Integração de Dados quanto a Integração de Aplicativos podem usar Extração, Transformação e Carregamento (ETL), um processo tripartido no qual os dados são extraídos (coletados), geralmente em massa, das fontes brutas, transformados (limpos) e carregados (ou salvos) para um destino.
• O pipeline de dados ETL, é um termo abrangente para toda movimentação e limpeza de dados, que permite canalizar dados para outras bases de dados não unificadas.

Implicações

• A integração de dados deve fornecer os seguintes recursos:
  • Visão 360 das informações e operações simplificadas (ex: ler e exportar)
  • Data Warehouse/Datalake centralizado
  • Gerenciamento de qualidade de dados
  • Permitir colaboração entre áreas
  • Permitir evolução para Big Data
• Para casos de uso de integração de dados, as ferramentas como - Azure Data Factory, Informatica, etc. - devem ser usadas para realizar ETL e análise de dados para grandes volumes.
• Os serviços de armazenamento de dados devem ser disponibilizados para processos de integração de dados, persistindo dados para análise e relatórios. Ex - Bancos de Dados (SQL/NoSQL), Data Warehouse, Data Lake, etc.
• A integração de aplicações deve fornecer os seguintes recursos:
  • Troca de dados em tempo real ou quase em tempo real entre os aplicações.
  • Manter os dados atualizados em diferentes aplicações.
  • Fornecer interfaces reutilizáveis para troca de dados com diferentes aplicativos.
  • Recuperação de transações com falha em (quase) tempo real por meio de mecanismos de repetição ou fluxos confiáveis de mensagens com tratativas para mensagem perdidas/erro através fila de mensagens mortas (dead-letter queue).
• Para integração de aplicações, considere usar APIs/microsserviços, middleware (adapter) baseado em mensagens para de troca de dados (quase) em tempo real. As tecnologias que permitem esses serviços são Apache Kafka, EventHub, RabbitMQ, etc.
• Os ETLs podem ser usados para integração de aplicações; no entanto, devem ser feitas considerações para processar pequenos volumes de dados com alta frequência para troca de dados entre as aplicações, a fim de alcançar uma transferência de dados quase em tempo real.

Arquitetura Event-Driven

Descrição

Projetar sistemas para transmitir e/ou consumir eventos afim de aumentar a capacidade de resposta e desacoplamento de aplicações.

Justificativa

• Em uma arquitetura orientada a eventos, o cliente gera um evento e pode seguir imediatamente para sua próxima tarefa. Diferentes partes do aplicativo então respondem ao evento conforme necessário, o que melhora a responsividade do aplicativo.
• Em uma arquitetura orientada a eventos, o publicador emite um evento, que é reconhecido pelo barramento de eventos ou filas de mensagens (MQ). O barramento de eventos ou MQ direciona os eventos para os assinantes, que processam os eventos com lógica de negócio autônoma. Não há comunicação direta entre publicadores e assinantes. Isso é chamado de modelo Pub-Sub.
• O modelo de publicação e assinatura usado na arquitetura orientada a eventos permite múltiplos assinantes para o mesmo evento; assim, diferentes assinantes podem executar outras lógicas de negócio ou envolver diferentes sistemas.
• Migrar para uma arquitetura orientada a eventos permite lidar com tráfego imprevisível, já que os processos envolvidos podem ser executados em diferentes velocidades de forma independente.
• As arquiteturas orientadas a eventos permitem que os processos realizem o tratamento de erros e as tentativas novamente de forma eficiente, pois os eventos são persistentes entre diferentes processos.
• Arquiteturas orientadas a eventos promovem a independência das equipes de desenvolvimento devido ao acoplamento fraco entre publicadores e assinantes. As aplicações podem se inscrever em eventos com requisitos de roteamento e lógica de negócio separadas do publicador e de outros assinantes. Isso permite que publicadores e assinantes mudem de forma independente, proporcionando mais flexibilidade para a arquitetura geral.

Implicações

• Aplicações que não precisam de respostas imediatas dos serviços e podem permitir o processamento assíncrono devem optar por arquiteturas orientadas a eventos.
• Os eventos devem ser persistidos nas filas de mensagens, que devem atuar como armazenamentos temporários para os eventos, para que possam ser processados de acordo com a capacidade dos consumidores e garantir que não haja perda de eventos. Uma vez que os eventos são processados, eles podem ser excluídos conforme necessário.
• Os serviços envolvidos devem ser configurados para reprocesar e tentar novamente os eventos em caso de um problema técnico recuperável. Por exemplo, quando um sistema secundário fica indisponível, os eventos falharão em ser entregues; no entanto, quando o sistema voltar, os eventos falhados podem ser reprocesados automaticamente. Os serviços devem tentar periodicamente processar os eventos até que sejam bem-sucedidos. Uma boa abordagem seria usar “exponential backoff” para calcular o tempo entre tentativas. É possível também definir um número máximo de tentativas, e ao atingi-lo, o evento poderá ser enviado para uma fila/bus de de mensagens não entregues (deadletter queue).
• Os serviços envolvidos podem não reprocesar ou tentar novamente os eventos em caso de erro de negócio ou funcional. Por exemplo, se o formato dos dados estiver incorreto, nesse caso, não importa quantas vezes os eventos sejam reprocesados, eles continuarão falhando, criando eventos inválidos que bloquearão todo o processo. Para evitar esse cenário, os erros de negócio ou funcionais devem ser identificados e os eventos falhados devem ser encaminhados para uma fila de eventos falhados. Que posteriormente pode ser usada pra processar estes eventos de acordo com a necessidade. Por exemplo: notificar usuários, ignorar o erro, abrir um chamado automaticamente no CRM.
• Adotar de sistemas de streaming de eventos (por exemplo, Kafka ou Microsoft Azure Event Hub) em casos de uma alta volumetria de dados, contínua e incremental (stream) estiver sendo trafegada. Exemplo de fontes de stream: bancos de dados, dispositivos IoT ou outros.

Integrações Real-Time ou Near Real-Time

Descrição

Simplifique os processos para enviar dados com frequência por meio de integrações baseadas em mensagens/eventos.

Justificativa

• As mensagens formam uma interface bem definida e neutra em termos de tecnologia entre as aplicações.
• Permite o desacoplamento de aplicações. Uma empresa pode ter várias aplicações com diferentes linguagens e plataformas construídas de forma independente.
• Oferece opções para fácil ajuste de desempenho e dimensionamento. Por exemplo:
  • Implantação e processamento em diferentes infraestruturas.
  • Vários requisitantes podem compartilhar um único servidor.
  • Vários requisitantes podem compartilhar vários servidores.
• Os vários middlewares de mensagens implementam de forma independente os padrões de mensagens.
  • Request/Reply
  • Fire and Forget
  • Publish/Subscribe
• Middleware entre as aplicações podem lidar com transformações de mensagens. Exemplo:: JSON para XML, XML para JSON, etc.
• Middleware entre as aplicações podem decompor uma única solicitação grande em diversas solicitações menores.
• As mensagens assíncronas são fundamentalmente uma reação aos problemas dos sistemas distribuídos. Uma mensagem pode ser enviada sem que ambos os sistemas estejam ativos e prontos simultaneamente.
• A comunicação assíncrona força os desenvolvedores a reconhecer que trabalhar com uma aplicação remota é mais lento, o que incentiva o design de componentes com alta coesão (muito trabalho local) e baixo acoplamento (trabalho seletivo remotamente).

Implicações

• Partilhar dados e processos de forma responsiva através de integrações baseadas em mensagens.
• As aplicações deverão ser informadas quando os dados compartilhados estiverem prontos para consumo. A latência no compartilhamento de dados deve ser levada em consideração no projeto de integração; quanto mais tempo o compartilhamento puder levar, maiores serão as oportunidades para os dados compartilhados se tornarem obsoletos e mais complexa se tornará a integração.
• Os padrões de mensagens devem ser usados para transferir pacotes de dados com frequência, de forma imediata, confiável e assíncrona, usando formatos personalizáveis (https://github.com/cloudevents/spec).
• As aplicações devem ser integradas através de canais de mensagens (Enterprise Service Bus, Message Queues, etc.) para trabalharem em conjunto e trocarem informações em tempo real ou quase em tempo real.

Microserviços

Descrição

Microsserviços podem facilitar uma arquitetura de integração escalonável, extensível e reutilizável. Ela permite que times distribuídos trabalhem de forma independente sem impactar os demais. O uso de microsserviços só começa a ser relevante quando as aplicações ficam grandes demais para serem mantidas. Para aplicações em estágio inicial, uma arquitetura monolítica bem projetada é suficiente. Uma estrutura monolítica bem definida permitirá substituir qualquer funcionalidade por um microsserviço quando necessário.

Justificativa

• As arquiteturas monolíticas acrescentam risco à disponibilidade dos aplicativos porque muitos processos dependentes e fortemente acoplados aumentam o impacto da falha de um único processo. Com uma arquitetura de microsserviços, um aplicativo é construído como componentes independentes que executam cada processo do aplicativo como um serviço. E a falha em um microserviço impacta somente o seu contexto (outros serviços que interagem com ele) e não toda aplicação. Esses serviços se comunicam por meio de uma interface bem definida usando APIs leves.
• As arquiteturas de microsserviços tornam os aplicativos mais fáceis de escalar e mais rápidos de desenvolver, permitindo a inovação e acelerando o tempo de lançamento de novos recursos no mercado.
• Os microsserviços permitem que cada serviço seja dimensionado de forma independente para atender à demanda do recurso que ele suporta. Isso permite que as equipes dimensionem corretamente as necessidades de infraestrutura, meçam com precisão o custo de um recurso e mantenham a disponibilidade se um serviço sofrer um aumento na demanda.
• Os microsserviços permitem integração e entrega contínuas, facilitando a experimentação de novas ideias e a reversão caso algo não funcione. O baixo custo da falha incentiva a experimentação, facilita a atualização do código e acelera o tempo de lançamento de novos recursos no mercado.
• As arquiteturas de microsserviços não seguem uma abordagem “padrão único”, permitindo assim a liberdade tecnológica. As equipes têm a liberdade de escolher a melhor ferramenta para resolver seus problemas específicos. Portanto, as equipes que constroem microsserviços podem escolher a melhor ferramenta para cada trabalho.
• Dividir o software em módulos pequenos permite a reusabilidade de blocos de código em novas features.
• A independência aumenta a resistência de um aplicativo a falhas. Em uma arquitetura monolítica, se um único componente falhar, poderá causar a falha de todo o aplicativo. Com os microsserviços, existe uma degradação da funcionalidade e não travamento de toda a aplicação.

Implicações

• Tecnologias como Amazon Web Services (AWS), Microsoft Azure, Kubernetes, etc., que fornecem a capacidade de construir APIs usando serverless, devem ser totalmente aproveitadas para implementar o padrão de arquitetura de microsserviços.
• As APIs devem ser documentadas seguindo padrões de documentação como RESTful API Modeling Language (RAML) ou Swagger para que o consumidor possa compreender os métodos, operações e funcionalidades das APIs. As APIs também devem seguir padrões de nomenclatura e controle de versão, que devem estar refletidos na documentação da API.
• As APIs devem ser publicadas em catálogos/repositórios/portais de API e detectáveis para que as equipes de projeto envolvendo desenvolvedores, arquitetos e analistas de negócios possam descobri-las e promover sua reutilização.
• As APIs devem ser protegidas de acordo com os padrões de segurança da informação para garantir que os padrões de segurança das APIs sejam respeitados durante todo o ciclo de vida das APIs, desde a concepção, passando pelo desenvolvimento, até a publicação para consumo.
• Devem ser evitadas integrações ponto a ponto, uma vez que criam dependências tecnológicas nos sistemas finais e débitos técnicos, que são difíceis de gerir a longo prazo.
• Quando é necessário um alto throughput o uso de gRPC deve ser levado em consideração
• Excesso de requisições, devido ao alto tráfego de comunição entre os serviços.
• Gerencimaneto de transação é bem mais complexo através do uso de SAGAS. A consistência de dados é eventual.
• Arquitetura complexa de manter implicando em maior responsabilidade e exigência técnica.
• Aumento significativo dos custos de cloud
• "Dependency Hell"