Microsserviços: tudo que você precisa saber!

Seu time precisa criar novos componentes para uma aplicação core da sua empresa e atender requisitos de negócios em constante evolução? Ou atualizar uma aplicação monolítica para linguagens mais recentes? Entregas de alta complexidade são o principal indicador de que sua empresa precisa partir para uma arquitetura de microsserviços no desenvolvimento de novas soluções.

Então, se você está sofrendo com atraso em entregas de alta complexidade ou quer criar aplicações mais tolerantes a falhas, continue comigo neste guia completo sobre microsserviços.

O que é e como funcionam os microsserviços?

Microsserviços são uma abordagem de arquitetura e organização para a criação, desenvolvimento ou atualização de softwares através de pequenos serviços independentes, que gerenciam seu próprio banco de dados e que se comunicam por meio de uma interface bem definida usando APIs leves. 

Nessa abordagem, a aplicação é decomposta por suas funções básicas para que cada função possa ser criada, aprimorada e implementada de maneira independente das outras.

Porém, a arquitetura de microsserviços é mais complexa do que acoplar funções essenciais de uma aplicação de maneira flexível, pois temos o fator humano totalmente envolvido aqui, na forma como as equipes de desenvolvimento são estruturadas. 

A comunicação entre os microsserviços precisa preparar a aplicação para falhas inevitáveis, garantir escalabilidade futura e integração de funcionalidades novas. Como um framework de arquitetura, os microsserviços devem ser distribuídos entre pequenas equipes autossuficientes. Assim, caso aconteçam mudanças na equipe, a aplicação não será corrompida por completo.

Qual a diferença entre microsserviços da arquitetura monolítica?

Enquanto que na arquitetura de microsserviços a aplicação é decomposta, na arquitetura monolítica todas as funções do software estão acopladas. A principal vantagem da arquitetura de microsserviços é que uma falha em um dos microsserviços não compromete os demais, já que cada um deles é executado independentemente.

A abordagem monolítica fazia parte do ciclo de garantia de qualidade, desde a atualização total da versão de atacado, até mesmo após as alterações mais insignificantes. O resultado é que, se alguma das partes atualizadas causasse erros, era necessário desativar a aplicação inteira, reverter a escala e corrigir o problema. Isso acontecia porque o código-fonte da aplicação monolítica era incorporado em uma única unidade de implantação, como .war ou .ear. 

Dá pra imaginar o quanto isso atrasava o trabalho e a evolução da aplicação, certo? Conforme as empresas sentiam a necessidade de lançar mais rapidamente suas aplicações ou atualizações de software para o mercado, novas formas de lidar com o código foram se tornando mais comuns, tais como a chamada arquitetura orientada a serviço (SOA).

O que Microservices tem a ver com SOA?

A arquitetura de microsserviços é bastante parecida com a arquitetura orientada a serviço (SOA), bem conhecida pelos desenvolvedores de software como método para fugir dos problemas das aplicações monolíticas. 

Na arquitetura SOA, os serviços individuais são organizados em torno de um processo de negócios específico através de protocolo de comunicação, como SOAP, ActiveMQ ou Apache Thrift, para que sejam compartilhados por meio de um Enterprise Service Bus (ESB). Quando reunidos em um pacote integrado por meio de um ESB, esses serviços formam uma aplicação.

Em SOA, a decomposição da aplicação em serviços individuais já permite criar, testar e ajustar os serviços de maneira simultânea, eliminando os ciclos de desenvolvimento monolíticos. O problema é que a centralização da comunicação em um ESB representava um ponto único de falha para o sistema inteiro — basicamente, outra estrutura monolítica que podia congestionar todo o ciclo de desenvolvimento.

Então, qual a diferença entre SOA e microsserviços? Diferentemente dos serviços em SOA, os microsserviços podem se comunicar entre si, normalmente de maneira stateless, tornando os softwares mais tolerantes a falhas e menos dependentes de um único ESB. Além disso, os microsserviços podem se comunicar por meio de interfaces de programação de aplicações (APIs), o que traz flexibilidade para que as equipes de desenvolvimento escolham as ferramentas que desejarem.

Qual a diferença entre microsserviços e API?

Microsserviços são um estilo de arquitetura para web service, em que a funcionalidade é dividida em pequenos serviços da web. Já as APIs são os frameworks através dos quais os desenvolvedores podem interagir com uma aplicação da web. 

