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

Slide 1

Slide 1 text

O que fazer quando microserviços se tornam monstrinhos? Jéssica Bonson 2022

Slide 2

Slide 2 text

● 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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Arquitetura de Microserviços

Slide 5

Slide 5 text

● 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?

Slide 6

Slide 6 text

“Uma arquitetura boa vem de compreendê-la mais como uma jornada do que como um destino.” Uncle Bob

Slide 7

Slide 7 text

● Evite otimização e decomposição prematuras ● Busque simplicidade e modularidade Boas Práticas

Slide 8

Slide 8 text

● Síncrona ○ Request / Response ● Assíncrona ○ Request / Response ○ Eventos ○ Acesso comum a dados Tipos de Comunicação

Slide 9

Slide 9 text

● Priorize comunicações assíncronas ○ Mais paralelismo ○ Evita acúmulo de latência ○ Menos acoplamento ○ Mais resiliência e escalabilidade Boas Práticas

Slide 10

Slide 10 text

● 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

Slide 11

Slide 11 text

Fluxo de criação de cadastro de cliente “Building Microservices”, Sam Newman Requisitos funcionais podem ser implementados de várias formas!

Slide 12

Slide 12 text

Implementação técnica com orquestração “Building Microservices”, Sam Newman

Slide 13

Slide 13 text

Implementação técnica com coreograﬁa “Building Microservices”, Sam Newman

Slide 14

Slide 14 text

● Existem várias maneiras de implementar os mesmos requisitos funcionais e não-funcionais de um sistema. ○ Avalie os trade-offs! Boas Práticas

Slide 15

Slide 15 text

Como deﬁnir 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

Slide 16

Slide 16 text

O que são limites bem deﬁnidos? ● 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

Slide 17

Slide 17 text

● À 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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Padrões de Refatoração para Microserviços

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Tipos de Refatoração ● Decomposição ○ Strangler Fig Pattern ○ Branch by Abstraction Pattern ● Modificação ○ Parallel Run Pattern ○ Expand-Contract Pattern ● Combinação

Slide 26

Slide 26 text

Strangler Fig Pattern

Slide 27

Slide 27 text

‘Strangler Fig Pattern’ aplicado em uma arquitetura síncrona. “Monolith To Microservices”, Sam Newman

Slide 28

Slide 28 text

“Monolith To Microservices”, Sam Newman ‘Strangler Fig Pattern’ aplicado em uma arquitetura assíncrona.

Slide 29

Slide 29 text

Branch by Abstraction Pattern ● Usado como preparação para o Strangler Fig Pattern “Monolith To Microservices”, Sam Newman

Slide 30

Slide 30 text

Exemplo de uso de ‘Branch by Abstraction Pattern’ “Monolith To Microservices”, Sam Newman

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Referências ‘Sacriﬁcial Architecture’, Martin Fowler

Slide 34

Slide 34 text

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)

Slide 35

Slide 35 text

Valeu! @jpbonson

Slide 36

Slide 36 text

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