Construindo consumidores ad-hoc para arquiteturas orientadas a eventos

Por Corneliu Croitoru (Media Streaming and Edge Architect) e Benjamin Smith (Principal Developer Advocate, Serverless).

Em janeiro de 2022, a equipe Serverless Developer Advocate lançou Serverlesspresso Extensions, um programa que permite que você contribua para o Serverlesspresso. Esta é uma aplicação multi-tenant orientada a eventos para uma cafeteria pop-up que permite que você faça pedidos pelo seu telefone. Em 2022, o Serverlesspresso processou mais de 20.000 pedidos em eventos de tecnologia ao redor do mundo. O objetivo das extensões Serverlesspresso é mostrar o poder e a simplicidade de evoluir uma aplicação orientada a eventos.

Arquitetura orientada a eventos é um padrão de design que permite aos desenvolvedores criar e evoluir aplicações respondendo a eventos gerados por várias partes do sistema. Para aplicações modernas, a necessidade de abordagens flexíveis e escaláveis é crítica, e a arquitetura orientada a eventos pode fornecer uma solução poderosa.

Esta publicação de blog mostra como construir e implantar uma extensão para uma aplicação orientada a eventos. Ele descreve os benefícios e desafios de evoluir aplicações orientadas a eventos. Também apresenta um exemplo da vida real que foi criado em menos de 24 horas.

Integrações desacopladas

Um benefício chave da arquitetura orientada a eventos é sua capacidade de desacoplar diferentes partes do sistema, tornando mais fácil gerenciar mudanças e evoluir a aplicação. Em aplicações monolíticas tradicionais, mudanças em uma parte do sistema podem afetar toda a aplicação.

Com arquitetura orientada a eventos, você pode alterar partes individuais do sistema sem afetar o resto da aplicação. A arquitetura orientada a eventos também torna mais fácil integrar novas funcionalidades em uma aplicação existente criando novos manipuladores de eventos para responder a eventos existentes. Dessa forma, você pode adicionar novas funcionalidades sem afetar o sistema existente, tornando mais fácil testar e implantar.

Os diagramas a seguir ilustram como adicionar e remover consumidores e produtores sem afetar a aplicação principal.

Adicionando e removendo extensões orientadas a eventos

A Extensão 2 está consumindo eventos do barramento de eventos e emitindo eventos de volta para o barramento. Ela pode ser adicionada à aplicação principal sem criar nenhuma dependência. Quando a extensão 2 é removida, a aplicação principal permanece inalterada.

Em aplicações monolíticas, recursos adicionais podem criar dependências na aplicação principal. Remover esses recursos mantém essas dependências no lugar, tornando mais complexo removê-los.

Adicionando e removendo extensões monolíticas

Colaboração

Em uma aplicação monolítica tradicional, pode ser difícil colaborar com múltiplos desenvolvedores em uma única base de código. Isso pode levar a conflitos, bugs e outros problemas que devem ser resolvidos. Integrar novos recursos e componentes nessas aplicações pode ser desafiador, especialmente quando múltiplos desenvolvedores estão usando tecnologias diferentes. Implantar atualizações também pode ser complexo quando múltiplos desenvolvedores estão envolvidos e diferentes partes da aplicação devem ser atualizadas simultaneamente.

Com aplicações baseadas em eventos, esses desafios são frequentemente menos significativos. Um consumidor bem projetado contém limites de permissões bem definidos. Seus recursos não devem precisar de permissão para interagir com recursos fora da definição da extensão. Isso significa que você pode implantá-los e excluí-los independentemente de outras extensões e da aplicação principal. Isso torna mais fácil colaborar com múltiplos desenvolvedores em diferentes linguagens, runtimes e frameworks de implantação.

Feedback em tempo quase real

Outra característica da arquitetura orientada a eventos é a capacidade de fornecer feedback em tempo real aos usuários. Isso ocorre porque os consumidores podem processar eventos à medida que ocorrem, tornando possível fornecer feedback imediato. Isso pode ser útil em aplicações que lidam com grandes volumes de dados ou interagem com múltiplos usuários, pois podem fornecer atualizações em tempo real e garantir que a aplicação permaneça responsiva.

Uma abordagem alternativa para feedback em tempo quase real é usar processamento em lote. Isso envolve agrupar múltiplos eventos ou pontos de dados em um lote e processá-los. Escolher entre processamento em lote e processamento de dados em tempo real com eventos depende da quantidade de dados sendo processados, dos requisitos de latência e da complexidade da lógica de processamento. O processamento em lote pode ser mais eficiente para grandes volumes de dados, pois reduz a sobrecarga de processar cada evento individualmente, enquanto o processamento de dados com eventos pode ser mais adequado para aplicações em tempo real que requerem baixa latência.

A mais nova extensão Serverlesspresso usa uma abordagem orientada a eventos para obter insights em tempo real sobre a aplicação.

A extensão de tempo médio de espera

