O que são microsserviços?
Microsserviços é um modelo de arquitetura de software que consiste dividir um sistema com muitas funcionalidades em vários pequenos sistemas, cada um deles com uma responsabilidade única e bem definida. Essa arquitetura também é considerada uma evolução do SOA (Arquitetura orientada a serviços)
Benefícios da arquitetura de microsserviços
Existem diversos ganhos nessa abordagem e vamos listar aqui os principais:
Resiliência – Evitar um ponto único de falha (Single Point of Failure)
Antes da arquitetura de microsserviços os sistemas eram escritos de forma monolítica, ou seja, um único sistema tinha todas funcionalidades dentro dele.
O principal problema dessa abordagem é que, caso esse grande sistema (chamado de monólito) fique indisponível, todas as funcionalidades ficam indisponíveis ao mesmo tempo. Isso é conhecido como ponto único de falha.
A principal motivação para escrever seu sistemas utilizando microsserviços é evitar o ponto único de falha.
Uma vez que dividimos um grande sistema (monólito) em vários sistemas menores, se um desses pequenos sistemas ficar indisponível os outros não são diretamente afetados (apenas parte das funcionalidades ficaria indisponível).
Vamos a um exemplo prático disso: Imagine um e-commerce com vários sistemas pequenos e que um deles é responsável apenas por enviar emails. Se esse pequeno sistema ficar indisponível, todas as outras funcionalidades continuam disponíveis (checkout, cálculo de frete, pagamento, cadastro, recomendação de produtos, etc).
Escalabilidade isolada
Em uma arquitetura de microsserviços cada um dos serviços é autônomo e tem uma responsabilidade bem definida. Por conta disso podemos escalar (aumentar recursos) esse serviço isoladamente dos demais.
Já em aplicações monolíticas é necessário escalar o sistema inteiro (todas as funcionalidades) e isso custa bem mais caro uma vez que é necessária uma máquina maior (com mais recursos) para rodar um sistema monolítico
Vamos a um exemplo prático disso: Imagine um e-commerce com vários sistemas pequenos onde um deles é responsável apenas por enviar emails. Se o volume de emails começa a ficar muito alto a ponto de deixar esse sistema lento podemos escalar apenas esse sistema para atender a nova demanda, sem precisar escalar os demais.
Liberdade na escolha de tecnologias
Em aplicações monolíticas o time de desenvolvimento escolhe uma stack de tecnologias para desenvolver o sistema inteiro e fica limitado a essa mesma stack para escrever o código de todas as funcionalidades (mesmo que a linguagem ou banco de dados escolhidos não resolvam muito bem algum problema específico).
Usado microsserviços, cada pequeno sistema criado é independente, e por isso podemos escolher as tecnologias que melhor resolvam o problema que esse sistema se dispõe a resolver.
Vamos a um exemplo prático sobre isso. Imagine um e-commerce com vários pequenos serviços onde dois deles servem para:
- Cadastro de produtos
- Recomendação de produtos para os clientes
Para o primeiro serviço (cadastro de produtos) o time poderia escolher por exemplo uma linguagem de programação onde seja simples realizar CRUDS como Java ou C#, além de um banco de dados relacional como MySQL, SQLServer, Oracle e etc.
Já para o segundo serviço (recomendação de produtos) poderia ser escolhida uma linguagem que lide mais facilmente com algoritmos de machine learning como Python e um banco de dados não relacional como MongoDB ou Dynamo.
Melhorias nos processos de CI/CD
Como cada um dos microsserviços é independente, o código fonte desses sistemas também pode ser isolado. Sendo assim podemos ter um repositório para cada sistema e isolar toda a esteira de CI e CD.
Isso viabiliza ter squads (times) diferentes para cada sistema, ou seja, times especialistas em determinadas funcionalidades que podem manter e evoluir essas funcionalidades isoladamente sem conhecer a fundo os outros sistemas.
Em um sistema monolítico isso é bem diferente, pois todos os desenvolvedores atuam no mesmo código fonte, conflitando código, aumentando o risco de quebrar outras funcionalidades do sistema que utiliza os mesmo arquivos para outra finalidade, disputando a prioridade de publicação com outras equipes e etc.
Reutilização de funcionalidades
Como cada sistema tem uma responsabilidade bem definida, fica mais fácil reutilizar esse sistema em todos os locais onde sua funcionalidade é necessária.
Um sistema de envio de emails em um e-commerce por exemplo pode ser reutilizado em diversas situações como:
- Enviar um email de confirmação de cadastro
- Enviar um email de confirmação de compra
- Enviar um email sobre uma promoção recomendando produtos
- Enviar um email sobre reset de senha
Desafios da arquitetura de microsserviços
Para decidir se vale a pela ou não implementar microsserviços, é necessário conhecer também os pontos negativos dessa arquitetura. Vamos listar os principais a seguir
Logs e Rastreabilidade
Ao usar uma arquitetura de microsserviços, uma jornada simples de um usuário pode passar por diversos sistemas diferentes. Isso pode dificultar a analise de problemas e a rastreabilidade.
Por exemplo: Imagine um e-commerce onde usuários frequentemente realizam compras. O processo de compras pode passar por diversos sistemas como:
- Sistema de cadastro de usuários (signup/login)
- Sistema de cadastro de produtos/estoque
- Sistema de checkout (carrinho / compra)
- Sistema de cálculo de frete
- Sistema de pagamento
- Sistema de envio de e-mails
Se não pensarmos bem em como/onde estruturar e guardar os logs de todos esses sistemas, dificilmente vamos conseguir ter rastreabilidade e pode ser bem complexo analisar logs para entender um processo por inteiro.
Imagine por exemplo analisar os logs dos vários sistemas utilizados no processo de compra citado acima para investigar uma fraude.
Performance
Dividir um sistema em vários sistemas menores exige que tenhamos uma maneira de esses vários sistemas “conversarem” entre si, e isso precisa ser feito através de uma rede.
Sem dúvidas é muito mais lento fazer uma chamada na rede do que seria fazer uma chamada de uma função rodando dentro de uma aplicação monolítica. Isso pode se agravar dependendo de quão distantes fisicamente estão os dois sistemas que precisam se integrar.
É importante lembrar ainda que existe o risco de alguma intermitência na rede causar uma falha na chamada a um sistema.
Bancos de dados distribuídos
Para ser realmente independente, cada um dos microsserviços precisa ter um banco de dados próprio e isolado. Isso quer dizer que as informações sobre os processos da empresa ficam espalhadas em diversos bancos de dados. Isso ainda pode se agravar pois esses diversos bancos de dados podem utilizar tecnologias diferentes.
Com o uso de microsserviços torna-se ainda mais importante implementar estratégias como data lake para sincronizar os dados de todas as aplicações.
Tratamento de erros distribuído
Tratar erros em sistemas distribuído é um processo bem complexo.
Imagine por exemplo um e-commerce que dividiu seus sistemas e optou por separar o sistema de checkout (compras) do sistema de estoque.
Se por algum motivo acontecer um problema na compra e for necessário fazer uma devolução, o item do estoque precisa também ser “devolvido” ao estoque, o que faz com que o time de desenvolvimento precise fazer essa operação de devolução em pelo menos 2 sistemas. Mas e se o sistema de compras fizer a devolução mas ocorrer um erro ao chamar no sistema de estoque? É necessário pensar em formas de tratar esse tipo de erro quando quebramos nossos monólitos em vários sistemas menores
Muitos microsserviços
É preciso tomar cuidado com a quantidade de microsserviços criados pois como visto acima quebrar um monólito em sistemas de mais, pode gerar problemas de performance, analise de dados, rastreabilidade e, além de tudo isso, pode se tornar bem difícil de gerenciar.
Imagine uma equipe de 2 ou 3 desenvolvedores lidando com dezenas de sistemas pequenos escritos cada um com uma linguagem de programação diferente, usando cada um um banco de dados diferente e tendo cada um sua própria esteira de CI e CD.
Esse problema ficou popularmente conhecido como “microservices hell”
Vale a pena utilizar microsserviços?
A escolha de utilizar microsserviços ou não, tem que ser tomada levando em consideração o tamanho da equipe, o momento da empresa, os ganhos e os prejuízos dessa abordagem de arquitetura. Além disso também é importante definir quantos e quais serão os microsserviços a serem construídos para não cair no problema do microservices hell.