Complexity Hell: Quando o produto se torna maior que a arquitetura, TDC Connections 2022

Quando se fala de microserviços é muito comum focar em como construir essa arquitetura do zero, ou em como migrar para ela dado um monolito. Mas o que acontece quando a própria arquitetura de microserviços se torna legada? Venha aprender nessa palestra como reconhecer e lidar com essa situação.

Transcript

1. Complexity Hell Quando o produto se torna maior que a arquitetura Jéssica Bonson 2022
2. • 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
3. Tópicos 1. Monolithic Hell 2. Complexity Hell 3. Como lidar com a complexidade?
4. Monolithic Hell
5. • Monolito é uma boa solução para um produto simples Arquitetura de Monolito
6. • …então novas demandas por features chegam Arquitetura de Monolito e isso é bom, quer dizer que o produto foi um sucesso!
7. • …e mais demandas… Arquitetura de Monolito o que esse produto fazia mesmo?
8. • Monolito é uma boa solução para um produto simples • …e quando o produto deixa de ser simples? Monolithic Hell
9. • Tentar entender o sistema é intimidador • Baixa produtividade ◦ Testes lentos, filas para deploy, incidentes constantes, testes manuais, conflitos em merges… • Bugs em produção são comuns ◦ E é normal levar dias para achar e consertar eles • Baixa escalabilidade e desperdício de recursos ◦ Uma parte do sistema precisa de mais memória, outra de mais CPU… • Baixa resiliência e tolerância a falhas • Sistema com techstack e bibliotecas desatualizadas Como saber se você está em um?
10. • Monolitos ainda são uma boa opção para aplicações simples. • É possível atrasar a deterioração do monolito ◦ Com boas práticas de desenvolvimento de software ◦ Mantendo o código modular ◦ Boa cobertura de testes automatizados ◦ Balanceando entrega de features com débitos técnicos Disclaimers!
11. • A medida que uma aplicação se torna mais complexa, uma arquitetura de microserviços permite mais escalabilidade, resiliência e produtividade. Arquitetura de Microserviços
12. • Também existe ‘Monolithic Hell’ para microserviços! Mais Disclaimers!
13. Complexity Hell
14. • Quando se fala em microserviços é comum focar em como construir a arquitetura do zero, dados os requisitos de produto ou a partir de um monolito. • Mas e se a própria arquitetura de microserviços se torna legada? Complexity Hell
15. • Tentar entender o sistema é intimidador • Baixa produtividade ◦ Dependências entre serviços, serviços inchados, responsabilidades espalhadas… • Bugs em produção são comuns ◦ Bugs que se espalham entre serviços ainda podem levar dias para achar e consertar • Baixa escalabilidade e desperdício de recursos ◦ Uma parte de um serviço precisa escalar com requisições sync, outra com async, outra usa mais CPU… • Baixa resiliência e tolerância a falhas • Sistema com techstack e bibliotecas desatualizadas Os sintomas são parecidos
16. • Os mesmos cuidados com monolito também se aplicam para microserviços. ◦ modularidade, testes automatizados, boas práticas, não acumular débitos… • Quanto mais complexa a arquitetura, mais rápido ela se tornará legada. Cuidados
17. Como lidar com a complexidade?
18. • Requisitos funcionais podem ser implementados de muitas formas. • Existe pouca relação entre os requisitos e a arquitetura. Decisões Técnicas “Building Microservices”, Sam Newman
19. • Todas essas arquiteturas atendem os requisitos funcionais. Microserviços com Orquestração Microserviços com Coreografia Monolito “Monolito Distribuído”
20. • Se não há relação entre os requisitos funcionais e a arquitetura, para que ela serve? • A arquitetura define os requisitos não-funcionais do produto, ou seja, a qualidade do sistema. ◦ A decomposição das partes da aplicação e os relacionamentos entre elas determinam as -ilities. Requisitos Não-Funcionais
21. • Velocidade de desenvolvimento ◦ debuggability, maintainability, extensibility, testability, deployability, code quality… • Confiança ◦ availability, reliability, durability, resiliency, fault tolerance, data consistency… • Escalabilidade ◦ modularity, capacity, throughput, performance, operability… • Segurança • Custo Requisitos Não-Funcionais
22. • Complexidade se refere mais ao que é difícil manter do que ao que é difícil fazer. • Tem forte impacto na velocidade de desenvolvimento e na escalabilidade. O que é complexidade?
23. • Não existe ‘bala de prata’, toda decisão de arquitetura tem prós e contras. • Perguntas a serem respondidas: ◦ Os ‘prós’ são necessários? ◦ Os ‘contras’ são aceitáveis? Trade-Offs de Arquitetura
24. • Monolito ou Microserviços • Comunicação Síncrona ou Assíncrona • Banco de Dados SQL ou NoSQL • Usar algo pronto ou fazer do zero • Cuidado com otimização prematura! ◦ É muito comum a complexidade do sistema ser aumentada devido à features e melhorias performance que não são necessários. Exemplos
25. • A arquitetura é algo vivo, que evolui à medida que o produto cresce. • Não temos como impedir as mudanças, mas podemos guiá-las. • É importante discutir e documentar as ‘guidelines’ importantes para a arquitetura do seu contexto, e observar se a arquitetura continua de acordo com elas. Observações Finais
26. Referências
27. Valeu! @jpbonson