Uma nova extensão foi criada por Corneliu Croitoru que calcula a espera média para cada bebida na cafeteria Serverlesspresso. Esta extensão usa AWS Step Functions, DynamoDB e AWS Lambda. O aplicativo exibe os resultados em tempo quase real, permitindo que os clientes vejam quanto tempo podem precisar esperar por seu pedido. A extensão usa o AWS Cloud Development Kit (CDK) para implantação.

A extensão usa o barramento de eventos Amazon EventBridge existente para iniciar um workflow Step Functions. O workflow é acionado pelos eventos de submissão de pedido e conclusão de pedido e calcula o tempo médio de espera para cada tipo de bebida (por exemplo, Caffe Latte). Esta informação é então enviada de volta ao barramento de eventos Serverlesspresso.

O diagrama a seguir ilustra o workflow Step Functions:

Quando um novo evento de submissão de pedido é emitido, o workflow Step Functions persiste o timestamp do evento em uma tabela DynamoDB, um armazenamento de dados chave/valor. Ele usa o ID único do pedido como chave. Quando um evento de conclusão de pedido é emitido, o workflow persiste o timestamp de conclusão no DynamoDB. O workflow então invoca uma função Lambda para calcular a duração média daquela bebida específica usando os últimos 10 pedidos armazenados na tabela DynamoDB.

Esta é a estrutura da tabela DynamoDB:

O workflow envia um evento para o barramento de eventos Serverlesspresso com a duração calculada e o tipo de bebida. Uma regra no barramento de eventos roteia este evento para um tópico IoT, que o publica para a aplicação front-end via uma conexão WebSocket aberta existente. O resultado aparece no front-end:

Abordagens alternativas

Existem várias abordagens alternativas que você poderia usar para construir uma extensão de “espera média” em tempo real sem usar eventos.

Uma dessas abordagens poderia ser usar o DynamoDB como cache para os dados orientados a eventos. Dessa forma, seria possível consultar o banco de dados periodicamente para verificar atualizações. Esta abordagem pode ser implementada adicionando um campo de timestamp aos registros do banco de dados e consultando registros que foram atualizados desde a última vez que você verificou.

Alternativamente, você poderia usar streams do DynamoDB para capturar mudanças à medida que ocorrem em vez de assinar novos eventos diretamente. No entanto, essas abordagens podem enfrentar vários desafios. A extensão exigiria permissão para ler dados da tabela ou stream do DynamoDB. Como o recurso da tabela DynamoDB é definido no template principal da aplicação, isso apresenta desafios de propriedade, limites de permissões e dependências. Isso adiciona complexidade adicional à aplicação, pois a extensão não estaria desacoplada do núcleo.

Os desafios

O maior desafio na construção desta extensão é a mudança necessária na mentalidade do desenvolvedor. Apesar de entender os princípios da arquitetura orientada a eventos desacoplada, não foi até construir uma extensão de arquitetura orientada a eventos que o conceito ficou claro.

Por exemplo, você pode pensar que é necessário implantar a aplicação existente para submeter pedidos, emitir eventos no barramento de eventos da aplicação e interagir com vários recursos principais. A equipe de desenvolvimento teve discussões sobre o grau em que a extensão deveria interagir com componentes de aplicação existentes. Esta não era uma mentalidade orientada a eventos.

Cada nova extensão deve ser baseada inteiramente em eventos. Isso significa que ela só pode interagir com a aplicação principal através do barramento de eventos compartilhado, consumindo e emitindo eventos. Também significa que você poderia escrever a extensão em qualquer runtime, com qualquer framework de infraestrutura como código (IaC), e que deveria ser possível implantar e destruir a pilha de extensão sem nenhum efeito na aplicação principal.

Uma vez que você entende isso, o próximo desafio é a descoberta. Encontrar os eventos certos para consumir pode se mostrar mais difícil do que o esperado. É por isso que documentar eventos à medida que você constrói sua aplicação é importante. O esquema do evento, produtor e consumidor devem ser documentados e evoluir com cada versão do evento. O Catálogo de Eventos Serverlesspresso ajuda a superar isso neste exemplo.

Finalmente, o reprodutor de eventos pode emitir eventos Serverlesspresso realistas no barramento de eventos. Isso substitui a necessidade de implantar a pilha da aplicação principal.

Conclusão

O programa Serverlesspresso Extensions mostra a simplicidade de desenvolver aplicações orientadas a eventos. Construir arquiteturas orientadas a eventos permite integrações desacopladas, tornando mais fácil gerenciar mudanças e desenvolver a aplicação. Também simplifica a colaboração entre múltiplas equipes, pois os consumidores de eventos podem ir e vir independentemente sem afetar o procedimento ou a aplicação principal.

Usando esses princípios, a extensão de tempo médio de espera foi construída e implantada em 24 horas, usando um framework IaC diferente da aplicação principal.

Use o repositório GitHub de extensões Serverlesspresso para ler como construir mais extensões Serverlesspresso.

Para mais recursos de aprendizado Serverless, visite Serverless Land.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

Tradutores

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Sua área de interesse são tecnologias serverless. https://www.linkedin.com/in/nicolastarzia

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock 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 especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/