Complexity Hell Quando o produto se torna maior que a arquitetura Jéssica Bonson 2022

● 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

Tópicos 1. Monolithic Hell 2. Complexity Hell 3. Como lidar com a complexidade?

Monolithic Hell

● Monolito é uma boa solução para um produto simples Arquitetura de Monolito

● …então novas demandas por features chegam Arquitetura de Monolito e isso é bom, quer dizer que o produto foi um sucesso!

● …e mais demandas… Arquitetura de Monolito o que esse produto fazia mesmo?

● Monolito é uma boa solução para um produto simples ● …e quando o produto deixa de ser simples? Monolithic Hell

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

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

● 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

● Também existe ‘Monolithic Hell’ para microserviços! Mais Disclaimers!

Complexity Hell

● 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

● 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

● 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

Como lidar com a complexidade?

● 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

● Todas essas arquiteturas atendem os requisitos funcionais. Microserviços com Orquestração Microserviços com Coreografia Monolito “Monolito Distribuído”

● 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

● 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

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

● 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

● 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

● 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

Referências

Valeu! @jpbonson