O que fazer quando
microserviços se tornam
monstrinhos?
Jéssica Bonson
Principal Engineer @ iFood TDC Future, Microserviços, 2021
Slide 2
Slide 2 text
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
Slide 3
Slide 3 text
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
Slide 4
Slide 4 text
1 ARQUITETURA DE
MICROSERVIÇOS
Slide 5
Slide 5 text
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
Slide 6
Slide 6 text
“
Uma arquitetura boa vêem
de compreendê-la mais
como uma jornada do que
como um destino.
Robert C. Martin (Uncle Bob)
6
Slide 7
Slide 7 text
Tipos de Comunicação
⬢ Síncrona
⬡ Request / Response
⬢ Assíncrona
⬡ Request / Response
⬡ Eventos
⬡ Acesso comum a dados
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
Fluxo de criação de customer
“Building Microservices”, Sam Newman
Slide 10
Slide 10 text
Fluxo com orquestração
“Building Microservices”, Sam Newman
Slide 11
Slide 11 text
Fluxo com coreografia
“Building Microservices”, Sam Newman
Slide 12
Slide 12 text
2 BOAS PRÁTICAS
Slide 13
Slide 13 text
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
Slide 14
Slide 14 text
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”
Slide 15
Slide 15 text
Como definir os limites?
⬢ DDD (Domain Driven Design)
⬢ Volatilidade
⬢ Sensibilidade dos Dados
⬡ Compliance, privacy, security...
⬢ Requisitos de Performance
⬢ Estruturação da Organização
Slide 16
Slide 16 text
“
I called this ‘onion
architecture’, as it had lots of
layers and made me cry
when we had to cut through
it.
Sam Newman
Slide 17
Slide 17 text
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
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
“
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
Slide 20
Slide 20 text
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
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
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
Slide 23
Slide 23 text
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
Slide 24
Slide 24 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
Slide 25
Slide 25 text
“
One of the secrets to an
effective microservice
architecture is to embrace a
consumer-first approach.
Sam Newman
Slide 26
Slide 26 text
3 PADRÕES PARA
REFATORAÇÃO
Slide 27
Slide 27 text
O que é refatoração?
⬢ Melhorar a estrutura interna, mas mantendo
a funcionalidade
⬡ Diminui bugs
⬡ Aumenta produtividade
⬡ Mais fácil de entender
27
Slide 28
Slide 28 text
Como refatorar?
Processo cíclico com passos curtos, mantendo a funcionalidade.
28
Ler
Entender
Refatorar
Testar
Commit
Slide 29
Slide 29 text
“
If you do a big-bang rewrite,
the only thing you’re
guaranteed of is a big bang.
Martin Fowler
Slide 30
Slide 30 text
Quando refatorar?
⬢ Mudança de foco contínua
⬡ Refactor
⬡ Feature
Atenção em manter o mesmo foco em Pull Requests!
Slide 31
Slide 31 text
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!
Slide 32
Slide 32 text
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
Slide 33
Slide 33 text
Como quebrar um microserviço?
⬢ Motivo?
⬡ Performance? Procure por bottlenecks
⬡ Time to market? Procure por volatilidade
⬡ Complexidade? Procure por domínios
Slide 34
Slide 34 text
Como quebrar?
Slide 35
Slide 35 text
Padrão Strangler Fig
Slide 36
Slide 36 text
REFERÊNCIAS
36
Presentation template by SlidesCarnival
Slide 37
Slide 37 text
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)