Do que são feitos os microsserviços?

Sei que o meme abaixo já virou clichê mas ele faz bastante sentido neste caso, pois este post tenta responder algumas perguntas parecidas. Não sou o grande Sérgio Chapelin mas vou contar aqui como estamos respondendo essas dúvidas no PicPay.

Clichê mas não resisti

Em um dos meus textos favoritos sobre o assunto, Should That Be a Microservice? Keep These Six Factors in Mind, o autor cita como um dos fatores para usarmos esta arquitetura:

The Freedom to Choose the Right Tech for the Job

Esta liberdade para a escolha da melhor tecnologia para resolver cada problema é realmente algo que atrai bastante os times de tecnologia. Mas como diria o Tio Ben, com grandes poderes vêm grandes responsabilidades. Se cada time escolher uma tecnologia e tomar uma decisão pensado apenas em seu problema local é provável que isso gere várias dores de cabeça no futuro. Serviços com diferentes requisitos, diferentes níveis de qualidade e maturidade podem gerar dificuldade de manutenção, evolução e disponibilidade.

Para mitigar estes e outros problemas nos voltamos para algumas literaturas que podem ser consideradas clássicos em relação a arquitetura de microsserviços.

Templates e Chassis

A primeira fonte importante foi o livro Microservices Patterns: With Examples in Java, do Chris Richardson, que também mantém o https://microservices.io/. No livro ele define vários padrões importantes a serem usados, mas os que vou dar destaque são o Service Template e o Microservice Chassis.

Quando iniciamos o desenvolvimento de um aplicativo, geralmente passamos uma quantidade significativa de tempo implementando os mecanismos para lidar com questões transversais, como:

• Configuração externa - inclui credenciais e endereços de rede de serviços externos, como bancos de dados e message brokers;
• Logs - configuração de uma estrutura de registro de logs centralizado;
• Health checks - uma url que algum serviço de monitoramento pode “pingar” para determinar a saúde do aplicativo;
• Métricas - medidas que fornecem uma visão sobre o que o aplicativo está fazendo e como está funcionando;
• Rastreamento distribuído - serviços de instrumentação que atribuem a cada solicitação externa um identificador único que é passado entre serviços, etc.

É comum passar várias horas configurando esses mecanismos. Se você vai gastar meses ou anos desenvolvendo um aplicativo monolítico, o investimento inicial para lidar com questões transversais é insignificante. A situação é muito diferente, no entanto, se você estiver desenvolvendo um aplicativo que segue a arquitetura de microsserviço. Podem existir dezenas ou centenas de serviços e frequentemente você criará novos, cada um dos quais levará apenas dias ou semanas para ser desenvolvido. Você não pode se dar ao luxo de passar alguns dias configurando os mecanismos para lidar com questões transversais.

Para resolver este problema podemos fazer uso do Service Template, criando um template de projeto que pode ser replicado facilmente pelos times. Existem diversas formas de se criar estes templates, desde algo simples como um projeto que pode ser copiado e colado pelos times, um repositório modelo no Github ou algo mais complexo. Aqui no PicPay usamos a funcionalidade de templates do Backstage, que foi a base para a construção do nosso IDP.

Mas usar apenas o Service Template acaba causando outro problema: duplicação de código entre os projetos.

Código duplicado

Ao duplicar o template códigos começam a ser replicados entre os projetos, o que torna difícil a manutenção.

Para resolver este problema é recomendado usarmos o pattern Service Template em conjunto com o Microservice Chassis. Segundo o autor:

"Crie serviços em um framework ou coleção de frameworks que tratem de questões transversais como exception tracking, logging, health checks, configuração externalizada e rastreamento distribuído"

Template e Chassi em conjunto

Agora o template passa a depender de uma série de bibliotecas e frameworks que formam o chassi de microsserviços. Com isso removemos a duplicação, pois os templates passam a usar as libs que fazem parte do chassi. Desta forma, ao atualizar uma lib atualizamos todos os projetos que foram criados a partir do template.

Mas além de código, o Chassi define os componentes que um microsserviço deve ter. Para isso criamos um RFC, um documento de padronização interna, que descreve todos os requisitos obrigatórios e recomendados de um microsserviço. Neste documento temos tópicos como: Autenticação, Autorização, Circuit Break, Rate Limit, Graceful Shutdown, etc. Não vou passar por todos os itens aqui pois tornaria o texto muito grande e além disso, quais itens são importantes depende do contexto da empresa.

De posse dessa documentação, bibliotecas e dos templates que implementam o Chassi, temos uma forma saudável e escalável de padronizar e difundir as boas práticas na construção de microsserviços.

Pronto para a produção

A segunda fonte que estamos usando é o ótimo livro Microsserviços Prontos Para a Produção: Construindo Sistemas Padronizados em uma Organização de Engenharia de Software, da Susan J. Fowler.

A autora passa por diversos tópicos importantes que devem ser levados em consideração para que um microsserviço possa ser colocado em produção e considerado pronto para receber tráfego. Dentre os tópicos, posso citar:

• Estabilidade e confiabilidade;
• Escalabilidade e desempenho;
• Tolerância a falhas e preparação para catástrofes;
• Monitoramento;
• Documentação e compreensão.

Para cada um destes grandes tópicos ela detalha conceitos importantes e recomendações de como os times deveriam dar a devida atenção a eles.

E no final do livro, nos apêndices, é possível encontrar um checklist com perguntas para cada um dos tópicos acima. Estamos usando este checklist para que os times discutam e revisem cada um dos itens e assim preparem seus serviços para atender esses importantes requisitos.

Existem outras literaturas importantes como o Building Microservices do Sam Newman que também é fortemente recomendado.
Concluindo, o recado mais importante aqui é que existem fontes que podem nos ajudar a tornar a arquitetura de microsserviços um ambiente saudável ao invés de caótico, que é a tendência natural se não for algo bem pensado.