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.
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.
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).
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.
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.
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.
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:
Se você não tem certeza se seu time atual está pronto para dar esse passo, considere pensar sobre os seguintes tópicos:
Chegou a hora de decidir se essa arquitetura é a melhor escolha para sua empresa? Confira os prós e contras dos microsserviç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!