Microsserviços são um tipo inovador de arquitetura de software, que consiste em construir aplicações desmembrando-as em serviços independentes. Estes serviços se comunicam entre si usando APIs e promovem grande agilidade em times de desenvolvimento.
Ao longo da carreira de desenvolvedor enfrentamos diversas disputas de tecnologia.
Java vs C#, SQL vs NoSQL e Server-side VS Client-side são apenas alguns exemplos.
Eu, pessoalmente, achava que ficaria ileso dessas disputas, mas há um ano foi decidido o uso de microsserviços em um sistema que foi designado a mim e a minha equipe.
Antes tínhamos uma grande arquitetura monolítica e pisávamos em um terreno relativamente tranquilo.
Mas, como é de praxe no mercado de TI, quando um conceito entra no hype, é necessário dar atenção para ele e novamente entrar em uma nova disputa.
A arquitetura de microsserviços estava com tudo, deixando para trás a antiga forma de arquitetar sistemas grandes e robustos, concentrados num grande “bolo” chamado de aplicação monolítica.
Hoje, gigantes do mercado como Netflix e Spotify, divulgam a receita do sucesso ao transformar sua gigante aplicação em mais de 500 microsserviços.
Por outro lado, alguns velhos conhecidos do mercado ficam indiferentes frente o novo hype, permanecendo com apenas um grande monolítico.
O que são microsserviços?
Quando alguém fala em microsserviços, está falando basicamente em uma arquitetura. Claro, a Arquitetura de Microsserviços.
Com eles, as aplicações são desmembradas em componentes mínimos e independentes.
Diferentemente da abordagem tradicional monolítica em que toda a aplicação é criada como um único bloco, os microsserviços são componentes separados que trabalham juntos para realizar as mesmas tarefas.
Cada um dos componentes ou processos é um microsserviço. A vertente da arquitetura de microsserviços valoriza a granularidade e, claro, uma aplicação bem mais leve.
>>Leitura Recomendada:
Kubernetes: a arquitetura de um cluster
O que é arquitetura monolítica?
Na arquitetura monolítica há uma dependência entre os serviços de uma mesma aplicação. De forma “grosseira” isso é um ‘monolito’.
Com a ascensão do desenvolvimento ágil, o modelo de arquitetura monolítica passou a não ser mais visto como melhor opção para aplicações robustas, uma vez que a alteração de um único serviço pode mexer com o funcionamento de outras features dependentes.
Por ser muito mais antiga, a arquitetura monolítica ainda é usada por uma maior fatia do mercado de desenvolvimento de software. Cenário este, que está mudando exponencialmente.
A diferença entre API e microsserviços
Tanto a API como os microsserviços são camadas dentro de um software. Muitas vezes os conceitos se sobrepõe, por isso é importante entender que a API é uma camada criada para comunicação externa.
Ou seja, pode- se dizer que escalar o software por meio de outros softwares é um dos seus objetivos.
A API é a camada do meu software responsável pela troca de dados entre qualquer outro software externo. Já os microsserviços, que também são camadas, tem um intuito diferente: escalar o software internamente, facilitando implantação, proteção e manutenção de features.
Arquitetura de microsserviços ou Arquitetura Monolítica?
Não podemos deixar de atribuir vários ganhos que tivemos com a escolha de partir para a arquitetura de microsservicos, mas, ao mesmo tempo, muitos obstáculos tiveram que ser vencidos para viabilizá-lo no nosso projeto.
Além disso, os motivos ainda não eram o suficiente para resolver quebrar a aplicação em vários pedaços.
Antes de apontar alguns motivos importantes para tomar a decisão de transformar a aplicação monolítica em microsserviços é importante pontuarmos os pontos positivos de usar um ou outro.
Quando e por que usar microsserviços?
Definição clara de domínios
Se você possui um microsserviço responsável pelo usuário, ele será a única referência para mexer em um dado do usuário, ou performar qualquer operação sobre ele.
Se outro serviço responsável pelo login precisa da informação do usuário, ele tem que estritamente buscá-lo a partir do microsserviço de usuário.
Escalabilidade
Quando quebramos uma aplicação monolítica e grande em várias pequenas, possivelmente conseguimos escalá-las de forma separada.
Supondo que um serviço de autenticação seja chamado várias vezes durante a sessão de um usuário, com certeza o stress sobre ele é maior.
Com microsserviços, podemos escalar apenas uma parte, ao invés de ter que escalar a aplicação como um todo, como ocorre em uma arquitetura monolítica.
A diversificação de tecnologia
Os microsserviços não necessariamente precisam ser escritos usando a mesma linguagem de programação.
Se cabe o uso de Python em determinado microsserviço, digamos que seja algo ligado a processamento de dados, por que não usar?
Quando e por que usar arquitetura monolítica?
Fácil de desenvolver
O desenvolvimento é simples, principalmente quando ainda não são claros os domínios da aplicação.
Fácil manutenção
A manutenção também é simples, principalmente para quem gosta de debugar código. Fazer isso com microsserviços é difícil quando não se tem a ferramenta certa.
Apenas um deploy
Existe apenas um sistema para subir e nenhuma preocupação se este pode quebrar outros sistemas que consomem dele, simplesmente por não existir outros. É apenas um.
Além disso, configurar uma esteira de CI/CD para monolítico também é mais simples.
Fácil de escalar
Só existe uma forma de escalar um monolítico horizontalmente: aumentando o número de máquinas.
Tráfego de rede baixo
Pois como não há outros serviços para se comunicar, o uso de rede é bem menor. Notou que o principal ponto positivo de uma arquitetura monolítica é a facilidade de lidar com ela?
>> Leitura recomendada: Como orquestrar contêineres? Na prática com Docker, Swarm e Portainer.
É possível uma união de arquitetura monolítica e microservices?
Sim, é possível ter microsserviços, ou serviços maiores, que são consumidos pela sua arquitetura monolítica.
Pode fazer muito sentido em diversas situações. Imagine que seu monolítico tenha um processo batch que roda assíncrono em um determinado horário.
Por que manter esse tipo de serviço dentro do seu código core? Ele pode, muitas vezes, ser responsável por gerar memory leak na sua aplicação, dependendo da quantidade de memória que ele usa.
Também por prejudicar o tempo de resposta, dependendo do processamento que ele consome na máquina.
Outro caso que faria sentido é um serviço que costuma realizar grandes processamentos.
Este serviço poderia ser apartado como outro serviço para ser escalado separadamente, muitas vezes gerando grandes economias no gasto com servidor.
Outro exemplo é com códigos legados, ou que seriam melhores se fossem escritos em outra linguagem. Nesses casos os microsserviços seriam uma possibilidade, mas não a única solução.
>>Leitura Recomendada:
Docker na prática – como construir uma aplicação?
Microsserviços na Netflix
Josh Evans, da Netflix, explica certinho no vídeo abaixo como eles trabalham com microsserviços:
Neste vídeo, Josh Evans fala sobre como microsserviços podem ser caóticos, mas ao mesmo tempo abrem um universo inteiro de possibilidades.
Josh começa do básico, explicando a anatomia de um microsserviço e os principais desafios e oportunidades.
Se a sua decisão pende mais para a implementação de microsserviços, vale a pena ouvir o que ele tem a dizer.
Caso de uso de microsserviços
Agora que já estabelecemos o que são os tais microsserviços e já entendemos as diferenças deles para o monolito, vou contar um pouco da minha experiência com essa arquitetura.
Com toda essa febre por microsserviços ‘contaminando’ o mercado de TI, a equipe queria tomar logo a decisão e encarar esse novo desafio.
Esse foi o assunto em todos os momentos, durante uma semana.
Chegando ao trabalho, durante o almoço, durante o cafezinho pós-almoço, nos botecos de saideira e às vezes até na madrugada, quando surgiam novos tópicos para incrementar o tema.
Antes de me posicionar, busquei informações para entender melhor o assunto.
Li artigos e fóruns, assisti a vídeos e conferências internacionais. Todos os ventos apontavam para o uso da arquitetura de microsserviços.
Microsserviços era a resposta para praticamente tudo que viria pela frente, quase não havia pontos de vista que contrariassem seu uso. Era praticamente unânime!
A princípio, me senti atraído pela ideia e, junto com um time de desenvolvedores, trabalhamos para transformar nossa grande arquitetura monolítica em pequenos pedaços de microsserviços.
O caminho foi árduo e levou quase que um ano.
O processo foi gradativo. Criávamos um serviço para substituir aquele que estava no monolítico, jogávamos em produção e, quando estava pronto para funcionar, mudávamos a rota da url específica para atingir apenas o microsserviço, e não mais o da aplicação CORE.
O ano todo nos propusemos a retirar uma parte do CORE para virar um microsserviço separado.
Às vezes tínhamos domínios da nossa aplicação que tinham menos de 100 linhas escritas, que mesmo separadas se tornavam microsserviços.
A febre ainda estava alta, mas, naquele momento, comecei a me questionar se era a arquitetura de microsserviços, de fato, a resposta para nós.
Vale a pena transformar meu monolito em microsserviços?
Para saber se é a hora certa de transformar sua aplicação monolítica em arquitetura de microsserviços você tem que entender um pouco da situação do seu projeto, ver se vale a pena trocar a facilidade por uma arquitetura mais robusta.
Para isso, tem que mensurar o quanto seu processo de CI/CD está automatizado.
Se não houver nem o processo, esta é uma tarefa que tem que ser consolidada antes de mais nada, antes de cogitar a arquitetura de microsserviços.
Digo isso pois lidar com o gerenciamento de inúmeros serviços, tanto na esteira, quando no deploy e monitoramento, exige um processo quase que totalmente automatizado.
Se você ainda está num ponto que julga não ser totalmente necessário usar arquitetura de microsserviços, por quê não fazer o meio termo dos dois?
O meio termo
Como vemos, ambas as arquiteturas têm suas vantagens. É importante entender como você consegue o melhor de cada uma e, de certa forma, diversificar a composição dos seus serviços.
Se não for necessário ser exclusivamente microsserviço, então que não seja.
Se for interessante ter uma arquitetura monolítica por inteiro, pois o processo é consolidado e não gera falta de recursos no servidor, ou má produtividade da equipe, então continue deste jeito.
Não há necessidade de mudar apenas por estar dentro da hype, certo?
Atualmente gosto de levar essa discussão para frente com meus amigos desenvolvedores. Não costumo ser fanático, nem tomar nenhum partido extremo.
Eu sou Java ou C# dependendo do contexto e sempre penso: qual vai me atender melhor no que eu preciso?
Sou SQL quando a relação e modelo o faz diferença no projeto. Sou ServerSide quando preciso de simplicidade.
Em resumo, gosto da arquitetura de microsserviços quando há carência de recursos e tenho bem definidos os domínios. Caso o contrário, sei que meu enorme monolítico pode dar conta do recado.
E vocês, o que tem usado por aí? 🙂
