Criando soluções orientadas a eventos de alto nível com serverless

Arquiteturas orientadas a eventos não são novas e temos referências sobre isso há alguns anos. Elas são muito eficientes especialmente quando trabalhamos com aplicações distribuídas para ter baixo acoplamento entre elas.
Nessa talk, vou mostro um caminho para criar aplicações de alto nível serverless, tendo como ator principal o EventBridge da AWS. Passo por conceitos do serviço, técnica para definição dos eventos e veremos uma aplicação utilizando tudo isso.

Transcript

1. Criando soluções orientadas a eventos de alto nível com serverless
2. Evandro Pires da Silva • Evangelista de Serverless • AWS Community Builder • Programador desde os 12 anos de idade (com Clipper) • Filho de programador • CTO no X Platform e Head de Pesquisa na Senior Sistemas • Founder e host do Sem Servidor, podcast dedicado ao tema Serverless • Adoro estudar idiomas: inglês, francês e espanhol (WIP) • Marido da Madi, e pai do Teodoro e da Olivia
3. O que é uma arquitetura orientada a eventos?
4. Arquitetura orientada a eventos “An event-driven architecture uses events to trigger and communicate between decoupled services (...). Event-driven architectures have three key components: event producers, event routers, and event consumers.” ~ AWS https://aws.amazon.com/pt/event-dri ven-architecture/ Definição
5. SOA e ESB • Arquitetura Orientada a Serviços, ou do inglês Service-Oriented Architecture (SOA): resolver problema de sistemas distribuídos • Variante: Event-Driven Architecture (EDA) • Enterprise Service Bus (ESB): geralmente associado a SOA - implementa padrões e ferramentas • Orquestração
6. Amazon EventBridge • O Amazon EventBridge é um barramento de eventos sem servidor que torna mais fácil a criação de aplicações orientadas por eventos em escala usando eventos gerados com base em suas aplicações, aplicações integradas de software como serviço (SaaS) e serviços da AWS. O que é?
7. Amazon EventBridge • Lançado em 2019 • CloudWatch Events • Variedade de EventBus ◦ Custom EventBus ◦ Partner EventBus ◦ Default EventBus • Schema Registry
8. Evitando o "Lambda Pinball" • O Lambda Pinball é um anti-pattern Serverless destacado pela ThoughtWorks. • Dificuldade em identificar as fronteiras
9. EventBridge Storming
10. Event 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). Definição
11. EventBridge Storming É o Event Storm em direção a uma arquitetura Serverless orientada a eventos de última geração baseada em EventBridge. Definição
12. 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
13. Guia do EventBridge Storming
14. Guia do EventBridge Storming São 8 etapas • Event Discovery • Temporal Sequencing • Trigger Detection • Categorize Aggregates • Categorize Bounded Contexts • Name Microservices • Create Single EventBus • Build Shared Schema
15. Event Discovery • Identificar os eventos de negócio • Eventos descritos no passado • Não precisa ◦ Agrupar ◦ Remover duplicados
16. Temporal Sequencing • Ordenar por linha do tempo ◦ Esquerda para direita ◦ Simultâneos empilhados • Não é agrupamento • Remover itens duplicados • Iteração “para frente e para trás” para identificar eventos faltantes
17. Trigger Detection • Etapa opcional • Identificação de gatilhos e comandos: pontos do sistema que geram os eventos ◦ Pode incluir atores e sistemas externos
18. • Agrupamento dos eventos • Entidades: nível alto de abstração • Modelagem de eventos e não de dados Categorize Aggregates
19. Categorize Bounded Contexts • Segunda etapa de agrupamento • Eliminar dependência entre os grupos • Já dá “a cara” do que serão os microsserviços 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.
20. Name Microservices • Começa a etapa do time técnico • Microsserviços correspondentes as fronteiras • “Um Lambda não faz um microsserviço” Ben Ellerby • Banco de dados por microsserviço
21. Create Single EventBus • 1 (um) Barramento de Eventos (Bus) • Todos os Eventos devem poder ser consumidos por todos os Serviços
22. Build Shared Schema • “Times devem compartilhar Schema, não dados ou código” Ben Ellerby • Criação de Schema Registry no EventBridge
23. Show me the code
24. Conclusões
25. Conclusões • Overview da técnica ◦ Estudar o Event Storming e DDD ◦ Estudar o EventBridge Storming • Nem sempre serão necessárias todas as etapas, adapte para sua realidade
26. Referências • EventBridge Storming: https://medium.com/serverless-transformation/eventbridge-storming-como-criar-uma-aplica%C 3%A7%C3%A3o-estado-da-arte-totalmente-event-driven-e-serverless-94de52f17f49 • Miro: https://miro.com/app/board/o9J_lDwFaIE=/?invite_link_id=841005573260 • GitHub: https://github.com/epiresdasilva/ecommerce-eventbridge
27. Obrigado! Evandro Pires da Silva @epiresdasilva at Linkedin, GitHub, Twitter