Slide 1

Slide 1 text

Complexity Hell Quando o produto se torna maior que a arquitetura 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. Monolithic Hell 2. Complexity Hell 3. Como lidar com a complexidade?

Slide 4

Slide 4 text

Monolithic Hell

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

● 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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Complexity Hell

Slide 14

Slide 14 text

● 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

Slide 15

Slide 15 text

● 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

Slide 16

Slide 16 text

● 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

Slide 17

Slide 17 text

Como lidar com a complexidade?

Slide 18

Slide 18 text

● 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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

● 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

Slide 21

Slide 21 text

● 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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

● 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

Slide 24

Slide 24 text

● 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

Slide 25

Slide 25 text

● 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

Slide 26

Slide 26 text

Referências

Slide 27

Slide 27 text

Valeu! @jpbonson