Pontos principais
- A arquitetura de microsserviços divide uma aplicação em serviços separados e independentes, cada um responsável por uma função de negócio específica.
- Diferente dos sistemas monolíticos, os microsserviços permitem implantação independente, escalabilidade direcionada e tolerância a falhas isolada entre os componentes.
- Entre os principais benefícios dos microsserviços, estão: escalabilidade, fluxos de trabalho paralelos entre equipes, flexibilidade tecnológica e resiliência da aplicação.
- Definir limites claros de serviço é essencial: serviços mal delimitados criam monólitos distribuídos, que carregam a sobrecarga dos microsserviços com menos benefícios.
- Os microsserviços se encaixam melhor em sistemas grandes e complexos, com requisitos variados de escalabilidade e disponibilidade; sistemas mais simples funcionam bem com uma arquitetura monolítica.
As cargas de trabalho modernas exigem aplicações capazes de lidar com tráfego imprevisível, atualizações frequentes e conjuntos de recursos em expansão. A arquitetura de microsserviços resolve isso ao separar cada microsserviço em bases de código independentes, cada uma implantável e escalável por conta própria.
Este guia explica o que são microsserviços, como eles se diferenciam dos sistemas monolíticos e como decidir se adotar essa arquitetura faz sentido para o seu ambiente.
Como funciona a arquitetura de microsserviços
A arquitetura de microsserviços é uma abordagem de construção de software que divide aplicações em serviços menores e independentes. Em vez de reunir todas as funções em um pacote único, cada recurso da aplicação é mantido como um serviço próprio.
Normalmente, cada microsserviço:
- Responde por um único serviço bem definido e atua apenas dentro dessa função.
- Gerencia o próprio banco de dados, em vez de compartilhar um banco central com o restante do sistema.
- Interage por meio de APIs, para que cada aplicação independente funcione de forma coerente.
- Opera de forma autônoma, o que permite às equipes atualizar, reiniciar ou escalar um serviço sem reimplantar a aplicação inteira.
Essa arquitetura permite às equipes de TI criar um ambiente de aplicação distribuído, em que os componentes evoluem separadamente. Assim, diferentes equipes trabalham em paralelo e escalam serviços conforme a demanda, sem que falhas se propaguem de uma base de código para outra.
Microsserviços e sistemas monolíticos: as diferenças
Para deixar o panorama mais claro, veja a comparação lado a lado:
| Critérios de comparação | Sistemas monolíticos | Microsserviços |
| Estrutura | Toda a funcionalidade vive em uma única base de código e roda como uma unidade. | A funcionalidade é dividida entre serviços independentes que rodam separadamente. |
| Estratégia de implantação | Implantação inicial fácil, mas qualquer mudança exige reimplantar a aplicação inteira. | Cada serviço recebe atualizações de forma independente, sem afetar o sistema todo. |
| Acoplamento de componentes | Os componentes compartilham código, memória e banco de dados. | Os serviços interagem apenas por APIs bem definidas. |
| Escalabilidade | Escalar exige mudar a aplicação inteira. | Serviços individuais podem ser escalados de forma independente para atender à demanda. |
| Tolerância a falhas | Uma única falha pode derrubar a aplicação inteira. | As falhas ficam isoladas por serviço, e o restante do sistema continua funcionando. |
| Stack tecnológica | Presa a uma única linguagem e framework em toda a base de código. | Cada serviço usa a linguagem, o framework ou o banco de dados mais adequado à sua função. |
| Fluxo de trabalho das equipes | Várias equipes precisam trabalhar na mesma base de código, o que exige colaboração entre times a cada release. | Cada equipe responde por serviços específicos e pode desenvolver, testar e lançar em paralelo. |
Os microsserviços costumam ser adotados para sustentar a escalabilidade e as demandas específicas de sistemas em evolução. Essa arquitetura também ajuda as equipes a trabalhar em paralelo, com linguagens ou frameworks diferentes, acelerando os ciclos de desenvolvimento. A tolerância a falhas mais robusta ainda evita que problemas se espalhem pelos componentes.
Mas os mesmos pontos que tornam os microsserviços poderosos também trazem uma complexidade extra indesejada. Como não operam sobre bancos de dados compartilhados, por exemplo, alinhar dados vira um desafio, somado a possíveis falhas de componentes que podem surgir em vários pontos do ambiente.
Como definir limites de serviço na arquitetura de microsserviços
Os limites definem o escopo de um microsserviço: o serviço pelo qual ele responde, a propriedade dos dados e onde essa propriedade termina. Um serviço de pagamentos, por exemplo, se restringe a processar transações e registros de pagamento; o escopo dele não deve invadir fluxos de logística.
Limites bem definidos alinham os microsserviços às funções que eles realmente executam, reduzem dependências entre serviços e sustentam a escalabilidade independente.
Já limites mal definidos geram ruído, porque os serviços passam a chamar uns aos outros o tempo todo, multiplicando tráfego de rede e latência. Isso também cria gargalos de desempenho e aumenta a complexidade do sistema.
Para extrair o máximo da arquitetura de microsserviços, as equipes precisam definir limites alinhados ao negócio desde o início e refiná-los conforme os sistemas evoluem. Sem limites bem desenhados, a organização acaba com um monólito distribuído, que carrega a sobrecarga dos microsserviços sem a flexibilidade.
Como avaliar se a arquitetura de microsserviços faz sentido para você
Antes de apostar nos microsserviços, avalie onde eles se encaixam no seu ambiente, onde não se encaixam e quais alternativas existem além dessa arquitetura.
Quando os microsserviços são a escolha certa
Os microsserviços entregam mais valor em ambientes cujas demandas superam o que os sistemas monolíticos conseguem oferecer. Costumam ser a escolha certa quando a organização se enquadra nos seguintes critérios:
- Sistemas grandes e complexos: considere microsserviços se a aplicação cresceu a ponto de tornar difícil manter ou lançar uma base de código unificada com segurança.
- As equipes precisam trabalhar em paralelo: várias equipes contribuem para o mesmo sistema e a base de código compartilhada virou um gargalo de coordenação.
- Requisitos variados de escalabilidade: algumas funções lidam com cargas muito mais pesadas que outras e precisam escalar por conta própria.
- Entrega contínua é prioridade: escolha microsserviços se a organização lança com frequência e não pode se dar ao luxo de parar durante um novo release.
Quando os microsserviços não são a escolha certa
Em alguns casos, uma arquitetura mais simples entrega resultados melhores, sem a sobrecarga operacional dos microsserviços. Evite microsserviços se o seu ambiente se encaixa nos pontos abaixo:
- Aplicações simples: um monólito dá conta de funcionalidades simples com bem menos infraestrutura e complexidade.
- Equipes sem experiência: sem domínio de orquestração de serviços, monitoramento e tratamento de falhas, a arquitetura causa mais problemas do que resolve.
- Recursos de infraestrutura limitados: microsserviços exigem ferramentas e capacidade que ambientes menores talvez não tenham.
- Escalabilidade independente não é necessária: se os componentes da aplicação escalam juntos em ritmos administráveis, separá-los só adiciona custos desnecessários.
Alternativas à arquitetura de microsserviços
As equipes de TI não precisam escolher apenas entre microsserviços e aplicações monolíticas. Existem vários modelos arquiteturais intermediários, que podem se encaixar melhor conforme os requisitos e a capacidade do ambiente.
Arquitetura de monólito modular
A arquitetura de monólito modular é uma unidade implantável única, organizada em módulos internos separados. Ela ajuda as equipes de TI a unir a separação interna clara dos microsserviços à simplicidade operacional do monólito. Em compensação, essa arquitetura escala como uma unidade só, o que limita a flexibilidade de cada módulo.
Arquitetura orientada a serviços
A arquitetura orientada a serviços (SOA) organiza funcionalidades distintas em serviços compartilhados, muitas vezes coordenados por um enterprise service bus (ESB). Esse modelo incentiva a reutilização de serviços e sustenta integrações em toda a empresa. Ele oferece interoperabilidade entre serviços diferentes, mas lentidões, mudanças ou indisponibilidades no ESB se propagam para todos os serviços conectados.
Entenda a arquitetura de microsserviços antes de adotá-la
Os microsserviços sustentam a escalabilidade e trazem flexibilidade de gerenciamento, mas vêm com uma sobrecarga considerável. Comparar os requisitos do seu ambiente com esses trade-offs é o que mostra se um sistema mais simples atende melhor ou se vale a pena migrar para microsserviços.
