Migração de Arquitetura

Uma visão prática sobre migração de arquitetura em ambientes reais. Da evolução de um monólito para microserviços até a consolidação em um monólito modular, explorando padrões de migração, métricas, trade-offs e os aprendizados obtidos ao longo do caminho.

Transcript

1. Migração de Arquitetura Como migramos serviços na vida real Luiz Schons
2. Quem aqui trabalha com microserviços? Migração de Arquitetura: A Volta 02 / 59
3. Luiz Schons Senior Software Engineer @ PicPay • Guarapuava - PR • 24 anos • UTFPR • Embaixador do DevParaná GitHub: @sschonss · LinkedIn: luizschons Migração de Arquitetura: A Volta 03 / 59
4. Disclaimer • Isso aqui é opinião, não receita • Cada contexto é único: time, produto, budget • O objetivo é compartilhar aprendizados reais • Não existe bala de prata Migração de Arquitetura: A Volta 04 / 59
5. BLOCO 01 A História Migração de Arquitetura: A Volta 05 / 59
6. O começo • Uma ideia, um dev, um framework, um servidor • Laravel + MySQL + Redis • Deploy por FTP (sim, FTP) • Primeiro cliente em 3 semanas • Funcionava. E era bonito de ver. Migração de Arquitetura: A Volta 06 / 59
7. Crescimento • Time cresce: 5 devs, 80 tabelas • CI/CD substituiu o FTP. Deploy diário • Testes rodando em 4 minutos • Dev novo produtivo em 1 semana • Todo mundo entendia o sistema inteiro "O monolito não estava sofrendo. Ele estava voando." Migração de Arquitetura: A Volta 07 / 59
8. Por que funcionava tão bem? • 1 repo, 1 deploy, 1 banco = pouco overhead • Bug? Stack trace completo, sem rede no meio • Refatoração? IDE encontra tudo, renomeia tudo • Transações ACID de verdade • Simplicidade é uma virtude, não um defeito Migração de Arquitetura: A Volta 08 / 59
9. O monolito clássico Migração de Arquitetura: A Volta 09 / 59
10. As primeiras rachaduras O time cresceu. O sistema, nem tanto. • 10 devs, 120 tabelas, 200k pedidos/mês • Deploy de sexta? Fim de semana perdido • CI que era orgulho agora leva 40 minutos • Dev novo demora 3 semanas pra ser produtivo • Ninguém entende o sistema inteiro mais Migração de Arquitetura: A Volta 10 / 59
11. Blast radius de um monolito acoplado Um bug em um modulo derruba todos os outros Migração de Arquitetura: A Volta 12 / 59
12. O dia a dia ficou pesado • Conflitos de merge: 10 devs no mesmo repo • Times pisando um no pé do outro • Qualquer mudança podia quebrar outra parte • Black Friday: escalar checkout = escalar tudo • Produto frustrado: 'por que demora tanto?' Migração de Arquitetura: A Volta 13 / 59
13. E se a gente migrasse pra microserviços? Migração de Arquitetura: A Volta 14 / 59
14. Antes: o checklist que não fizemos • Temos testes automatizados? • Sabemos quais são nossos domínios? • Temos observabilidade? • Já tentamos resolver internamente? • O time sabe operar sistemas distribuídos? "Se falta algum item, pare. Resolva primeiro." Migração de Arquitetura: A Volta 15 / 59
15. Gestão: Antes de migrar • Defina onde quer chegar: métricas de sucesso • Deploy frequency, lead time, MTTR, custo • Crie um plano de fallback: como voltar? • Saiba quando NÃO fazer • Se não sabe medir, não sabe se melhorou "Migrar sem definir sucesso é turismo arquitetural." Migração de Arquitetura: A Volta 16 / 59
16. BLOCO 02 A Migração Migração de Arquitetura: A Volta 17 / 59
17. A decisão • Conferências dizendo que monolito = legado • Cases de Netflix, Uber, Spotify • Time hypado com tecnologia nova • CTO convencido pelo mercado • Plano: migrar para 12 microserviços Migração de Arquitetura: A Volta 18 / 59
18. O plano: 12 microserviços 12 servicos, 12 repos, 12 pipelines, 12 deploys Migração de Arquitetura: A Volta 19 / 59
19. PRÓXIMO BLOCO Próximo passo Migração de Arquitetura: A Volta 20 / 59
20. Migrando o Checkout com Strangler Migração de Arquitetura: A Volta 20 / 59
21. Padrão 1: Strangler Pattern A planta que envolve a árvore • Metáfora biológica de Martin Fowler • Uma planta cresce ao redor da árvore • Se alimenta dela até substituí-la • A árvore original nunca é derrubada • O sistema novo envolve o legado gradualmente Migração de Arquitetura: A Volta 21 / 59
22. Strangler Fig: Fase 1 - Proxy Nada muda pro usuario. Apenas ganhamos controle do roteamento. Migração de Arquitetura: A Volta 22 / 59
23. Strangler Fig: Fase 2 - Coexistência Canary deployment: trafego gradual, rollback instantaneo Migração de Arquitetura: A Volta 23 / 59
24. Strangler Fig: Fase 3 - Migrado Rota desligada no monolito. Codigo legado removido semanas depois. Migração de Arquitetura: A Volta 24 / 59
25. Strangler: Na prática • O proxy pode ser Nginx, Kong, ou um middleware • Feature flags controlam % do tráfego • Fallback pro monolito se o serviço novo falhar • Monitorar: latência, erros, throughput • Só remove código legado depois de validado Migração de Arquitetura: A Volta 25 / 59
26. Padrão 2: Branch by Abstraction Trocar o motor com o carro andando • Duas implementações coexistem no mesmo codebase • Uma interface define o contrato • Feature flag decide qual implementação roda • Rollback instantâneo: desliga a flag • Controller não muda nada Migração de Arquitetura: A Volta 27 / 59
27. Branch by Abstraction: Passo 1 - Interface Todos os controllers passam a depender da interface, nao da implementacao Migração de Arquitetura: A Volta 28 / 59
28. Branch by Abstraction: Passo 2 - Nova implementação Feature flag roteia entre implementacoes. Rollback = desligar a flag. Migração de Arquitetura: A Volta 29 / 59
29. Branch by Abstraction: O código interface CatalogServiceInterface { public function findProduct(int $id): ProductDTO; public function search(string $query): Collection; } // Service Provider decide qual injetar if (Feature::active('new-catalog')) { $app->bind( CatalogServiceInterface::class, NewCatalogService::class ); } else { $app->bind( CatalogServiceInterface::class, LegacyCatalogService::class ); }
30. Padrão 3: Anti-Corruption Layer Um tradutor entre dois mundos • Serviço novo precisa falar com o legado • Importar models do legado = acoplamento direto • ACL: camada de tradução entre domínios • Serviço novo nunca enxerga o modelo antigo • Mudou o legado? Só a ACL precisa mudar Migração de Arquitetura: A Volta 32 / 59
31. Sem ACL: acoplamento direto Servico novo depende da estrutura interna do legado Migração de Arquitetura: A Volta 33 / 59
32. Com ACL: domínios protegidos Monolito mudou? So a ACL precisa ser atualizada. Migração de Arquitetura: A Volta 34 / 59
33. Anti-Corruption Layer: O código class OrderACL { public function __construct( private MonolithApiClient $api ) {} public function getOrder(int $id): PaymentOrderDTO { // Busca no formato do legado $legacy = $this->api->get("/orders/{$id}"); // Traduz pro dominio de pagamento return new PaymentOrderDTO( orderId: $legacy['id'], amount: $legacy['total_price'] / 100, currency: 'BRL', items: count($legacy['line_items']), ); } }
34. Resumo: quando usar cada padrão Nao existe padrao melhor. Existe o certo pro momento. Migração de Arquitetura: A Volta 36 / 59
35. Gestão: Durante a migração • Métrica de sucesso definida antes de cada módulo • Plano de fallback: feature flag pra voltar • Um módulo por vez: resista à pressão • Dual-running por algumas semanas antes de desligar Exemplo: ”Sucesso = deploy >= 3x/semana + latência p99 <= 200ms" Migração de Arquitetura: A Volta 37 / 59
36. BLOCO 03 A Realidade dos 12 Microserviços Migração de Arquitetura: A Volta 38 / 59
37. O que ganharam vs o que perderam Ganhos • Deploys independentes • Escala seletiva por serviço • Liberdade tecnológica • Ownership claro por time Perdas • Complexidade operacional • 8 devs / 12 serviços + infra • Debugging distribuído • Custos de infra 4x maiores VS Migração de Arquitetura: A Volta 39 / 59
38. O custo real de cada microserviço Multiplica por 12. Esse e o novo baseline operacional. Migração de Arquitetura: A Volta 40 / 59
39. A percepção incômoda • Carrinho e Checkout eram o mesmo contexto • Relatórios e Admin: 2 req/min • Busca: poderia ser Elasticsearch no monolito • Estoque e Catálogo: acoplados demais • 12 serviços pra ~4 contextos reais Migração de Arquitetura: A Volta 41 / 59
40. Hora de medir Deploy freq. 1x/sem 4x/dia Custo infra R$ 3k R$ 12k Incidentes/mês 2 5 Satisfação time 7/10 5/10 Medir é o que permite tomar decisões com dados, não com hype. 42 / 59
41. BLOCO 04 A Volta Migração de Arquitetura: A Volta 43 / 59
42. O momento da virada • Incidente em produção + retrospectiva • Mais tempo mantendo infra do que entregando • A complexidade está matando a velocidade • A pergunta mudou... Migração de Arquitetura: A Volta 44 / 59 O time esta servindo a arquitetura e não a arquitetura o time
43. Quais serviços justificam existir? Migração de Arquitetura: A Volta 45 / 59
44. Revisitando os domínios • Brain Storming com todo o time • Mapearam os domínios reais do negócio • Carrinho + Checkout = mesmo contexto: Vendas • Os 12 serviços não respeitavam as fronteiras • Resultado: 12 serviços pra ~4 contextos reais Migração de Arquitetura: A Volta 46 / 59
45. Mapa de contextos real 4 contextos reais. 12 servicos eram demais. Migração de Arquitetura: A Volta 47 / 59
46. Critérios para voltar Só mantém separado se tem os 3: • 1. Time dedicado: alguém é dono disso? • 2. Domínio próprio: a linguagem é diferente? • 3. Deploy independente com motivo real? • Falta 1? Candidato a voltar. Migração de Arquitetura: A Volta 48 / 59
47. Estratégia 1: Reabsorver como módulo • Serviço volta pro monolito como módulo isolado • Carrinho + Checkout = módulo Vendas • Relatórios + Admin = módulo Backoffice • Busca = módulo Catálogo + Elasticsearch • Boundaries claras, testes isolados, eventos internos Migração de Arquitetura: A Volta 49 / 59
48. Monolito modular: o resultado Modulos isolados, deploy unico, comunicacao via eventos Migração de Arquitetura: A Volta 50 / 59
49. Estratégia 2: Transformar em library • O serviço tem lógica boa mas pouco tráfego • Cálculo de frete: regras complexas, 10 req/min • Extraíram o core como Composer package • Importaram como dependência no monolito • Mesma lógica, sem overhead de serviço Migração de Arquitetura: A Volta 51 / 59
50. De microserviço a library Mesma logica, sem deploy separado, sem infra extra Migração de Arquitetura: A Volta 52 / 59
51. Estratégia 3: Manter separado Quando os 3 critérios são atendidos • Pagamento: PCI compliance, time dedicado • Notificações: assíncrono, escala independente • API Gateway: rate limiting, autenticação • Frete (cotação): APIs externas, latência variável Migração de Arquitetura: A Volta 53 / 59
52. A jornada completa 2 repos, 5 pipelines. Equilibrio pragmatico. Migração de Arquitetura: A Volta 54 / 59
53. Gestão: Na volta também • Métricas de sucesso: custo, incidentes, satisfação • Fallback: se falhar, serviços continuam separados • Consolidar não é 'voltar atrás', é evoluir • O time voltou a entregar features Migração de Arquitetura: A Volta 55 / 59
54. BLOCO 05 Fechamento Migração de Arquitetura: A Volta 56 / 59
55. Para levar pra casa 1 Monolito bem feito > microserviços mal feitos 2 Defina métricas de sucesso antes de migrar 3 Tenha sempre um plano de fallback 4 Migre um contexto por vez 5 Mudar de opnião não é fracasso, é maturidade 6 A melhor arquitetura é a que seu time aguenta Migração de Arquitetura: A Volta 57 / 59
56. Obrigado!