Nos últimos anos, as APIs públicas se estabeleceram como produtos de negócio, já que a possibilidade de integração entre aplicações aumenta a satisfação e a retenção dos clientes. Por isso, seu apelo é duplo para a maioria das empresas.

Em geral, os microsserviços se comunicam através de APIs. Além disso, elas podem ser usadas para expor os dados e funcionalidades de uma aplicação para terceiros, o que permite integrações poderosas e a evolução contínua da aplicação. Nesse sentido, o que há é uma sobreposição entre APIs e microsserviços.

Microsserviços e containers

Levando em consideração a história da SOA, conseguimos ver que a arquitetura de microsserviços é uma evolução de uma ideia que já existia. Em parte, os microsserviços só se tornaram viáveis graças aos avanços nas tecnologias de conteinerização, que permitem executar várias partes de uma aplicação de maneira independente no mesmo hardware e com um controle muito maior sobre os componentes individuais e ciclos de vida. 

Com as APIs e as equipes de DevOps, os microsserviços em containers são os pilares das aplicações nativas em nuvem.

Quando usar microsserviços?

O exemplo das aplicações cloud native, que mencionamos acima, é um bom ponto de partida. Em geral, os microsserviços são indicados para aplicações que precisam de alta disponibilidade e escalabilidade. Além disso, eles podem ser usados para atualizar aplicações complexas compostas por vários componentes, como sistemas legados. 

Por isso, se você é gestor de infra e está planejando migrar uma aplicação escrita em arquiteturas tradicionais para microsserviços, mas ainda tem dúvidas se essa é a melhor solução, sugiro o uso dessa arquitetura na equipe de desenvolvimento da sua empresa sempre que precisar: 

1. Escalar ou implementar um componente individual rapidamente
2. Reescrever sistemas legados em linguagens mais atuais
3. Aprimorar a performance de um monolito a nível de sistema e de negócio
4. Quebrar uma aplicação muito grande em funções menores

Se você não tem certeza se seu time atual está pronto para dar esse passo, considere pensar sobre os seguintes tópicos:

• Sua equipe já tem maturidade para usar devOps ou agile?
• Como a tecnologia vai impactar no desenvolvimento da aplicação?
• Existem especialistas para configurar e implementar a nova arquitetura?
• A escala da aplicação está no core do negócio e vai ser expandida?
• Quais os custos dessa movimentação para o setor e para a empresa?

Vantagens e desvantagens da arquitetura de microsserviços

Chegou a hora de decidir se essa arquitetura é a melhor escolha para sua empresa? Confira os prós e contras dos microsserviços:

Prós:

• Lançar aplicações e atualizações com mais agilidade para o mercado
• Escalar rapidamente à medida que a demanda aumenta
• Dimensionar corretamente os custos de um recurso
• Criar aplicações resistentes a falhas e com alta disponibilidade
• Atualizar, testar e voltar para a versão anterior sempre que precisar
• Integrações cada vez melhores com outras aplicações já disponíveis
• Liberdade para escolher a melhor ferramenta para solucionar um problema específico
• Reutilizar o código de um serviço já escrito para uma nova funcionalidade
• Possibilidade de usar APIs em qualquer linguagem e aumentar o uso de open source na sua empresa

Contras:

• Aumento dos custos com infraestrutura para manter os vários serviços disponíveis
• Necessidade de dedicar mais tempo para a compilação das dependências entre serviços
• Testes de integração e end-to-end são mais importantes e desafiadores para a equipe
• O controle de versões deve ser mais rigoroso para não gerar incompatibilidades
• Automação na implementação é central, já que o número maior de serviços inviabiliza uma implementação manual
• Gerar logs centralizados dos serviços para viabilizar a gestão da aplicação
• A depuração remota por meio do seu ambiente de desenvolvimento integrado (IDE) local não funciona bem quando há muitos serviços

Veja que a maior parte dos contras são, na verdade, desafios para a equipe de desenvolvimento. Por isso, a dica para times que estão começando agora a explorar a arquitetura de microsserviços é começar com funções ou aplicações menos críticas e menores para identificar onde estão os gaps de conhecimento.

Se você é gestor de infra, recomendo a leitura deste infográfico que vai te ajudar a evoluir o mindset da sua equipe de desenvolvimento para a aplicação de arquiteturas mais complexas e eficientes, como a de microsserviços. Boa leitura!