O que são microsserviços e como funcionam?
Microsserviços é uma abordagem arquitetônica e organizacional para o desenvolvimento de software em que o software consiste em pequenos serviços independentes que se comunicam usando APIs bem definidas. Esses serviços pertencem a equipes pequenas e autossuficientes.
A arquitetura de microsserviços promove a escalabilidade e acelera o desenvolvimento de aplicativos, oferece suporte à inovação e acelera o tempo de lançamento de novos recursos no mercado.
Diferenças entre as arquiteturas monolítica e de microsserviços
Com uma arquitetura monolítica, todos os processos são fortemente acoplados e executados como um único serviço. Isso significa que, se um processo de aplicativo apresentar um pico de demanda, toda a arquitetura deverá ser dimensionada. A complexidade de adicionar ou aprimorar a funcionalidade de um aplicativo monolítico aumenta à medida que a base de código cresce. Essa complexidade limita a experimentação e dificulta a implementação de novas ideias. Arquiteturas monolíticas aumentam o risco de disponibilidade de aplicativos porque muitos processos dependentes e fortemente acoplados aumentam o impacto de uma única falha de processo.
Com uma arquitetura de microsserviços, os aplicativos são construídos como componentes independentes, executando cada processo de aplicativo como um serviço. Esses serviços se comunicam por meio de interfaces bem definidas usando uma API leve. Os serviços são criados para recursos corporativos e cada serviço desempenha uma função. Como eles operam de forma independente, cada serviço pode ser atualizado, implantado e estendido para atender às necessidades de funcionalidades específicas do aplicativo.
O que é arquitetura monolítica?
Em uma arquitetura monolítica, existem dependências entre serviços de uma mesma aplicação. Grosso modo, este é um “monólito”.
Com a ascensão do desenvolvimento ágil, o modelo de arquitetura monolítica não é mais visto como a melhor escolha para aplicativos robustos, pois alterações em um único serviço podem interferir na funcionalidade de outras funções relacionadas.
Por ser mais antiga, a arquitetura monolítica ainda é utilizada por uma fatia maior do mercado de desenvolvimento de software. Essa situação está mudando exponencialmente.
A diferença entre API e microsserviços
Tanto as APIs quanto os microsserviços são camadas no software. Os conceitos geralmente se sobrepõem, por isso é importante entender que as APIs são camadas criadas para comunicação externa.
Em outras palavras, pode-se dizer que estender o software por outros softwares é um de seus objetivos.
API é minha camada de software responsável pela troca de dados entre qualquer outro software externo. Por outro lado, os microsserviços, que também são camadas, atendem a um propósito diferente: estender o software internamente, facilitar a implantação, proteção e manutenção da funcionalidade.
Arquitetura de microsserviços ou Arquitetura Monolítica?
Transforme aplicativos monolíticos em microsserviços
Não podemos deixar de nos creditar com vários benefícios de optar por usar uma arquitetura de microsserviços, mas ao mesmo tempo, existem muitos obstáculos que precisam ser superados para que isso seja viável em nosso projeto.
Além disso, esses motivos ainda não são suficientes para resolver o problema de dividir o aplicativo em partes.
Antes de apontar alguns motivos importantes para decidir converter um aplicativo monolítico em microsserviços, é importante apontar os pontos positivos de usar um ou outro.
Quando e por que usar microsserviços?
Domínio bem definido
Se você tiver um microsserviço que seja responsável pelo usuário, ele será a única referência para modificar ou fazer qualquer coisa com os dados do usuário.
Se outro serviço responsável pelo login precisar das informações do usuário, ele deverá obtê-las estritamente do microsserviço do usuário.
Escalabilidade
Quando dividimos um grande aplicativo monolítico em vários menores, podemos escalá-los individualmente.
É definitivamente mais estressante, pois o serviço de autenticação é chamado várias vezes durante uma sessão de usuário.
Com microsserviços, podemos dimensionar apenas parte do aplicativo sem precisar dimensionar o aplicativo como um todo, como em uma arquitetura monolítica.
A diversificação de tecnologia
Os microsserviços não precisam necessariamente ser escritos na mesma linguagem de programação.
Se o Python pode ser usado em um microsserviço específico, digamos que seja algo relacionado ao processamento de dados, por que não usá-lo?
Quando e por que usar arquitetura monolítica?
Fácil de desenvolver
O desenvolvimento é simples, especialmente quando o domínio do aplicativo ainda não está claro.
Fácil manutenção
A manutenção também é fácil, especialmente para pessoas que gostam de depurar seu código. Fazer isso com microsserviços é difícil quando você não tem as ferramentas certas.
Apenas um deploy
Há apenas um sistema para inicializar, e não se preocupe se ele quebrará outros sistemas que o consomem, porque não há outros sistemas. É apenas um.
Além disso, é mais simples configurar uma esteira transportadora de CI/CD para aplicações monolíticas.
Fácil de escalar
Há apenas uma maneira de dimensionar um monólito horizontalmente: aumentar o número de máquinas.
Tráfego de rede baixo
Como não há outros serviços com os quais se comunicar, o uso da rede é muito menor. Você percebeu que a principal vantagem de uma arquitetura monolítica é a facilidade de manuseio?
É possível uma união de arquitetura monolítica e microservices?
Sim, sua arquitetura monolítica pode usar microsserviços ou serviços maiores.
Em muitos casos isso faz sentido. Imagine que seu aplicativo monolítico tenha um processo em lote que seja executado de forma assíncrona em horários específicos.
Por que manter esse tipo de serviço em seu código principal? Geralmente é responsável por criar vazamentos de memória em seu aplicativo, dependendo de quanta memória ele usa.
Também usado para prejudicar o tempo de resposta, dependendo de quanto processamento ele consome na máquina.
Outra situação em que faz sentido é um serviço que normalmente faz muito processamento.
O serviço pode ser dimensionado separadamente como outro serviço, geralmente com economias significativas de custo de servidor.
Outro exemplo é o código legado, ou seria melhor se fossem escritos em outra linguagem. Nesses casos, os microsserviços serão uma possibilidade, mas não a única solução.
Microsserviços na Netflix
Josh Evans, da Netflix, explica como eles usam microsserviços no vídeo abaixo:
Neste vídeo, Josh Evans fala sobre como os microsserviços podem se tornar caóticos, mas ao mesmo tempo abrir todo um mundo de possibilidades.
Josh começa com o básico, explicando a estrutura dos microsserviços e os principais desafios e oportunidades.
Se sua decisão é mais para implementar microsserviços, vale a pena ouvi-lo.
Caso de uso de microsserviços
Microsservicos no Spotify
Agora que identificamos o que são esses microsserviços e entendemos como eles diferem de uma arquitetura monolítica, vou contar um pouco sobre minha experiência com essa arquitetura.
Como os microsserviços “poluíam” o mercado de TI, a equipe queria tomar uma decisão e enfrentar esse novo desafio o mais rápido possível.
Esse foi o assunto em todos os momentos, durante uma semana.
Chegando no trabalho, na hora do almoço, na hora do café pós-almoço, nas casas noturnas, e às vezes até de madrugada, quando surgem novos temas para potencializar o tema.
Antes de me posicionar, busco informações para entender melhor o assunto.
Leio artigos e fóruns, assisto a vídeos e conferências internacionais. Todos os ventos estão apontando para o uso de uma arquitetura de microsserviços.
Os microsserviços são a resposta para quase tudo que está por vir, e quase ninguém é contra o seu uso. É quase o mesmo!
No início, fui atraído pela ideia e trabalhei com um grupo de desenvolvedores para transformar nossa grande arquitetura monolítica em pequenos pedaços de microsserviços.
O caminho foi árduo e levou quase que um ano.
Esse processo é gradativo. Criamos um serviço para substituir o serviço no monólito, reproduzi-lo em produção e, quando estiver pronto para funcionar, alteramos o roteamento de uma url específica para alcançar apenas o microsserviço e não atingir mais o aplicativo CORE.
Ao longo do ano, propomos deixar de fora parte do CORE e torná-lo um microsserviço separado.
Às vezes os domínios em nossa aplicação são escritos em menos de 100 linhas ou até mesmo separados em microsserviços.
O calor ainda estava alto, mas naquele momento, comecei a me perguntar se a arquitetura de microsserviços era realmente nossa resposta.
Vale a pena transformar meu monolito em microsserviços?
Para saber quando é o momento certo de transformar um aplicativo monolítico em uma arquitetura de microsserviços, você precisa ter uma ideia do seu projeto para ver se vale a pena trocar o recurso por uma arquitetura mais robusta.
Para fazer isso, você deve medir o quão automatizado é o seu processo de CI/CD.
Se não houver nenhum processo, essa é uma tarefa que deve ser integrada primeiro e, em seguida, uma arquitetura de microsserviço é considerada.
Digo isso porque lidar com o gerenciamento de um grande número de serviços em uma esteira exige um processo quase totalmente automatizado quando se trata de implantação e monitoramento.
Se você ainda acha que uma arquitetura de microsserviços é completamente desnecessária, por que não fazer um compromisso entre as duas?
O meio termo
Vantagens de arquiteturas para software
Como podemos ver, ambas as arquiteturas têm suas vantagens. É importante entender como tirar o máximo proveito de cada serviço e diversificar o portfólio de serviços até certo ponto.
Se não precisar ser totalmente microsserviços, não o faça.
Se for interessante ter uma arquitetura monolítica completa porque os processos são mesclados e não levam a recursos famintos no servidor ou baixa produtividade da equipe, então vá em frente.
Não há necessidade de mudar apenas por estar dentro da hype, certo?
Atualmente, gosto de avançar nessa discussão com meus amigos desenvolvedores. Normalmente não sou fanático e não tomo posições extremas.
Sou Java ou C#, dependendo do contexto, e fico me perguntando: qual é melhor para minhas necessidades?
Sou SQL quando relacionamentos e modelos têm impacto em um projeto. Estou do lado do servidor quando preciso de simplicidade.
Em suma, gosto da arquitetura de microsserviços quando os recursos são escassos e tenho domínios claros. Caso contrário, sei que meu enorme monólito fará o truque.