Defendendo uma arquitetura simples (2022)

• A Wave é uma empresa avaliada em $1.7B (2,3 trilhões de won) com 70 engenheiros (fornece serviços de mobile banking para a África)
• Usa uma arquitetura padrão de app CRUD monolítico em Python com base em Postgres
• Ao resolver problemas partindo de uma arquitetura simples e minimizando a complexidade, os engenheiros puderam se concentrar em entregar valor aos usuários
• O Stack Overflow cresceu com sucesso expandindo um monólito, a ponto de ser adquirido por 1,8 bilhão de dólares

Apesar da eficiência de uma arquitetura simples, a maior parte da mídia prefere arquiteturas complexas

• Em conferências de tecnologia há muitas apresentações sobre arquiteturas complexas baseadas em microsserviços, mas nenhuma sobre monólitos simples
• Muitas empresas imitam tecnologias complexas mesmo tendo aplicações pequenas, e com isso ganham popularidade em conferências e no HN
• A arquitetura que usamos é tão simples que nem precisamos desenhar um diagrama de arquitetura

Como manter a simplicidade

• A Wave usa Python síncrono, o que significa que o processo do servidor fica bloqueado enquanto espera por I/O
• Eles tentaram frameworks assíncronos como Eventlet, mas havia bugs demais, então concluíram que o custo não valia a dor operacional
• Em vez de aumentar a complexidade, tarefas com tempo de execução longo são separadas e processadas por filas
• Para cumprir regras de residência de dados, em alguns países é necessário operar datacenters on-premises
  • Senegal/Costa do Marfim estavam na nuvem, mas Uganda e outros países exigiam on-premises por causa da regulamentação
  • Nesses casos, uma arquitetura simples é muito mais fácil do que uma arquitetura complexa

Construir em vez de comprar

• Como a equipe era pequena, no início preferiam comprar software, mas quando não conseguiam resolver bugs críticos, desenvolviam ferramentas próprias
• Construir ferramentas próprias é uma complexidade que não gostariam de assumir, mas em algumas categorias de produto, mesmo após uma pesquisa bastante ampla, não encontraram fornecedores capazes de oferecer algo adequado
• Às vezes é necessário desenvolver ferramentas próprias e manter expertise interna mesmo fora da competência central

Escolhas que estão sendo reavaliadas

• Estão reavaliando escolhas tecnológicas como RabbitMQ, Celery, SQLAlchemy e Python, pois elas aumentam a complexidade ou o peso de manutenção
• Se começassem uma nova base de código, considerariam essas escolhas com cuidado

Escolhas das quais estão satisfeitos

• Estão satisfeitos com escolhas como GraphQL, protocolos de transporte personalizados e Kubernetes
• O GraphQL tem vantagens como autodocumentação, geração de código e o explorador interativo GraphiQL
• Eles consideram que, ao usar GraphQL, os benefícios superam as desvantagens
  • Vantagens
    • Autodocumentação dos tipos exatos de retorno
    • Os clientes ficam mais seguros graças à geração de código dos tipos exatos de retorno
    • Aumento de produtividade com o explorador interativo GraphiQL
    • Vários apps (app do usuário, app de suporte, app dos agentes da Wave etc.) podem compartilhar em grande parte uma única API, reduzindo a complexidade
    • Com uma linguagem de consulta configurável, o cliente pode buscar exatamente os dados de que precisa em um único round-trip de pacote, sem precisar criar muitos endpoints para fins específicos
    • Elimina o bikeshedding sobre o que deve ser considerado uma API RESTful
  • Desvantagens
    • As bibliotecas de GraphQL não eram muito boas na época em que adotaram GraphQL
    • A codificação GQL padrão é redundante, e como muitos clientes usam baixa largura de banda, eles prestam muita atenção a limites de tamanho
• O Kubernetes é usado para atender aos requisitos de operar datacenters por país

Conclusão

• Ao manter a arquitetura da aplicação o mais simples possível, é possível gastar o orçamento de complexidade (e de pessoal) onde a complexidade ajuda o negócio
• Com a ideia de fazer as coisas da forma mais simples possível, a menos que haja um motivo forte para adicionar complexidade, eles conseguiram construir um negócio considerável com poucos engenheiros, mesmo operando no setor financeiro africano, geralmente visto como um negócio difícil

[secret3056]

Acho que, em vez de "comprar em vez de construir", o certo parece ser "construir em vez de comprar".

Another area is with software we’ve had to build (instead of buy).

[xguru]

Ah, eu fui tentar dar ênfase e o título acabou ficando estranho. Já corrigi. Obrigado.

[savvykang]

Será que as modas mudam de acordo com o ciclo econômico? Independentemente da tendência, começar com um monólito é mais vantajoso para reduzir custos fixos e para a manutenção.

[aer0700]

Uma arquitetura fácil de entender também é fácil de manter.

[mhj5730]

Na minha visão, para qualquer serviço, parece melhor começar com um monólito. Se você já entra definindo MSA desde o início, é desperdício de dinheiro.

[dhlee0305]

"À medida que a complexidade aumenta, os custos (dinheiro, pessoas, tempo...) também aumentam"
"Não tente resolver com uma arquitetura complexa um problema que pode ser resolvido com uma arquitetura simples."

[xguru]

Opiniões no Hacker News

• Conselhos de engenharia sobre microsserviços

  • Microsserviços não são uma estratégia para melhorar desempenho, mas sim uma estratégia potencial de redução de custos e de coordenação de engenharia.
  • Não há grande diferença entre uma aplicação monolítica escalável horizontalmente e microsserviços, exceto quando se quer reduzir a escala de uma funcionalidade específica.
  • Em um app monolítico, é impossível reduzir a escala de apenas uma parte do app.
  • A redução de custos começa em grande escala e exige pelo menos 3 réplicas.
  • Para a maioria das empresas, o benefício real está na coordenação de engenharia.
  • Em um monólito com repositório único, uma equipe pode ser responsável e fazer a gestão, mas em um monólito compartilhado ninguém é dono, o que dificulta a manutenção.

• Palestras sobre microsserviços

  • Em conferências técnicas gerais, houve várias apresentações sobre a complexidade e os efeitos colaterais da arquitetura de microsserviços, mas nenhuma sobre construir um monólito simples.
  • Uma palestra de David Schmitz sobre dicas para fracassar com microsserviços foi marcante, e seu estilo de apresentação bem-humorado é atraente.

• Viés cognitivo e simplicidade

  • As pessoas muitas vezes se concentram em adicionar algo e deixam passar soluções simples.
  • Pesquisas mostram que resolver problemas removendo peças de uma estrutura de Lego, em vez de adicionar, pode ser uma solução melhor.

• Excesso de engenharia e falta de experiência

  • A arquitetura deve ser "simples o suficiente, mas complexa o quanto for necessário", mas alcançar isso exige experiência.
  • A indústria de TI tende a ter pouca experiência, e experiência leva tempo.
  • Engenheiros e gestores com pouca experiência frequentemente usam tecnologias ou métricas desnecessárias.

• Empresas que valorizam equilíbrio entre trabalho e vida pessoal

  • Estou procurando uma empresa em que eu possa focar em melhorar o produto e dedicar o restante do tempo à vida pessoal.

• Experiência pessoal com Dan Luu

  • Dan Luu é generoso ao interagir com fãs do blog e tem grande conhecimento sobre a fronteira entre software e hardware.
  • Ele é muito generoso ao compartilhar seus insights e sua expertise, e aprender com ele é uma experiência extremamente prazerosa.

• A importância de uma arquitetura simples

  • Na maioria dos casos, a arquitetura necessária consiste em componentes básicos como um load balancer com suporte a SSL, vários servidores de aplicação, banco de dados com sharding e fila de mensagens.

• Arquitetura e a estrutura social das equipes de engenharia

  • A arquitetura deve refletir a estrutura social das equipes de engenharia; se isso não for considerado, podem surgir confusão e ineficiência.
  • Grandes repositórios monolíticos e arquiteturas simples podem ser difíceis de gerenciar, e empresas como Google e Meta também desenvolvem muitas ferramentas internamente.
  • Como a arquitetura pode apoiar ou atrapalhar a colaboração entre equipes, a liderança técnica precisa levar isso em conta.

• Preferência por arquitetura simples

  • Arquiteturas simples e monólitos são adequados na maioria dos casos, mas é preciso tomar cuidado para que não surjam problemas causados por I/O síncrono.
  • Bugs de integridade de dados são um problema importante que deve ser evitado em sistemas financeiros.

[dangyup]

Você poderia pedir o link da palestra que aborda as dicas de David Schmitz sobre fracassos em microsserviços?

[xguru]

É https://www.youtube.com/watch?v=r8mtXJh3hzM