As arquiteturas serverless usam um FaaS (Function as a Service/Função como Serviço) como o AWS Lambda. O FaaS oferece aos desenvolvedores a capacidade de enviar o código do seu aplicativo para o provedor de serviços em nuvem e executá-lo de maneira isolada, com todos os detalhes do servidor por baixo dos panos abstraídos de você. Essas funções devem ser invocadas por algum evento/gatilho, seja a invocação direta pelo AWS SDK, através de chamadas HTTP via API Gateway, pelo DynamoDB Stream, Kinesis, Cognito, Alexa ou S3…

A partir desses exemplos de como o FaaS é executado, podemos ver que a adoção do serverless é uma mudança de paradigma mais orientado a eventos.

Uma arquitetura Serverless-First deve tratar os eventos como cidadãos de primeira classe; é a única maneira de realmente abraçar o poder do Cloud-Native.

Há muitos debates sobre como as funções do AWS Lambda devem ser arquitetadas, variando da abordagem monolítica com "uma lambda para governar todas", até uma divisão por serviços ou uma abordagem de micro-serviços/micro-lambda.

Pela minha experiência, quanto mais fina a granularidade de suas funções, melhor o desempenho e a adaptabilidade de sua arquitetura.

Os micro-serviços são difíceis. Gerenciar versões de API, comunicações entre equipes, duplicação de dados e muitos outros aspectos se revelam bem desafiadores.

Então, na abordagem "micro-lambda", com funções de granularidade extremamente fina: como exatamente estamos facilitando nossas vidas?

De fato, teremos muito mais serviços interagindo uns com os outros e respondendo a eventos "cloud-native" e não apenas HTTP.

A chegada do EventBridge

Em 2019, a AWS lançou um novo serviço serverless, o Amazon EventBridge, formalizando o fluxo de eventos por meio de arquiteturas. Isso é feito fornecendo um (ou vários) Event Bus para que os eventos sejam despachados, juntamente com ferramentas para os desenvolvedores interagirem com esses eventos.

O EventBridge foi visto pela comunidade serverless como o maior anúncio desde o AWS Lambda. Isso ocorre porque a comunidade serverless está migrando para arquiteturas orientadas a eventos e o EventBridge foi a peça que faltava no quebra-cabeça serverless orientado a eventos.

Evento: "Uma mudança significativa de estado" - K. Mani Chandy

O EventBridge nos ajuda a afastar solicitações síncronas passadas entre um emaranhado de funções Lambda que resultam em um antipadrão como "Lambda Pinball" com solicitações realizadas entre Lambdas, S3 Buckets, SQS, SNS e assim por diante. Ao invés disso, pensamos em termos de eventos unidirecionais.

Como isso é diferente dos CloudWatch Events?

Na verdade, 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 a AWS:

"O CloudWatch Events e o EventBridge são o mesmo serviço e APIs por baixo dos panos, mas o EventBridge fornece mais recursos." - AWS

O CloudWatch Events permitiu que sua arquitetura respondesse aos eventos gerados pelos serviços da AWS que você usa, e embora exista funcionalidade para gerar seus próprios eventos e usar gatilhos de cron e limites de taxa - essa não era a principal função do CloudWatch Events.

Dito isso, antes de o EventBridge formalizar essa abordagem, algumas arquiteturas serverless começaram a fazer uso de CloudWatch Events e ter "hacky-EventBus".

Event Bus Padrão vs Event Bus Customizado

Toda conta da AWS sempre possui pelo menos 1 Event Bus, chamado de Event Bus padrão, 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 seus próprios Event Bus, e é aí que entra em cena o verdadeiro poder do EventBrige.

Por meio do console da AWS ou de soluções IaC como a Serverless Framework, você pode criar Event Buses para suas necessidades de arquitetura e fazer com que os eventos que entram nessas "zonas de despacho", disparem funções específicas do Lambda. Isso é um divisor de águas na simplificação de comunicação entre micro-serviços e nos ajuda a avançar em direção ao paradigma orientado a eventos.

Fonte da imagem: https://aws.amazon.com/eventbridge/

Registro de esquema do EventBridge

