Descubra o que é arquitetura de Microsserviços, conheça seus benefícios e entenda quando vale a pena utilizar este tipo de arquitetura em seus projetos.
Tradicionalmente, a indústria sempre construiu softwares de forma monolítica, ou seja, como um grande e único repositório.
Analisando de forma superficial, isso parece bastante interessante. Todos os desenvolvedores da empresa possuíam todo o software em suas máquinas e acesso a toda base de código.
O deploy normalmente se tornava algo simples uma vez que a aplicação era única, assim como a manutenção de ambientes de desenvolvimento e homologação.
- Ferramentas para desenvolvedores: otimize sua rotina hoje mesmo
- Cultura DevOps: integração de times multi skills
O que é arquitetura de Microsserviços?
Nos últimos anos entretanto, uma nova abordagem para construção de software tem ganhado força: microsserviços.
Ela propõe a construção de uma aplicação não mais como uma única unidade de código e sim como uma suíte de serviços menores e com responsabilidades bem definidas.
Temos diversos repositórios que trabalham de forma independente e que juntos formam a aplicação que resolve o problema abordado.
Desde então, esta tem sido a abordagem mais utilizada no desenvolvimento de novos projetos. Não há um manual para aplicação de microsserviços, nem uma receita de bolo para migração de aplicações monolíticas.
Dessa forma, abordaremos prós e contras de sua utilização, na tentativa de auxiliar na escolha da abordagem mais adequada ao problema a ser solucionado.
Quando usar Microsserviços?
- A utilização de microsserviços facilita o desenvolvimento de múltiplos serviços ao mesmo tempo. Enquanto uma equipe cuida da melhoria de um serviço específico, outra pode, sem maiores percalços, implementar um novo serviço no ecossistema ou modificar um serviço distinto. Documentação e padronização são fatores decisivos para que tudo isso funcione de forma correta e como esperado.
- O deploy é feito de forma individual, ou seja, somente aquele serviço aprimorado precisa ser publicado, não a aplicação como um todo. Isso pode representar um ganho no tempo e na complexidade do deploy.
- Caso algum dos serviços apresente gargalo por algum motivo, ele, e somente ele, pode ser escalado, não é necessário escalar a aplicação inteira. Isso representa uma redução no tempo para resolução de problemas ligados a performance, devido a alto tráfego. O custo também pode ser reduzido, levando em consideração que instanciar um serviço tende a ser mais barato do que instanciar uma nova aplicação completa para solucionar o problema.
- Com cada serviço possuindo uma única responsabilidade, consegue-se controlar melhor a qualidade do software entregue. Os diversos serviços do ecossistema podem ser testados de forma mais rápida e assertiva.
- Existe uma redução da complexidade do código, o que facilita a integração de novos desenvolvedores aos times responsáveis. Um novo membro do time pode se familiarizar de forma mais rápida com os diversos serviços do ecossistema, uma vez que eles tendem a ser mais simples.
- Com o uso de serviços independentes e com baixo ou nenhum acoplamento, há a possibilidade de utilização das melhores linguagens e ferramentas para resolução de cada problema. Esta abordagem permite que você utilize aquilo que melhor se adapta a necessidade da aplicação, isto inclui linguagem, ferramentas e frameworks.
- Caso algum dos serviços do ecossistema falhe, os demais continuarão funcionando. Isso garante que pelo menos parte da sua aplicação permaneça funcionando e realizando suas funções.
Quando não usar Microsserviços?
- Com diversos serviços, a manutenção dos ambientes torna-se mais complexa. É necessário gerenciar as dependências de cada serviço e os instanciar de forma independente.
- A utilização de diversas tecnologias no ecossistema, pode resultar em custo maior de infraestrutura, se comparado a uma aplicação monolítica. A utilização de uma máquina para cada serviço pode tornar a operação muito cara. Containers são uma solução viável e bastante utilizada.
- A utilização de microsserviços adiciona um grau a mais de dificuldade no gerenciamento de instâncias de aplicações. Enquanto em uma aplicação monolítica lidamos basicamente com uma instância, que é a aplicação completa, com microsserviços, muitas vezes, precisamos gerenciar múltiplas instâncias de diversos serviços. Essa complexidade na utilização, estruturação e gerenciamento de sistemas distribuídos deve ser levada em consideração na escolha da abordagem.
- Há a necessidade de definir, implantar e manter uma forma de comunicação entre os serviços. Para isso, são utilizadas normalmente duas estratégias: REST e serviços mensageiros como ActiveMQ e RabbitMQ.
- Com múltiplos pontos de falha, principalmente na comunicação entre os serviços, é necessário estar preparado para monitorar e recuperar instâncias, sempre que necessário. Este ponto é crucial para um uso bem sucedido de microsserviços.
- O maior custo de entrada também pode ser considerado um ponto contra. É necessário um esforço extra para padronização, gerenciamento e manutenção tanto dos serviços quanto dos times envolvidos. A adaptação dos times a nova realidade de desenvolvimento e pensamento leva algum tempo e isso deve ser considerado.
Conclusão: não existe bala de prata
A abordagem de microsserviços tem sido muito debatida e ganhado bastante destaque, entretanto, isso não significa que ela deva ser utilizada para resolver todos os problemas. Isso não se aplica somente a abordagens e arquitetura, mas a tecnologias e frameworks também.
A resposta para a pergunta “qual a melhor abordagem para desenvolvimento de software?” é: depende. Cada um dos modelos citados possui suas particularidades, prós e contras.
O modelo a ser adotado vai depender de fatores como o tipo de problema a ser resolvido, tempo para desenvolvimento, experiência dos times envolvidos e demais recursos disponíveis.
Percebemos, através dos pontos abordados, que a adoção de microsserviços impacta a produtividade dos times envolvidos. A produtividade é impactada negativamente quando tratamos de projetos com baixa complexidade.
Neste caso, o custo extra para implantação e manutenção dos serviços acaba sendo mais prejudicial do que benéfico. Já quando tratamos de projetos com avançado grau de complexidade, o quadro se inverte, a produtividade tende a aumentar.
Sendo assim, é de extrema importância que o problema a ser atacado esteja muito bem definido. Com essa definição, a escolha da abordagem ocorre de forma mais assertiva, uma vez que o projeto tem um objetivo claro.
Com uma análise detalhada e levantamento de prós e contras do uso de uma ou de outra abordagem, a escolha se torna mais simples e tende a ser a ideal.
