EventBridge Storming — Como criar uma aplicação estado da arte totalmente Event-Driven e Serverless (Translated Version)
This is a translation of the original article “EventBridge Storming — How to build state-of-the-art Event-Driven Serverless Architectures” by Ben Ellerby.
Translated by Evandro Pires da Silva
Part of the Serverless-Transformation Rosetta Initiative
Arquiteturas microsserviços só funcionam quando elas:
- São divididas em serviços claros e bem definidos
- Podem ser implantados de forma independente
- Somente se comunicam com outros serviços de forma assíncrona
- Dominam seus próprios dados
Arquitetura Orientada a Serviços, ou do inglês Service-Oriented Architecture (SOA), um termo que precedeu os Microsserviços, tem várias características semelhantes a estas citadas. Arquiteturas SOA geralmente diferem do que entendemos por microserviços modernos em seu mecanismo de comunicação.
Uma variante popular do SOA é o Event-Driven Architecture (EDA), ou Arquitetura Orientada a Eventos, em português. Nesse paradigma, cada serviço consome e produz eventos, permitindo baixo acoplamento na interação entre os serviços. Estas abordagens SOA comumente dependiam do papel do Enterprise Service Bus (ESB) para fornecer o transporte destes “Eventos”.
O que é um Enterprise Service Bus (ESB):
- Enterprise: Implica o uso em grandes organizações empresariais que geralmente usam para lidar com a complexidade nesses domínios, juntamente com o investimento alto em infraestrutura historicamente necessário.
- Service: Fornecem uma maneira para os diferentes serviços (representações lógicas autocontidas de processos de negócios) se comunicarem.
- Bus: Faz referência ao elemento de hardware dos computadores que permite a transferência de sinais entre diferentes componentes.
Evento: “Uma significante mudança no estado” — K. Mani Chandy
EventBridge
“Uma ponte sobre arquiteturas problemáticas”
Em 2019, a AWS lançou um novo serviço Serverless, Amazon EventBridge, formalizando o fluxo de eventos através de arquiteturas Serverless. Antes disso, muitas pessoas trabalhando com paradigma Event-Driven tinham que “hackear” um Bus além de usar o CloudWatch Events.
Para um entendimento completo do EventBridge, veja o artigo EventBridge: The key component in Serverless Architectures e assista a ótima introdução em vídeo feito pelo James Beswick.
Em resumo, EventBridge é o maior anúncio de serviço Serverless desde o lançamento do AWS Lambda e é o componente chave para construção de aplicações serverless estado da arte usando o paradigma Event-Driven.
O ESB está morto, vida longa ao ESB
Em contraste com soluções ESB típicas, o EventBridge é completamente Serverless. Requer nenhuma gestão e tem integração fácil com todos os serviços existentes da AWS. Por padrão, todos os eventos cloud da AWS que integram com CloudWatch estão incluídos no EventBus default e você está habilitado a construir seu próprio Event Bus dentro do EventBridge para seus eventos de aplicações customizados.
Evitando o “Lambda Pinball”
O Lambda Pinball é um anti-pattern Serverless destacado pela ThoughtWorks onde “perdemos de vista a lógica de domínio importante no emaranhado de lambdas, buckets e filas conforme as requisições saltam em cada vez mais complexos serviços em nuvem”.
Isso geralmente é o resultado da falta de fronteiras claras de serviço. Mudar para um EDA e adotar EventBridge pode ajudar enormemente — mas isso não é uma bala de prata de forma isolada.
O que é necessário é um foco nos serviços, identificando contextos delimitados claros (emprestando do DDD — Domain-Driven Design, ou em português, Design Orientado a Domínio) e compartilhando Event Schemas, não código, interfaces de API ou dados.
“EventBridge Storming”
Event Storming é uma abordagem para definir os eventos, fronteiras e entidades em seu domínio de negócios criado por Alberto Brandolini como uma extensão do Domain-Driven Design (DDD).
Trabalhar a totalidade do DDD pode ser muito para dominar e pode resultar em engenharia excessiva para sistemas sem grande complexidade de domínio.
No entanto, o Event Storming pode ser usado isoladamente.
O guia a seguir apresentará as etapas para Event-Storm em direção a uma arquitetura Serverless orientada a eventos de última geração baseada em EventBridge.
Decidimos chamar esta variante de Event Storming de EventBridge Storming. O foco está menos no DDD formal e mais na estruturação pragmática de arquiteturas Serverless baseadas em EventBridge.
O “EventBridge Storming” pode ser usado em projetos greenfield ou brownfield Serverless, desde os extremamente simples aos assustadoramente complexos. Ele garante uma linguagem comum, compreensão máxima de Eventos em termos de domínio de negócios com uma lista de Serviços independentes para criar e um Schema no Registry do EventBridge.
Benefícios do “EventBridge Storming”
- Redução de acoplamento
- Maior velocidade de desenvolvimento a médio e longo prazo
- Arquitetura mais adaptável e redução de risco de reconstrução
- Redução de requisitos de código
- Melhor ownership do sistema pelas equipes
- Melhor disponibilidade
Guia do EventBridge Storming
“EventBridge Storming”: uma variante específica do EventStorming que reduz o retrabalho e o acoplamento para equipes que criam arquiteturas orientadas a eventos Serverless de última geração com EventBridge.
EventBridge Storming, baseado em Event Storming, começa com os membros do time de negócios (produtos) e do time técnico de um projeto conduzindo um workshop para entender seus sistemas. Isso é feito, de preferência pessoalmente, com muitos post-its à mão. Um típico Event Storming tem diretrizes específicas sobre as cores de Post-It, embora estejamos nos concentrando em Eventos e essas regras são menos importantes.
As etapas 1 a 5 são realizadas em conjunto pelo time de negócio e técnico. A partir da etapa 6, até a 8, o time técnico continuará a desenvolvê-lo na arquitetura. Todo esse processo deve ser feito em menos de uma semana, com as etapas 1 a 5 realizadas em uma sessão de 1 dia. O tempo exato depende da complexidade do domínio e da coesão da equipe.
Idealmente as etapas são realizadas pessoalmente, mas quando isso não é possível faça uma reunião em grupo e utilize uma ferramenta como o https://metroretro.io/ que pode ser altamente eficiente.
Na imagem acima, podemos ver todas as etapas do EventBridge Storming, que são:
- Event Discovery: Descoberta dos conjuntos de domínios de eventos
- Temporal Sequencing: Organização dos eventos em ordem cronológica e sequencial
- Trigger Detection: Encontrar os pontos de gatilho e os atores
- Categorize Aggregates: Encontrar as entidades (como substantivos)
- Categorize Bounded Contexts: Agrupar os eventos evitando dependências (definição de fronteiras)
- Name Microservices: Nomear os microserviços para ter fronteiras bem definidas por contexto
- Create Single EventBus: Criar um único EventBus para todos os eventos
- Build Shared Schema: Compartilhar a estrutura dos eventos entre os serviços
1. Event Discovery (Descoberta de Eventos)
Conforme definido anteriormente, um Evento pode ser entendido como uma “mudança significativa de estado”. Neste workshop, o foco são Eventos do domínio de negócio. O foco não deve ser em eventos técnicos ou detalhes de implementação, em vez disso, os eventos do mundo real que o sistema precisa tratar é que devem ser elaborados.
Essa primeira etapa envolve toda a equipe escrevendo eventos em post-its e colocando-os em uma grande tela em branco. Todos os eventos devem ser escritos no passado (pretérito) e devem se concentrar nos verbos. Por exemplo, “Pedido feito”, “Pagamento não efetuado”, “Pagamento efetuado com sucesso”, “Item despachado”.
É importante não se concentrar em agrupar, remover itens repetidos ou filtrar durante esse tempo — é crucial colocar todos os eventos de domínio conhecidos no quadro. A limpeza e o agrupamento são feitos posteriormente.
Para um projeto greenfield simples em uma startup, isso pode levar apenas 45 minutos — para uma grande transformação digital organizacional, pode demorar muito mais.
2. Temporal Sequencing (Sequencialmento temporal)
Esta etapa envolve colocar todos os eventos em ordem de tempo, da esquerda para a direita (os eventos simultâneos são empilhados). O foco aqui não é agrupar, é colocar todas as cartas na ordem da esquerda para a direita. Se ficar complicado organizar os subprocessos, use alguma separação vertical, mas mantenha o foco em colocar os eventos em ordem, não os grupos.
Continue indo para frente e para trás na sequência, adicionando eventos ausentes. É o momento de discutir os itens complexos, concordar com os termos e remover itens duplicados.
3. Trigger detection (Detecção de gatilhos) — Opicional
A detecção de trigger é um estágio frequentemente usado em Event Storming, onde adicionamos os gatilhos, comandos, sistemas externos e atores. Isso pode ser muito útil para nos forçar a pensar mais criticamente sobre os eventos de nosso sistema e garantir uma terminologia compartilhada — embora isso não seja fundamental para todos os sistemas.
4. Categorize Entities & Aggregates (Categorização de entidades e agrupamentos)
Esta é a primeira fase do agrupamento. O primeiro passo é procurar os substantivos nos Eventos do quadro. A partir disso, é fácil começar a criar novos Post-its (de preferência com uma cor diferente para os Eventos), com esses nomes de Entidades (Entities). Se a etapa de detecção de trigger não foi realizada, os atores podem ser capturados como entidades.
No DDD formal, um Aggregate é uma coleção de entidades (por exemplo, um carro, pedido, loja). Este workshop é focado na modelagem de eventos e não na modelagem de dados. Ficar em um nível bastante alto de abstração quando se trata de Entidades é o mais indicado — use as Entidades criadas a partir dos Eventos (algumas delas podem ser Aggregate, mas essa não é uma distinção que precisamos neste ponto e pode ser confusa para o grupo).
5. Categorization into Bounded Contexts (Categorização em contextos delimitados)
Esta segunda etapa de agrupamento tem como objetivo encontrar os limites entre nossos sistemas futuros. O objetivo é eliminar dependências entre esses grupos. Em equipe, desenhe círculos em torno de agrupamentos lógicos de eventos e entidades, otimizando para reduzir a interdependência — isso reduzirá o alto acoplamento e o acoplamento temporal no sistema que vai resultar deste trabalho.
No DDD formal, um Bounded Context é um conjunto de linguagem consistente — um contexto no qual um termo é compreendido de forma onipresente. Por exemplo, “Pedido” pode significar uma coisa em um contexto de “Despacho de Item” e outra coisa em um contexto de “Marketing”. Este é um conceito bastante abrangente e, para alguns sistemas mais simples, a ideia da inconsistência pode não se apresentar ou se fazer necessário, mas ainda é muito útil fazer agrupamentos lógicos de eventos que eliminam dependências. Este é um ponto de partida para elaborar a lista de microsserviços e sua estrutura.
Quanto mais claro for o entendimento de um sistema em termos de negócios, mais claro e mais adaptável será o código resultante.
Se um Aggregate / Entity aparecer em vários contextos, isso não é necessariamente um problema — significa apenas que os sistemas derivados podem precisar duplicar os dados para serem implantados isoladamente e deve-se considerar o potencial acoplamento temporal.
Agora que os contextos e fronteiras foram identificados, eles precisam ser nomeados com um acordo entre as partes interessadas de negócios (produtos) e técnicas. Por exemplo, Gerenciamento de pedidos.
A partir de agora, o resto do EventBridge Storming pode ser tratado pela equipe técnica.
6. Name Microservices (Nomeando os Microsserviços)
Um Lambda não faz um microsserviço
Precisamos construir microsserviços correspondentes aos nossos contextos e fronteiras. Com base no exemplo acima, você pode ter uma ideia intuitiva da granularidade de um microsserviço nessa abordagem.
Porém, muitas equipes, especialmente quando uma sessão semelhante não foi realizada, podem cair na armadilha de dizer que um Lamdba é um microsserviço (ou NanoServiço). Isso leva a Lambdas muito inchadas, gerenciamento ineficiente de vários Lambdas que deveriam ter sido agrupados como um Serviço e negligenciando completamente a implantação e configuração de outros componentes como DynamoDB, Step Functions, SQS, SNS, etc.
No caso do DynamoDB, pensar em termos de vários Serviços associados a contextos delimitados e seus Aggregates / Entities pode resultar em duplicação de dados proposital. Sem esse processo, um anti-pattern de banco de dados compartilhado pode violar a regra de deployment independente da abordagem SOA.
Construindo uma lista de (micro) serviços
Um contexto delimitado não é a mesma coisa que um microsserviço. Um contexto delimitado é um espaço no qual uma terminologia específica pode ser compreendida de forma onipresente, geralmente envolvendo uma única equipe com poucos interessados.
Em contraste, um microsserviço se refere a um conjunto de coisas que são implantadas juntas.
- Um contexto delimitado pode ter vários microsserviços correspondentes a seus Aggregates e Entities.
- ⚠️Se um microsserviço estiver envolvido em vários contextos delimitados, o alarme deve soar! Isso geralmente resulta em um monólito distribuído fortemente acoplado.
Quando formamos nossos contextos delimitados, tentamos evitar a interdependência. É o mesmo na formação de nossos microsserviços. Devemos tentar eliminar a necessidade de solicitações síncronas entre os serviços. Por exemplo, uma arquitetura em que todos os serviços precisam chamar o microsserviço do pedido para concluir seus processos cria um único ponto de falha e esse acoplamento diminui a adaptabilidade do sistema.
Como equipe técnica, tente listar os microsserviços necessários para cada contexto delimitado. Em sistemas simples, isso pode ser um mapeamento 1–1. Em contextos mais complexos, pode ser por Aggregate contido em um contexto.
⚠️Se uma Entity ou Aggregate aparecer em dois contextos, isso significa que deve haver dois microsserviços independentes para lidar com os processos de negócios divergentes nesses dois contextos.
7. Creating a Single EventBridge Event Bus (Criando um único Event Bus no EventBridge)
Com exceção do Default Bus, sua arquitetura deve ter apenas 1 (um) Barramento de Eventos (Bus). Isso porque todos os Eventos devem poder ser consumidos por todos os Serviços, sem que equipes e códigos tenham que coordenar.
Times devem ser capazes de descobrir Eventos e consumi-los quando necessário — apenas precisando receber e publicar em um Bus.
8. Building a Shared Schema (Construindo um Schema compartilhado)
As equipes devem ser capazes de trabalhar e implantar os Serviços de forma independente. Com a mudança para um EDA Serverless baseado em EventBridge, mudamos do modelo de Request-Response síncrono para pensar em interações assíncronas por meio de eventos unidirecionais.
As equipes precisam concordar sobre a estrutura dos eventos e seus esquemas. Isso inclui o nome do evento, a estrutura e os tipos de atributos. Equipes, e até mesmo sistemas gerenciados por uma única equipe, devem compartilhar um esquema, não um banco de dados, base de código ou interface de API.
Todos os membros da equipe técnica, ou representantes, se em um contexto maior, devem dedicar workshops para trabalhar o esquema criado para todos os eventos.
Isso é adicionado ao EventBridge Schema Registry (veja mais sobre isso no artigo anterior em EventBridge).
Times devem compartilhar Schema, não dados ou código.
Conclusões
Em resumo, precisamos construir aplicações usando serviços desacoplados em uma abordagem orientada a eventos. EDAs Serverless de última geração usam o EventBridge para conseguir isso.
O Event Storming é uma ferramenta extremamente útil e fornece a primeira etapa principal. A variante EventBridge Storming explicada neste artigo é um guia pragmático para construir um aplicativo Serverless de última geração usando EventBridge.
Este não é um plano que não está sujeito a alterações, é um ponto de partida e estas sessões devem ser repetidas.
EventBridge Storming: uma especialização do EventStorming que reduz o retrabalho e o acoplamento da aplicação, para equipes que criam arquiteturas orientadas a eventos Serverless de última geração com EventBridge
This is a translation of the original article “EventBridge Storming — How to build state-of-the-art Event-Driven Serverless Architectures” by Ben Ellerby
Part of the Serverless-Transformation Rosetta Initiative
Serverless Transformation is a Theodo initiative. Theodo helps companies leverage Serverless through expert delivery and training teams.
Learn more about Theodo and speak to one of our teams today!
If you like content like this consider subscribing to our weekly newsletter!
