O blog da AWS
Dissociando a publicação de eventos com o Amazon EventBridge Pipes
As arquiteturas baseada em eventos (Event Driven Architectures – EDAs) ajudam a separar aplicativos ou componentes de aplicativos uns dos outros. O consumo de eventos torna-se um componente menos dependente da localização do remetente ou dos detalhes de implementação. Como os eventos são independentes, eles podem ser consumidos de forma assíncrona, o que permite que o remetente e o destinatário sigam considerações de temporização independentes. O desacoplamento por meio de eventos pode melhorar a agilidade de desenvolvimento e a resiliência operacional ao criar aplicativos distribuídos refinados, que é o estilo mais adequado para aplicativos Serverless.
Muitos serviços da AWS publicam eventos por meio de mecanismos integrados para apoiar a criação de arquiteturas baseada em eventos com uma quantidade mínima de codificação (low code) personalizada. Aplicativos modernos criados com base nesses serviços também podem enviar e consumir eventos com base em sua lógica de negócios específica. Os serviços de integração de aplicativos da AWS, como o Amazon EventBridge ou o Amazon SNS (um serviço gerenciado de publicação e assinatura), filtram esses eventos e os direcionam para o destino pretendido, fornecendo dissociação adicional entre produtor e consumidor do evento.
Publicando eventos
Aplicativos personalizados / customizados que atuam como produtores de eventos geralmente usam a biblioteca do AWS SDK, que está disponível para 12 linguagens de programação, para enviar uma mensagem de evento. No código do aplicativo se constrói o evento como uma estrutura de dados local e especifica para onde enviá-lo, por exemplo, para um barramento de eventos EventBridge.
O código no aplicativo necessário para enviar um evento ao EventBridge é simples e requer apenas algumas linhas de desenvolvimento, conforme mostrado neste método auxiliar (simplificado) que publica um evento de pedido gerado pelo aplicativo:
É provável que um aplicativo chame esse método no contexto de outra ação, por exemplo, ao persistir um pedido recebido em um armazenamento de dados. O código que executa essas tarefas pode ter a seguinte forma:
O código utiliza um objeto de pedido com vários itens na linha (na realidade, isso seria baseado em dados inseridos por um usuário ou recebidos por meio de uma chamada de API), o grava em um banco de dados (por meio de outro método auxiliar cuja implementação não é mostrada) e o envia para um barramento EventBridge por meio do método anterior.
O código causa o acoplamento
Embora esse código não seja complexo, ele tem desvantagens do ponto de vista de arquitetura:
- Ele entrelaça a lógica do aplicativo com a topologia da solução porque o destino do evento, tanto em termos de serviço (EventBridge versus SNS, por exemplo) quanto da instância (o nome do barramento de serviço nesse caso) é definido dentro do código-fonte do aplicativo. Se o destino do evento mudar, você deverá alterar o código-fonte ou, pelo menos, saber qual constante de string é passada para a função por meio de uma variável de ambiente. Ambos os aspectos funcionam contra o princípio da EDA de minimizar o acoplamento entre os componentes porque as mudanças na estrutura de comunicação se propagam no código-fonte do produtor.
- O envio do evento, após a atualização do banco de dados, é frágil porque carece de garantias transacionais em ambas as etapas. Você deve implementar o tratamento de erros e a lógica de repetição para lidar com os casos em que o envio do evento falha ou até mesmo desfazer a atualização do banco de dados. Escrever esse código pode ser entediante e propenso a erros.
- O código com todos os tratamentos de exceção é uma responsabilidade muito grande. Afinal, é daí que vêm os bugs. Em um exemplo real, um método auxiliar semelhante ao código anterior trocou erroneamente o dia e o mês na data do evento, o que gerou um ciclo de debug complexo. Portanto, é melhor evitar o código padronizado para enviar eventos.
Realizar o roteamento de eventos dentro do EventBridge pode diminuir a primeira preocupação. Você pode reconfigurar as regras e os destinos do EventBridge para rotear eventos com um tipo e uma origem especificados para um destino diferente, desde que mantenha o nome do barramento de eventos estável. No entanto, os outros problemas permaneceriam:
Serverless: menos infraestrutura, menos código
Os serviços de integração Serverless da AWS podem diminuir a necessidade de escrever um código de aplicativo personalizado / customizados para publicar eventos por completo.
Um dos principais benefícios dos aplicativos Serverless é que você pode deixar que a nuvem da AWS faça o trabalho pesado por você. Tradicionalmente, associamos a tecnologia Serverless ao provisionamento, escalabilidade e operação da infraestrutura computacional para que os desenvolvedores possam se concentrar em escrever código que gere valor para o negócio.
Os serviços de integração de aplicativos Serverless também podem cuidar das tarefas em nível de aplicativo para você, incluindo a publicação de eventos. A maioria dos aplicativos armazena dados em armazenamentos de dados da AWS, como o Amazon Simple Storage Service (S3) ou o Amazon DynamoDB, que podem emitir eventos automaticamente sempre que uma atualização ocorre, sem nenhum código de aplicativo.
EventBridge Pipes: Eventos sem código de aplicativo
O EventBridge Pipes permite que você crie integrações ponto a ponto entre produtores e consumidores de eventos com etapas opcionais de transformação, filtragem e enriquecimento. Os serviços de integração Serverless combinados com a automação em nuvem permitem que as integrações “ponto a ponto” sejam gerenciadas com mais facilidade do que no passado, o que as torna ideais para esse caso de uso.
Este exemplo aproveita a capacidade do EventBridge Pipes de buscar eventos ativamente de fontes como o DynamoDB Streams. O DynamoDB Streams captura uma sequência ordenada por tempo de modificações em nível de item em qualquer tabela do DynamoDB e armazena essas informações em um registro por até 24 horas. O EventBridge Pipes coleta eventos desse registro e os envia para um dos mais de 14 destinos de eventos, incluindo um barramento EventBridge, SNS, SQS ou API Destinations. Ele também acomoda tamanhos de lote, tempos limite e limitação de taxa quando necessário.
A integração por meio do EventBridge Pipes pode substituir o código personalizado do aplicativo que envia o evento, incluindo qualquer lógica de nova tentativa ou erro. Somente o código a seguir permanece:
Automação como código
Os EventBridge Pipes podem ser configurados a partir da CLI, do AWS Management Console ou do código de automação usando o AWS CloudFormation ou o AWS CDK. Ao usar o AWS CDK, você pode usar a mesma linguagem de programação usada para escrever sua lógica de aplicação e também escrever seu código de automação.
Por exemplo, o seguinte trecho de CDK configura um EventBridge Pipe para ler eventos de um stream do DynamoDB anexado à tabela Orders e os passa para um barramento de eventos do EventBridge.
Esse código faz referência à tabela do DynamoDB por meio da variável orderStable que seria definida quando a tabela fosse criada:
O código de automação define claramente a dependência entre a tabela do DynamoDB e o destino do evento, independente da lógica do aplicativo.
Dissociação/Desacoplamento com a transformação de dados
O acoplamento não se limita às fontes e destinos de eventos. O formato de dados de uma fonte pode determinar o formato do evento e exigir alterações posteriores caso o formato dos dados ou a fonte de dados sejam alterados. Os EventBridge Pipes também podem aliviar essa consideração.
Os eventos emitidos pelo DynamoDB Stream usam o formato nativo e organizado do DynamoDB que inclui informações de tipo, como “S” para cadeias de caracteres ou “L” para listas.
Por exemplo, o evento de pedido no stream do DynamoDB desse exemplo tem a seguinte aparência. Alguns campos são omitidos para facilitar a leitura:
Esse formato não é adequado para processamento posterior porque acoplaria desnecessariamente os consumidores de eventos ao fato de que esse evento se originou de um DynamoDB Stream. O EventBridge Pipes pode converter esse evento em um formato mais facilmente consumível. A transformação é especificada por meio de um parâmetro InputTemplate usando expressões JSONPath. O suporte adicionado do EventBridge Pipes para processamento de listas com curingas se mostra perfeito para esse cenário
Neste exemplo, adicione o seguinte modelo de transformação dentro dos parâmetros de destino ao código CDK anterior (o caractere asterisco corresponde a uma lista completa de elementos):
Essa transformação formata o evento publicado pelo EventBridge Pipes como um evento comercial normal, desacoplando qualquer consumidor de eventos do fato de ter se originado de uma tabela do DynamoDB:
Conclusão
Ao criar aplicativos baseada em eventos, considere se você pode substituir o código do aplicativo por serviços de integração Serverless para melhorar a resiliência do seu aplicativo e fornecer uma separação clara entre a lógica do aplicativo e as dependências do sistema.
O EventBridge Pipes pode ser um recurso útil nessas situações, por exemplo, para capturar e publicar eventos com base nas atualizações da tabela do DynamoDB.
Saiba mais sobre o EventBridge Pipes em https://aws.amazon.com/eventbridge/pipes/ e descubra maneiras adicionais de reduzir o código de aplicativos Serverless em https://serverlessland.com/refactoring-serverless. Para ver um exemplo de código completo, consulte https://github.com/aws-samples/aws-refactoring-to-serverless.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre o autor
Gregor Hohpe
Tradutor
Daniel Abib é Enterprise Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.