Upgrade to Pro — share decks privately, control downloads, hide ads and more …

O que fazer quando microserviços se tornam mons...

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/

Jessica Pauli de C Bonson

December 01, 2021
Tweet

More Decks by Jessica Pauli de C Bonson

Other Decks in Technology

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. 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
  5. “ Uma arquitetura boa vêem de compreendê-la mais como uma

    jornada do que como um destino. Robert C. Martin (Uncle Bob) 6
  6. Tipos de Comunicação ⬢ Síncrona ⬡ Request / Response ⬢

    Assíncrona ⬡ Request / Response ⬡ Eventos ⬡ Acesso comum a dados
  7. 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
  8. 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
  9. 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”
  10. Como definir os limites? ⬢ DDD (Domain Driven Design) ⬢

    Volatilidade ⬢ Sensibilidade dos Dados ⬡ Compliance, privacy, security... ⬢ Requisitos de Performance ⬢ Estruturação da Organização
  11. “ I called this ‘onion architecture’, as it had lots

    of layers and made me cry when we had to cut through it. Sam Newman
  12. 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
  13. 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
  14. “ 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. “ One of the secrets to an effective microservice architecture

    is to embrace a consumer-first approach. Sam Newman
  21. O que é refatoração? ⬢ Melhorar a estrutura interna, mas

    mantendo a funcionalidade ⬡ Diminui bugs ⬡ Aumenta produtividade ⬡ Mais fácil de entender 27
  22. “ If you do a big-bang rewrite, the only thing

    you’re guaranteed of is a big bang. Martin Fowler
  23. Quando refatorar? ⬢ Mudança de foco contínua ⬡ Refactor ⬡

    Feature Atenção em manter o mesmo foco em Pull Requests!
  24. 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!
  25. 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
  26. Como quebrar um microserviço? ⬢ Motivo? ⬡ Performance? Procure por

    bottlenecks ⬡ Time to market? Procure por volatilidade ⬡ Complexidade? Procure por domínios
  27. 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)