"O registro de esquema do Amazon EventBridge armazena a estrutura de eventos - ou esquema - em um local central compartilhado e mapeia esses esquemas para códigos Java, Python e Typescript, para que seja fácil usar eventos como objetos no seu código." - AWS

Quando os micro-serviç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 duas semanas após a compra, essas duas equipes precisarão se coordenar para garantir que o email da pesquisa seja acionado.

No entanto, imagine se tivermos uma aplicação orientada a eventos, no caso de ambas as equipes, elas podem estar registradas para um evento "PAYMENT SUCCESS" - com uma arquitetura baseada em EventBridge nós podemos fazer isso!

Agora, e se a equipe de marketing pudesse saber exatamente qual evento ouvir e a estrutura do evento (nome, sobrenome e campos de e-mail ...) sem precisar conversar com a outra equipe? Ou sem o desenvolvedor deixar seu editor de texto?

Felizmente, a AWS estendeu a funcionalidade do EventBridge com o Amazon EventBridge Schema Registry. O Registro de esquema não apenas permite criar e gerenciar o esquema de eventos, mas também gera automaticamente o esquema de eventos passando por qualquer Event Bus, inferindo o esquema das instâncias do evento. Esses esquemas estão no formato OpenAPI, mas também podem ser baixados como tipos ou objetos para linguagens totalmente tipadas como TypeScript, Java ou Python.

Como começar com EventBridge?

O primeiro passo é uma mudança de mentalidade para começar a pensar em sua arquitetura em termos de eventos, pensando como ser orientado a eventos. Realizar um workshop de event storming com a equipe é uma ótima maneira de gerar uma lista dos principais eventos que seu sistema precisa processar em termos de domínio comercial. Esses eventos podem ajudá-lo a identificar as divisões de micro-serviço no seu sistema.

A partir daqui, é possível criar um Even Bus Customizado, filtrar e rotear os eventos certos para os destinos certos.

Criar um Even Bus Customizado é extremamente simples na versão mais recente do Serverless Framework:

functions:
  hello:
    handler: functions/hello.main
    events:
      - eventBridge:
          eventBus: application-bridge
          pattern:
            source:
              - custom.hello

Simplesmente adicionando um evento eventBridge a uma função, o Serverless Framework criará automaticamente esse novo Event Bus Customizado (neste caso, chamado de application-bridge). Além disso, ele definirá uma regra para que a função Lambda seja acionada nos eventos que passam por esse Event Bus com o atributo source (neste caso, custom.hello).

Podemos verificar se isso funciona com um script JS simples:

const AWS = require('aws-sdk')

function injection() {
  const eventBridge = new AWS.EventBridge()

  return eventBridge.putEvents({
    Entries: [
      {
        EventBusName: 'application-bridge',
        Source: 'custom.hello',
        DetailType: 'HelloMsg123',
        Detail: '{}',
      },
    ]
  }, (err, data) => {
    console.log(data)
  })
}

injection()

Nota: Invocar Lambdas pelo EventBus é obviamente diferente de invocar via HTTP. Os desenvolvedores não podem user cURL/Postman para acionar suas funções durante o desenvolvimento. Portanto, isso está na lista de pendências do projeto sls-dev-tools para poder "Injetar Eventos" de forma rápida e prática. Veja o progresso no quadro de projetos do GitHub.

Conclusão

Eu mesmo, junto com muitos na comunidade Serverless, vejo o EventBridge como o principal componente em arquiteturas serverless desde o Lambda.

As arquiteturas serverless funcionam melhor quando são estruturadas de maneira orientada a eventos, e o EventBridge foi a peça do quebra-cabeça que faltava para fazer isso muito bem.

O EventBridge simplifica a comunicação entre serviços e equipes, reduz o acoplamento rígido entre elas e nos ajuda a evitar o "monólito distribuído".

É hora de tratar os eventos como cidadãos de primeira classe, e o EventBridge é a ferramenta para fazer isso.

No Theodo, estamos iniciando todos os nossos projetos serverless com EventBridge por padrão!

Créditos

• EventBridge: The key component in Serverless Architectures, escrito originalmente por Ben Ellerby.