Práticas recomendadas para desenvolver arquiteturas orientadas por eventos em sua organização

• eles são o principal mecanismo de invocação em padrões serverless;
• eles são o padrão preferido para desacoplar microsserviços, onde as comunicações assíncronas e a persistência de eventos são fundamentais;
• eles são amplamente adotados como um mecanismo de baixo acoplamento entre sistemas em diferentes domínios de negócios, como sistemas de terceiros ou locais.

Os padrões orientados por eventos permitem a independência da equipe por meio da dissociação e descentralização das responsabilidades. Essa tendência de descentralização, por sua vez, permite que as empresas se movam com agilidade sem precedentes, aumentando a velocidade de desenvolvimento de recursos.

Neste blog, exploraremos os componentes importantes e as decisões de arquitetura que você deve considerar ao adotar padrões orientados por eventos e forneceremos algumas orientações sobre estruturas organizacionais.

Divisão de responsabilidades

O fluxo de comunicações no EDA (consulte O que é EDA? ) é iniciado pela ocorrência de um evento. A maioria das implementações orientadas por eventos em produção tem três componentes principais, conforme mostrado na Figura 1: produtores, agentes de mensagens, e consumidores.

Produtores, barramento de mensagens e consumidores normalmente assumem as seguintes funções:

Produtores

Os produtores são responsáveis por publicar os eventos à medida que eles acontecem. Eles são os proprietários do esquema do evento (estrutura de dados) e da semântica (significado dos campos, como o significado do valor de um campo enumerado). Como esse é o único contrato (acoplamento) entre os produtores e os componentes posteriores do sistema, o esquema e sua semântica são cruciais no EDA. Os produtores são responsáveis pela implementação de um processo de gerenciamento de mudanças, que envolve mudanças contínuas e significativas. Com a introdução de mudanças importantes, os consumidores podem negociar o processo de migração com os produtores.

Os produtores são “independentes do consumidor”, pois seu limite de responsabilidade termina quando um evento é publicado.

Barramento de mensagens

Os barramento de mensagens (message brokers) são responsáveis pela durabilidade dos eventos e manterão um evento disponível para consumo até que seja processado com sucesso. Os barramentos de mensagens garantem que os produtores possam publicar eventos para os consumidores consumirem e regulam o acesso e as permissões para publicar e consumir mensagens.

Os barramentos de mensagens são em grande parte “independentes de eventos” e geralmente não acessam nem interpretam o conteúdo do evento. No entanto, alguns sistemas fornecem um mecanismo de roteamento com base na carga útil (payloads) do evento ou nos metadados.

Consumidores

Os consumidores são responsáveis por consumir eventos e devem possuir a semântica do efeito dos eventos. Os consumidores geralmente estão limitados a um contexto de negócio. Isso significa que o mesmo evento terá uma semântica de efeitos diferentes para consumidores diferentes. As escolhas de arquitetura são cruciais ao implementar um consumidor que envolvem o tratamento de entregas mal sucedidas de mensagens ou mensagens duplicadas. Dependendo da interpretação comercial do evento, ao se recuperar de uma falha, um consumidor pode permitir eventos duplicados, como com um padrão de consumo idempotente.

Fundamentalmente, os consumidores são “independentes do produtor”, e seu limite de responsabilidade começa quando um evento está pronto para consumo. Isso permite que novos consumidores se integrem ao sistema sem alterar os contratos dos produtores.

Independência da equipe

Para implementar a divisão de responsabilidades, as empresas devem organizar suas equipes técnicas de acordo com a responsabilidade de produtores, barramento de mensagens e consumidores. Embora a responsabilidade dos produtores e consumidores seja simples em uma implementação de EDA, a responsabilidade do barramento de mensagens pode não ser. Abordagens diferentes podem ser adotadas para identificar a responsabilidade do barramento de mensagens, dependendo de sua estrutura organizacional.

Responsabilidade descentralizada

Em uma estrutura organizacional de responsabilidade descentralizada (veja a Figura 2), as equipes que produzem eventos são responsáveis por gerenciar seus próprios agentes de mensagens e pela durabilidade e disponibilidade dos eventos para os consumidores.

