Jun 24, 2021
EventBridge: o componente principal para arquiteturas serverless
This is a translation of the original article “EventBridge: The key component in Serverless Architectures” by Ben Ellerby.
Translated by Evandro Pires da Silva
Part of the Serverless-Transformation Rosetta Initiative
As arquiteturas serverless fazem uso de FaaS (Function as a Service) como o AWS Lambda. O FaaS oferece aos desenvolvedores a capacidade de enviar o código do aplicativo ao cloud provider e executá-lo de maneira isolada, com todos os detalhes do servidor abstraídos por eles. Essas funções devem ser invocadas por um gatilho (trigger), seja essa invocação direta do AWS SDK, por meio de HTTP via API Gateway, um DynamoDB Stream, Kinesis, Cognito, Alexa ou S3…
A partir desses exemplos de gatilhos FaaS, podemos ver que a mudança para adotar o Serverless é uma mudança para um paradigma mais orientado a eventos.
Uma arquitetura Serverless-First deve tratar os eventos como cidadãos de primeira classe (First-class Citizen) — é a única maneira de realmente abraçar o poder do Cloud-Native.
Existem muitos debates sobre como as funções do Lambda devem ser arquitetadas, variando da abordagem monolítica com “um lambda para controlar tudo”, a uma divisão por Serviços ou uma abordagem de Microserviço / MicroLambda.
Pela minha experiência, quanto mais precisa a granularidade de suas funções, melhor será o desempenho e a adaptabilidade de sua arquitetura.
Os microsserviços são difíceis. O gerenciamento de versões de API, comunicações entre equipes, duplicação de dados e muitos outros aspectos são desafiadores.
Então, em uma abordagem “Micro-Lambda”, com funções Lambda extremamente granulares: como estamos, exatamente, tornando nossas vidas mais fáceis?
De fato, teremos muito mais serviços interagindo uns com os outros e respondendo a eventos CloudNative, não apenas HTTP.
Enter, EventBridge
Em 2019, a AWS lançou um novo serviço Serverless, Amazon EventBridge, dando forma ao fluxo de eventos através de arquiteturas. Ele faz isso fornecendo Event Bus(es) para os eventos serem distribuídos, junto com ferramentas para os desenvolvedores interagirem com esses eventos.
O EventBridge foi visto pela comunidade Serverless como o maior anúncio desde a AWS Lambda. Isso ocorre porque a comunidade Serverless está mudando para arquiteturas orientadas a eventos, e o EventBridge era a peça que faltava no quebra-cabeça Serverless orientado a eventos.
Evento: “Uma significante mudança no estado” — K. Mani Chandy
EventBridge nos ajuda a escapar das solicitações síncronas passadas entre si pelas funções Lambda que resultam em um anti-pattern “Lambda Pinball”, com solicitações alternando entre Lambdas, Buckets S3, SQS, SNS e assim por diante. Em vez disso, pensamos em eventos unidirecionais.
Como isso é diferente dos eventos do CloudWatch?
Não é!
É a mesma tecnologia “por baixo dos panos” que a AWS usa para despachar eventos gerados pelos serviços da AWS que você já usa. Para citar AWS:
“Eventos CloudWatch e EventBridge são o mesmo serviço e API, mas EventBridge fornece mais recursos.” — AWS
O CloudWatch Events habilitou sua arquitetura a responder a eventos gerados pelos serviços da AWS que você usa, e embora haja funcionalidade para gerar seus próprios eventos e usar cron e rate triggers — esta não era a função primária do CloudWatch Events.
Dito isso, antes do EventBridge formalizar a abordagem, algumas arquiteturas Serverless começaram a usar eventos CloudWatch para ter um conceito de EventBus “hackeado”.
Default vs Custom Event Bus
Cada conta da AWS sempre tem pelo menos 1 EventBus, o EventBus default, que contém os eventos clássicos do CloudWatch para alterações nos serviços da AWS. O EventBridge também permite que sua arquitetura crie seu(s) próprio(s) EventBus(es), e é aqui que o verdadeiro poder do EventBrige entra em ação.
Por meio do AWS Console ou por meio de soluções IaC como o Serverless Framework, você pode criar EventBuses para suas necessidades arquitetônicas e fazer com que os eventos que entram nesses Buses acionem funções Lambda específicas. Isso é uma virada de jogo para simplificação da comunicação entre microsserviços e nos ajuda a avançar em direção ao paradigma orientado a eventos.
EventBridge Schema Registry
“O Schema Registry do Amazon EventBridge armazena a estrutura do evento — ou schema — em um local central compartilhado e mapeia esses esquemas para o código Java, Python e Typescript, de modo que seja fácil usar eventos como objetos em seu código.” — AWS
Quando microsserviços são gerenciados por equipes diferentes, a comunicação entre essas equipes pode ser difícil. Por exemplo, se você tiver uma equipe de pagamento processando pagamentos de clientes e uma equipe de marketing que deseja acionar uma pesquisa de acompanhamento 2 (duas) semanas após a compra, essas duas equipes precisarão se coordenar para garantir que o e-mail de pesquisa seja acionado.
No entanto, e se formos orientados por eventos e for apenas o caso de ambas as equipes ouvirem um evento “SUCESSO NO PAGAMENTO” — bem, com uma arquitetura baseada em EventBridge nós podemos!
Agora, e se a equipe de marketing pudesse saber exatamente qual evento ouvir e a estrutura digitada do evento (campos de nome, sobrenome e e-mail…) sem nem mesmo ter que falar com a outra equipe?
Ou o desenvolvedor nem precisar deixar sua IDE?
Bem, felizmente a AWS estendeu a funcionalidade do EventBridge com o Amazon EventBridge Schema Registry. O Schema Registry não apenas permite que você crie e gerencie Schemas por eventos, mas também gera automaticamente Schemas por eventos que trafegam por qualquer EventBus, inferindo seu esquema a partir das instâncias de Event. Esses esquemas estão no formato OpenAPI, mas também podem ser baixados como código fonte tipadas para TypeScript, Java e Python.
Como começar com EventBridge?
Bem, o primeiro passo é uma mudança de mentalidade para começar a pensar sobre sua arquitetura em termos de eventos, passando a ser orientada a eventos. Conduzir um workshop de Event Storming é uma ótima maneira de gerar uma lista dos principais eventos que seu sistema precisa processar em termos de domínio de negócios. Esses eventos podem ajudá-lo a identificar os limites do microsserviço em seu sistema.
A partir daqui, é o caso de criar um Custom Event Bus e filtrar e encaminhar os eventos certos para os destinos certos.
Criar um Custom Event Bus é extremamente simples na versão mais recente do Serverless Framework:
Simplesmente adicionando uma trigger EventBridge em uma função, a estrutura Serverless criará automaticamente esse novo EventBus personalizado (neste caso, “application-bridge”). Além disso, ele definirá uma regra para que a Função Lambda seja disparada nos eventos que passam por este EventBus com o atributo de origem correto (neste caso “custom.hello”).
Podemos verificar como isso funciona com um script JS simples:
Observação: o disparo de Lambdas por meio do EventBus é obviamente diferente do disparo por meio de HTTP. Os desenvolvedores não podem contar com o CURL/Postman para acionar suas funções facilmente durante o desenvolvimento. Portanto, isso está na lista de pendências para que o projeto sls-dev-tools seja capaz de “injetar eventos” rápidamente e repetidamente.
Conclusões
Eu mesmo, junto com muitos na comunidade Serverless, consideramos EventBridge a maior coisa que aconteceu para arquiteturas Serverless desde Lambda.
As arquiteturas Serverless funcionam melhor quando são estruturadas de forma orientada a eventos, e o EventBridge era a peça do quebra-cabeça que faltava para fazer isso bem.
EventBridge simplifica a comunicação entre serviços e equipes, reduz o acoplamento entre as aplicações e nos ajuda a evitar o Monólito Distribuído (Distributed Monolith).
É hora de tratar os eventos como cidadãos de primeira classe (First-Class Citizens), e EventBridge é a ferramenta para fazer isso.
No Theodo, agora estamos iniciando todos os nossos projetos Serverless com EventBridge por padrão!
This is a translation of the original article “EventBridge: The key component in 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!
