O que fazer quando microserviços se tornam monstrinhos?, TDC Future 2021

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.

URLs nas referências:
"O que fazer quando o sistema se torna um monstrinho?" https://www.youtube.com/watch?v=yvuT4gc_L6E
"Semantic Versioning 2.0.0 | Semantic Versioning" https://semver.org/
"Microservices (Martin Fowler)" https://martinfowler.com/articles/Microservices
"Refactoring a Monolith to microservices" https://www.nginx.com/blog/refactoring-a-monolith-into-microservices/
"Microservices Choreography vs. Orchestration" https://solace.com/blog/microservices-choreography-vs-orchestration/
"The Twelve-Factor App (traduzido)" https://12factor.net/pt_br/

Transcript

1. O que fazer quando microserviços se tornam monstrinhos? Jéssica Bonson Principal Engineer @ iFood TDC Future, Microserviços, 2021
2. OLÁ! Eu sou Jéssica Bonson (@jpbonson) Principal Engineer @ iFood 2 ⬢ Graduação/Mestrado em Ciências da Computação ⬢ 9+ anos de experiência em techstacks e projetos diversos
3. 1. Arquitetura de Microserviços 2. Boas Práticas a. Modelagem b. Comunicação c. Infraestrutura d. Desenvolvimento 3. Padrões para Refatoração Tópicos
4. 1 ARQUITETURA DE MICROSERVIÇOS
5. O que são microserviços? ⬢ Trade-off Monolíticos vs Microserviços ⬡ Menos acoplamento, mais complexidade ⬢ Não são acoplados por código, mas são acoplados por dados ⬡ Contratos devem ser bem definidos e flexíveis 5
6. “ Uma arquitetura boa vêem de compreendê-la mais como uma jornada do que como um destino. Robert C. Martin (Uncle Bob) 6
7. Tipos de Comunicação ⬢ Síncrona ⬡ Request / Response ⬢ Assíncrona ⬡ Request / Response ⬡ Eventos ⬡ Acesso comum a dados
8. Tipos de Controle de Fluxo ⬢ Orquestração vs Coreografia 8 Serviço Serviço Serviço Serviço Serviço Serviço Serviço Serviço Serviço
9. Fluxo de criação de customer “Building Microservices”, Sam Newman
10. Fluxo com orquestração “Building Microservices”, Sam Newman
11. Fluxo com coreografia “Building Microservices”, Sam Newman
12. 2 BOAS PRÁTICAS
13. Boas Práticas na Modelagem ⬢ Domain-Driven Design (DDD) ⬢ Evitar decomposição prematura ⬢ Preferência para coreografia ⬢ Limites bem definidos entre os serviços 13
14. 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”
15. Como definir os limites? ⬢ DDD (Domain Driven Design) ⬢ Volatilidade ⬢ Sensibilidade dos Dados ⬡ Compliance, privacy, security... ⬢ Requisitos de Performance ⬢ Estruturação da Organização
16. “ I called this ‘onion architecture’, as it had lots of layers and made me cry when we had to cut through it. Sam Newman
17. Boas Práticas na Comunicação ⬢ Usar IDs para trackear a sequência de chamadas ⬢ Evitar comunicação síncrona ⬡ Ponto único de falha ⬡ Latência ⬢ Evitar excesso de comunicação entre serviços 17
18. Boas Práticas na Infraestrutura ⬢ Deploys independentes ⬢ Não compartilhar banco de dados ⬢ “Keep the pipes dumb, and the endpoints smart” ⬢ Circuit Breaker ⬢ Monitoramento ⬢ Evitar caching 18
19. “ We discovered the hard way that systems that just act slow are much harder to deal with than systems that just fail fast. In a distributed system, latency kills. Sam Newman
20. Por que evitar caching? ⬢ Aumenta a complexidade ⬡ “The fewer the caches, the easier to reason about the system and the freshness of data” ⬢ Use caching primariamente para otimização de performance
21. Boas Práticas no Desenvolvimento ⬢ Definir princípios e práticas de arquitetura ⬢ Usar Semantic Versioning ⬢ Bibliotecas compartilhadas e/ou Templates ⬡ Cuidado com acoplamento! ⬢ Seguir Padrões e Frameworks ⬢ Evitar Otimização Prematura ⬢ Evitar breaking changes entre microserviços 21
22. Como evitar breaking changes? ⬢ Expansion changes ⬡ Add new things, don’t remove old things ⬢ Tolerant reader ⬡ The consumer should have flexible expectations ⬢ Right technology ⬡ Pick ones that make backward-compatible changes easier ⬢ Explicit interface ⬢ Catch accidental breaking changes early 22
23. E se não tiver como evitar? ⬢ A) Simular a interface antiga ⬡ Usar versionamento nos endpoints ⬡ Se tiver pressa, transformar payload entre versões ⬡ Monitore o uso ⬢ B) Deployar ambas as versões dos microserviços ⬢ C) Lockstep deployment
24. 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
25. “ One of the secrets to an effective microservice architecture is to embrace a consumer-first approach. Sam Newman
26. 3 PADRÕES PARA REFATORAÇÃO
27. O que é refatoração? ⬢ Melhorar a estrutura interna, mas mantendo a funcionalidade ⬡ Diminui bugs ⬡ Aumenta produtividade ⬡ Mais fácil de entender 27
28. Como refatorar? Processo cíclico com passos curtos, mantendo a funcionalidade. 28 Ler Entender Refatorar Testar Commit
29. “ If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang. Martin Fowler
30. Quando refatorar? ⬢ Mudança de foco contínua ⬡ Refactor ⬡ Feature Atenção em manter o mesmo foco em Pull Requests!
31. Quando não refatorar? ⬢ Não por motivos como “feio” ou “diferente” ⬢ É resolvido com automatização ⬡ ex.: linters ⬢ Complexidade != Qualidade ⬢ Preocupação com performance ⬡ Faça medições de desempenho, não especule!
32. Como priorizar? ⬢ Foco em produtividade, não em “beleza” ⬡ Tempo, bugs, custo… ⬢ Alinhe com o time, não faça sozinho ⬢ Tasks de refatoração devem ter a mesma atenção e debate que tasks de features ⬢ Foque o debate no escopo 32
33. Como quebrar um microserviço? ⬢ Motivo? ⬡ Performance? Procure por bottlenecks ⬡ Time to market? Procure por volatilidade ⬡ Complexidade? Procure por domínios
34. Como quebrar?
35. Padrão Strangler Fig
36. REFERÊNCIAS 36 Presentation template by SlidesCarnival
37. REFERÊNCIAS 37 Presentation template by SlidesCarnival O que fazer quando o sistema se torna um monstrinho? Semantic Versioning 2.0.0 | Semantic Versioning Microservices (Martin Fowler) Refactoring a Monolith to microservices Microservices Choreography vs. Orchestration The Twelve-Factor App (traduzido)
38. VALEU! @jpbonson 38