Afinal, O Que São Microsserviços?

Capítulo 1: Definição, prós e contras

Guilherme Virgs Moraes
Jun 10 · 4 min read
Onde há microsserviços há colmeia

Introdução

Há alguns anos, o termo microservices tem sido usado pra descrever uma filosofia de design de arquitetura de software. Embora não exista uma definição precisa, há características comuns entre as implementações que alegam utilizá-la.

Os microsserviços galgaram rapidamente ao topo do mundo de desenvolvimento de software e desempenham um papel importante em muitas organizações hoje em dia. Bem-aventurado aquele que conseguiu passar ileso a essa buzzword. A primeira menção sobre o termo data de muitas eras atrás, contudo, o movimento ganhou força com o artigo de James Lewis e Martin Fowler, seguido pelo livro de Sam Newman e várias palestras.

Ao meu ver, uma das principais contribuições dessa arquitetura, não desmerecendo as demais, foi a introdução do termo monólito — que nada mais é do que uma pedra grande. Então porque não substituir de vez o termo por "pedra grande"? Jamais saberemos! — ao nosso vocabulário do cotidiano e o eterno embate sobre a pronúncia correta dessa palavra.

Conceito

A definição é fundamentalmente simples: distribuir uma aplicação monolítica em diversos pequenos serviços de forma que o conjunto desses serviços entrega o valor final esperado. O quão pequenos e qual a diretriz dessa distribuição são aspectos imprecisos e nebulosos.

Não há nada que defina formalmente o tamanho do microsserviço. Há quem alegue que deve ter no máximo poucas dezenas de linhas de código, possivelmente por meio de FaaS (Function as a service). Enquanto outros alegam que o ideal é iniciar de uma aplicação abrangente e aos poucos descobrir como esculpir os microsserviços. Seja por domínio, funcionalidade ou serviço, dependendo da abstração desejada. Como há uma relação entre o tamanho e a quantidade de componentes, não é raro encontrar ecossistemas com centenas de microsserviços, dependendo do produto.

Uma boa orientação para a questão de quando se deve dividir um microsserviço é a filosofia Unix de criação de utilitários modulares. Algo que se resume em: “faça uma coisa e faça bem”

Justificativa

As leis de Lehman sobre a evolução de software justificam o pensamento por trás do conceito. Dentre outras leis, evidencio, para fins didáticos: o crescimento contínuo, a complexidade crescente e a conservação de familiaridade:

  1. Crescimento contínuo: dado que a demanda é alterada após a concepção de uma funcionalidade, o software deve ser continuamente ampliado para manter a satisfação dos usuários;
  2. Complexidade crescente: conforme o software é alterado sua complexidade aumenta progressivamente; e
  3. Conservação de familiaridade: a velocidade de evolução de um software está intimamente ligada ao grau de familiaridade dos profissionais que o mantém.
Curva exponencial da complexidade de manutenção de software em função do tempo

Analisando as leis acima, concluímos que é apenas questão de tempo para que o desenvolvimento uma aplicação tenha dimensões colossais e sua manutenção seja dramática. Utilizando um pouco de lógica, reordenando as sentenças e uma pitadinha de sal, concluímos:

A manutenção de qualquer aplicação tende ao impossível

Eu concordo plenamente com a minha afirmação acima.

Sejam meses, sejam décadas. É inevitável como a gravidade. Uma alternativa é assegurar que as aplicações permaneçam micro, particionando-as de acordo com o domínio e conforme a diretriz acordada.

Esse é o cerne da filosofia de microsserviços. Domínios distintos, na medida do possível, devem compreender serviços distintos. Busca-se, através da coreografia de minúsculos serviços distribuídos, a implementação das funcionalidades do sistema.

Curioso pensar que a solução passa pela distribuição enquanto o próprio Martin Fowler alega:

Prós e contras

Assim como toda solução arquitetural, a filosofia de microsserviços possui pontos positivos e pontos negativos:

Prós:

Contras:

  • Distribuição: como mencionado anteriormente, sistemas distribuídos são mais complexos por natureza. Principalmente por conta do risco inerente a a latência e falhas nas chamadas remotas.
  • Consistência eventual: manter consistência de dados em um sistema distribuído é uma tarefa árdua. Todos os sistemas devem ser capazes de lidar com uma inconsistência eventual.
  • Complexidade operacional: é necessário, definitivamente, um time maduro para gerenciar múltiplos serviços e suas respectivas entregas constantes.

Cuidado

Levando em consideração os benefícios elencados, indaga-se: por que não se recomenda a utilização de microsserviços? Afinal, o assunto é frequentemente debatido em conferências; dão títulos a artigos, e cada vez mais organizações estão adotando com sucesso. Ao se cogitar o uso de microsserviços, embora haja vantagens nítidas, também há custos. O peso de cada contra e de cada pró varia de acordo com a estrutura organizacional da empresa; do domínio, da maturidade e conhecimento do time de outros fatores de difícil ponderação que afetam esse balanço. A verdade é que não é incomum que a balança pese mais para a não utilização de microsserviços. O que, por si só, não é necessariamente um problema.

No fim das contas, a familiaridade do time com a solução é mais importante do que a filosofia adotada, seja ela a de microsserviços, seja ela a de monólitos.

Relação de produtividade entre microsserviços e monólitos em função da complexidade do sistema

E mais

Para saber mais sobre as características imprescindíveis ao implementar microsserviços, clique aqui.


Guilherme Virgs Moraes

Written by

I am a doer. Enthusiastic about everything, amazed at the life itself and the desire to evolve everyone's skills. pagehub.me/virgs

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade