Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Complexity Hell: Quando o produto se torna maio...

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.

Jessica Pauli de C Bonson

March 23, 2022
Tweet

More Decks by Jessica Pauli de C Bonson

Other Decks in Technology

Transcript

  1. • 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
  2. • …então novas demandas por features chegam Arquitetura de Monolito

    e isso é bom, quer dizer que o produto foi um sucesso!
  3. • Monolito é uma boa solução para um produto simples

    • …e quando o produto deixa de ser simples? Monolithic Hell
  4. • 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?
  5. • 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!
  6. • 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
  7. • 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
  8. • 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
  9. • 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
  10. • 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
  11. • Todas essas arquiteturas atendem os requisitos funcionais. Microserviços com

    Orquestração Microserviços com Coreografia Monolito “Monolito Distribuído”
  12. • 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
  13. • 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
  14. • 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?
  15. • 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
  16. • 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
  17. • 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