O que fazer quando microserviços se tornam monstrinhos? [revisado], TDC Innovation, Stadium

[versão revisada e melhorada]

Todo developer na indústria já teve que enfrentar diversos monstrinhos de código e fluxos legados nos sistemas das empresas. Essa palestra compartilha conhecimentos e experiências sobre como lidar e resolver esses problemas em arquiteturas de microserviços. Venha aprender a refatorar fluxos e arquiteturas legadas de forma segura e eficiente, seguindo padrões e boas práticas.

Transcript

1. O que fazer quando microserviços se tornam monstrinhos? Jéssica Bonson 2022
2. • Graduação / Mestrado em Ciências da Computação • 10+ anos de experiências em diversas techstacks e projetos OLÁ! Eu sou Jéssica Bonson Staff Engineer @ iFood
3. Tópicos 1. Arquitetura de Microserviços ◦ O que são, e como evitar que virem monstrinhos? 2. Padrões de Refatoração para Microserviços
4. Arquitetura de Microserviços
5. • Trade-off Monolitos vs Microserviços ◦ Menos acoplamento, mais complexidade • Não são acoplados por código, mas por dados ◦ Contratos devem ser bem definidos e flexíveis O que são microserviços?
6. “Uma arquitetura boa vem de compreendê-la mais como uma jornada do que como um destino.” Uncle Bob
7. • Evite otimização e decomposição prematuras • Busque simplicidade e modularidade Boas Práticas
8. • Síncrona ◦ Request / Response • Assíncrona ◦ Request / Response ◦ Eventos ◦ Acesso comum a dados Tipos de Comunicação
9. • Priorize comunicações assíncronas ◦ Mais paralelismo ◦ Evita acúmulo de latência ◦ Menos acoplamento ◦ Mais resiliência e escalabilidade Boas Práticas
10. • Orquestração Tipos de Controle de Fluxo • Coreografia Serviço Serviço Serviço Serviço Serviço Serviço Serviço Serviço Serviço
11. Fluxo de criação de cadastro de cliente “Building Microservices”, Sam Newman Requisitos funcionais podem ser implementados de várias formas!
12. Implementação técnica com orquestração “Building Microservices”, Sam Newman
13. Implementação técnica com coreografia “Building Microservices”, Sam Newman
14. • Existem várias maneiras de implementar os mesmos requisitos funcionais e não-funcionais de um sistema. ◦ Avalie os trade-offs! Boas Práticas
15. Como definir os serviços? • Várias abordagens: ◦ Domain-Driven-Design (DDD) ◦ Volatilidade ◦ Sensibilidade dos dados ◦ Requisitos de performance ◦ Event-storming ◦ … • O importante é que os limites e responsabilidades sejam bem-definidos
16. O que são limites bem definidos? • Escondem informação • Alta coesão ◦ “The code that changes together, stays together” • Baixo acoplamento ◦ “Avoid chatty communication” • Modularidade • Há um trade-off entre redundância e acoplamento
17. • À medida que a complexidade do sistema aumenta, uma boa definição dos domínios e seus limites é essencial. ◦ Vale a pena investir tempo nisso! Boas Práticas
18. Outras Boas Práticas • Usar IDs para trackear a sequência de chamadas • Deploys independentes ◦ Não compartilhar banco de dados • “Keep the pipes dumb, and the endpoints smart” • Circuit Breaker ◦ É mais fácil lidar com serviços que falham rápido do que aos poucos 1 / 3
19. Outras Boas Práticas • Monitoramento robusto • Evitar caching desnecessário ◦ “The fewer the caches, the easier to reason about the system and the freshness of data” • Definir princípios e práticas de arquitetura ◦ Quais são os requisitos não-funcionais? 2 / 3
20. Outras Boas Práticas • Versionamento ◦ ‘Semantic Versioning’ para bibliotecas e repositórios ◦ Endpoints de APIs ◦ ‘Schema Evolution’ para Kafka • Bibliotecas compartilhadas ◦ Ótimas para funcionalidades técnicas ◦ Péssimas se tiverem regras de negócio • Seguir Padrões e Frameworks já estabelecidos ◦ Evite reinventar a roda 3 / 3
21. Padrões de Refatoração para Microserviços
22. Por que quebrar um microserviço? • Microserviços legados tem problemas muito semelhantes a monolítos legados… ◦ …mas com algumas complexidades a mais • Mindset de “Arquitetura Sacrificável” ◦ O código precisar ser sacrificado é sinal de sucesso do produto ◦ A qualidade ainda é importante ◦ Modularidade é essencial ◦ Evita otimização prematura
23. Como quebrar um microserviço? • Motivo? ◦ Complexidade Procure por domínios ◦ Performance Procure por bottlenecks ◦ Time to market Procure por volatilidade • Trade-off entre benefício e dificuldade da refatoração
24. Como não quebrar um microserviço? • Não faça refatorações “Big Bang” ◦ Além dos riscos ao colocar em produção, também há o risco de nunca colocar em produção. “Se você fizer uma refatoração Big Bang, a única coisa garantida é o Big Bang.” Martin Fowler
25. Tipos de Refatoração • Decomposição ◦ Strangler Fig Pattern ◦ Branch by Abstraction Pattern • Modificação ◦ Parallel Run Pattern ◦ Expand-Contract Pattern • Combinação
26. Strangler Fig Pattern
27. ‘Strangler Fig Pattern’ aplicado em uma arquitetura síncrona. “Monolith To Microservices”, Sam Newman
28. “Monolith To Microservices”, Sam Newman ‘Strangler Fig Pattern’ aplicado em uma arquitetura assíncrona.
29. Branch by Abstraction Pattern • Usado como preparação para o Strangler Fig Pattern “Monolith To Microservices”, Sam Newman
30. Exemplo de uso de ‘Branch by Abstraction Pattern’ “Monolith To Microservices”, Sam Newman
31. Parallel Run Pattern • É importante comparar resultados e acompanhar o uso. • Podem receber as mesmas requisições e só um ser usado, ou funcionar como um canário. Service 1 App Service 1 App Service 2 Service 2 App
32. Expand-Contract Pattern • Exemplo: Renomear um campo A para B 1. Adiciona o campo B, sem usar 2. Escrita tanto em A como em B 3. Leitura apenas em B 4. Aguardar/Corrigir bugs 5. Remover campo A
33. Referências ‘Sacrificial Architecture’, Martin Fowler
34. Complexity Hell: Como escapar? Técnicas para lidar com microserviços legados Extra! - 12 de julho https://materiais.ifood.com.br/event_lunch_and_learn_12072022 (ou shorturl.at/mpGLZ)
35. Valeu! @jpbonson
36. Boas Práticas na Documentação • Usar OpenAPI e AsyncAPI / CloudEvents • “Humane registry” • Obter dados reais dos sistemas • Usar metadados • ‘Health score’ de operação Bônus