- Artigo sobre os custos e benefícios de migrar de um backend monolítico para uma arquitetura de microsserviços
- À medida que aumenta o número de equipes contribuindo para uma base de código única, os componentes ficam cada vez mais acoplados, reduzindo a produtividade e aumentando a complexidade
- Uma solução para aliviar esses problemas é dividir o backend monolítico em um conjunto de serviços implantáveis de forma independente que se comunicam por API, ou seja, microsserviços
- O termo "micro" é enganoso, já que os serviços não precisam ser "micro". Um termo mais apropriado seria arquitetura orientada a serviços
- Ao decompor o backend em um conjunto de serviços com limites bem definidos, basta uma pequena equipe para desenvolver e operar cada serviço, o que aumenta a velocidade de desenvolvimento da aplicação
- Cada microsserviço pode escalar de forma independente e adotar diferentes stacks de tecnologia conforme suas próprias necessidades, facilitando a experimentação e a avaliação de novas tecnologias
- No entanto, a arquitetura de microsserviços aumenta a complexidade ao adicionar mais partes móveis ao sistema como um todo e exige um certo nível de padronização
- Usar linguagens, bibliotecas e datastores diferentes para cada microsserviço pode transformar a aplicação em uma bagunça difícil de manter, além de dificultar a movimentação de desenvolvedores entre equipes
- Para dar suporte em larga escala a serviços independentes, deve ser fácil criar novos servidores, datastores e outros recursos, o que exige um nível significativo de automação
- Chamadas remotas são caras e introduzem novas formas de falha no sistema, portanto são necessários mecanismos de defesa como timeouts, retries e circuit breakers
- Integração contínua garante que mudanças de código passem por processos automáticos de build e teste antes de serem mescladas na branch principal
- Testes de integração de todos os microsserviços são muito mais difíceis do que testes de um monólito; comportamentos muito sutis e inesperados podem surgir quando serviços individuais interagem entre si
- As equipes que desenvolvem os serviços geralmente também ficam responsáveis pelo suporte a eles, criando atrito entre o trabalho de desenvolvimento e os custos operacionais
- Depurar falhas de sistema fica mais difícil com microsserviços; bons logs e monitoramento em todos os níveis são essenciais
- Quando a aplicação é dividida em serviços separados, o modelo de dados deixa de existir em um único datastore, de modo que geralmente é preciso aceitar consistência eventual
- Em geral, o melhor é começar com um monólito e só dividir quando for difícil definir corretamente as fronteiras entre os serviços
- Só se deve começar com uma abordagem voltada primeiro a microsserviços se já houver experiência com isso e uma plataforma preparada para tal, ou se o tempo necessário para construir essa plataforma já tiver sido considerado
Ainda não há comentários.