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 por 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:
- 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;
- Complexidade crescente: conforme o software é alterado sua complexidade aumenta progressivamente; e
- 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.
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:
A primeira lei sobre a distribuição de objetos é: não distribua seus objetos.
Prós e contras
Assim como toda solução arquitetural, a filosofia de microsserviços possui pontos positivos e pontos negativos:
Prós:
- Fronteiras de módulos bem definidas: uma estrutura modular é favorecida.
- Entrega independente: serviços simples são mais fáceis de serem entregues e, por conta da autonomia, é menos provável que causem falhas no ecossistema inteiro quando dão pane.
- Diversidade tecnológica: é possível utilizar e mesclar a linguagem, os frameworks e as ferramentas mais adequadas para o contexto_._ O que deve ser salientado por promover a programação poliglota e a persistência poliglota.
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] (https://www.thoughtworks.com/insights/blog/microservices-adopt)? 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.
E mais
Para saber mais sobre as características imprescindíveis ao implementar microsserviços, clique aqui. (Pera que ainda estou escrevendo. Juro)