A adoção de padrões de tópicos de fanout  baseados no Amazon Simple Queue Service (SQS) e no Amazon Simple Notification Service (SNS) (veja a Figura 3) pode ajudar as empresas a implementar um padrão de responsabilidade descentralizada. Um padrão baseado em barramento usando o Amazon EventBridge também pode ser utilizado de forma semelhante (veja a Figura 4).

A abordagem de responsabilidade descentralizada tem a vantagem de promover a independência da equipe, mas não é adequada para todas as organizações. Para ser implementada de forma eficaz, é necessária uma cultura de DevOps bem estabelecida. Nesse cenário, as equipes de produção são responsáveis por gerenciar a infraestrutura do barramento de mensagens e os padrões de requisitos não funcionais.

Responsabilidade centralizada

Em uma estrutura organizacional de responsabilidade centralizada, uma equipe central (chamaremos de equipe de plataforma) é responsável pelo gerenciamento do barramento de mensagens (veja a Figura 5). Ter uma equipe de plataforma especializada oferece a vantagem da implementação padronizada de requisitos não funcionais, como confiabilidade, disponibilidade e segurança. Uma desvantagem é que a equipe da plataforma é um ponto único de falha no ciclo de vida de desenvolvimento e implantação. Isso pode se tornar um gargalo e colocar em risco a independência da equipe e a eficiência operacional.

Além dos padrões de implementação mencionados na seção anterior, a presença de uma equipe dedicada facilita a implementação de padrões de streaming. Nesse caso, é necessário um entendimento mais profundo sobre como os dados são particionados e como o sistema é dimensionado. Os padrões de streaming podem ser implementados usando serviços como o Amazon Managed Streaming for Apache Kafka (MSK) ou o Amazon Kinesis Data Streams (veja a Figura 6).

Práticas recomendadas para implementar arquiteturas orientadas por eventos em sua organização

As estruturas organizacionais de responsabilidade centralizada e descentralizada aumentam a independência da equipe ou a padronização dos requisitos não funcionais, respectivamente. No entanto, eles introduzem possíveis fronteiras no crescimento do time de engenharia em uma empresa.

Inspirado pelas duas abordagens, você pode implementar um conjunto de melhores práticas que visam minimizar essas limitações.

1. Crie um centro de excelência em nuvem (CCoE). Um CCoE padroniza a implementação não funcional em todas as equipes de engenharia. Para promover uma forte cultura de DevOps, o CCoE não deve assumir a forma de uma equipe externa independente, mas sim ser uma coleção de membros individuais representando as várias equipes de engenharia.
2. Descentralize a responsabilidade da equipe. Descentralize a responsabilidade e a manutenção do barramento de mensagens para as equipes de produção. Isso maximizará a independência e a agilidade da equipe. Ele capacita a equipe a usar a ferramenta certa para o trabalho certo, desde que esteja em conformidade com as diretrizes do CCoE.
3. Centralize os padrões de registro e as estratégias de observabilidade. Embora seja uma prática recomendada descentralizar a responsabilidade da equipe sobre os componentes de uma arquitetura orientada por eventos, os padrões de registro e as estratégias de observabilidade devem ser centralizados e padronizados em toda a função de engenharia de software. Essa centralização fornece rastreamento de ponta a ponta de solicitações e eventos, que são ferramentas de diagnóstico poderosas em caso de falha.

Conclusão

Neste post, descrevemos os principais componentes de uma arquitetura orientada a eventos e identificamos a responsabilidade do barramento de mensagens como uma das escolhas de arquitetura mais importantes que você pode fazer. Descrevemos uma abordagem organizacional centralizada e descentralizada, apresentando os pontos fortes das duas abordagens, bem como os limites que elas impõem ao crescimento de sua organização de engenharia. Fornecemos algumas práticas recomendadas que você pode implementar em sua organização para minimizar essas limitações.

Leitura adicional:
Para começar sua jornada criando arquiteturas orientadas por eventos na AWS, explore os seguintes tópicos:

• Para padrões baseados em barramentos e tópicos, consulte O que é uma arquitetura orientada por eventos?
• Para padrões de streaming, consulte O que é o Apache Kafka? e o Amazon Kinesis

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre o autor