Microservices e a complexidade

Arquitetura de microservices é uma maneira de projetar sistemas que se tornou viável e popular com o avanço da computação distribuída. Abordarei aqui como isso afeta a produção de tecnologia e inovação. Este assunto já foi bastante discutido pela comunidade de desenvolvedores, gerou bastante buzz, por isso quero entregar aqui a experiência e a observação de aspectos culturais e técnicos que vivenciei na Aurum implementando e evoluindo neste assunto.

Em poucas palavras este tipo de arquitetura pode ser definido como: um sistema com suas partes distribuídas em uma rede. Observando apenas esta definição já noto:

3 benefícios em relação às partes:

• Deploy independente
• Tecnologia independente
• Maior encapsulamento e especialização

2 problemas:

• Maior complexidade de infraestrutura (sim, a rede e as máquinas, mesmo que virtuais)
• Adição de um novo domínio de conhecimento

A ESCOLHA

Haverá quem busca os benefícios, quem precisa, quem não precisa e quem deve ficar longe dos problemas. Sobre os benefícios e de como as pessoas dos dois primeiros grupos podem resolver os problemas, alguns pontos.

O deploy independente traz agilidade na entrega contínua. A independência de tecnologia possibilita trabalhar com diferentes sistemas operacionais, diferentes hardwares e diferentes linguagens de programação. O encapsulamento e especialização das partes pode até moldar equipes, com as partes independentes podemos ter como resultado equipes pequenas, especializadas e autônomas.

As pessoas são o maior ativo de uma empresa e não existe nada mais motivador para um programador do que trabalhar com as melhores ferramentas e melhores condições. Quando as pessoas são restritas porque devem se adequar a estrutura maior, pode haver dificuldade para obter inovação de processo e renovação de tecnologias.

O CENÁRIO

Aqui na Aurum eu trabalho na equipe responsável por automatizar a extração e tratamento das informações processuais para os clientes dos softwares da empresa, os quais geralmente são advogados de diversos perfis. Nossos serviços servem funcionalidades para diversos produtos e serviços da empresa, incluindo aplicações legadas. Quando comecei a trabalhar na equipe de robôs o cenário era um sistema monolítico que executava diversas funcionalidades relacionadas a extração e tratamento de dados.

Era impressionante a diversidade de soluções utilizadas, um paraíso para aprender, hackear ou escovar bits. Na figura abaixo, podemos ver que já existia uma separação por 2 serviços: um para fazer a extração dos dados e outro para executar e armazenar os dados do web crawler.

Monolito

QUEBRANDO O MONOLITO

1) Separação do Banco de dados
A primeira ação após definir a estratégia de quebrar o monolito foi separar o banco de dados Mongo para uma instância separada da aplicação

2) Extração da análise de imagens
Precisávamos de um especialista em técnicas de análise de imagens. Um colega nosso sabia de alguém que estava fazendo uma pesquisa nesta área, então investimos em treinar esta pessoa e criar condições para que ela pudesse usar as tecnologias em que está habituado e também pudesse fazer deploy de forma independente da aplicação principal. O resultado foi muito bom, um serviço especializado em análise de imagem que escala de forma independente e tem tecnologia especializada. Tínhamos um problema com consumo excessivo de memória, após esta separação, este problema ocorreu somente na instância de análise de imagens. Sabíamos exatamente onde agir e otimizar.

3) Extração de outros serviços especializados
Também extraímos para serviços separados o escalonador, o navegador headless e o módulo para executar serviços especializados de fornecedores.

Quebrando o monolito

AUTOMAÇÃO E ORQUESTRAÇÃO

Lembra da complexidade no título? Pois é, 5 serviços foram o suficiente para concluirmos que precisávamos investir em técnicas de automação e orquestração dos serviços senão perderíamos o direito de dormir. A primeira boa prática de devops aparece: infrastructure as code. Infraestrutura como código é o mais poderoso recurso de automação. A primeira solução para “codificar infraestrutura” foi usar o docker em todos serviços e rodar eles no Elastic beanstalk da AWS, o qual suporta docker entre outras opções.

Como o Elastic beanstalk não era específico para o docker e tinha limitações como, por exemplo, só poder usar um container por instância então resolvi fazer uma pesquisa. Como o Kubernetes apareceu no nosso radar, resolvi testar ele e o Docker Swarm. Na época o kubernetes era bem mais completo e tinha uma comunidade maior, então rapidamente virou a menina dos nossos olhos. Pela pesquisa feita ele era superior, então migramos tudo para um cluster kubernetes (já estar tudo dockerizado facilitou). O conhecimento adquirido fez evoluirmos em infraestrutura e até impulsionou a criação da área de devops na empresa. Como o nosso devops comentou no post dele.

O resultado é que hoje estamos habituados a já pensar em microservices na análise do software e está cada vez mais fácil jogar para dentro do cluster serviços próprios e de terceiros como bancos de dados, sistemas de monitoramento, sistemas de filas, entre outros.

RESULTADOS E APRENDIZADO

Hoje estamos habituados a analisar se uma funcionalidade é especializada o suficiente para virar um serviço e temos até um método para nomear eles baseado em figuras mitológicas. Mas a implementação dessa arquitetura envolveu diversas fases, abordei aqui as duas primeiras: quebrar o monolito e usar orquestrador. Outros serviços, uso de Gateway API e sistemas de mensageria são assunto para outros posts.

Sobre a escolha desse tipo de arquitetura, constato que sempre depende do cenário, contexto e de quanto se anseia pelos benefícios. Algo que aprendi é que se for migrar para arquitetura de microsserviços é melhor estudar e utilizar ferramentas de automação como docker e kubernetes. Caso contrário pode haver aumento da complexidade para desenvolver e manter o sistema. Se não houver um bom nível de automação e padronização, pode ficar mais difícil de manter que um sistema monolítico.

A maioria esmagadora dos órgãos públicos da justiça não tem webservices e extrair dados dos sites envolve uma diversidade enorme de soluções. Analisamos cerca de 2,5 milhões de processos e acompanhamos 1 milhão para clientes internos e externos. Para o nosso caso a arquitetura de microsserviços foi benéfica. Nos ajudou até gerar novas ideias reaproveitando serviços existentes para outras features e a migrar rapidamente partes do sistema para tecnologias mais novas ou mais adequadas.