Migração de microsserviços para monolitos

Em nossos posts anteriores já falamos muito sobre microsserviços, suas propriedades, as vantagens de usar essa arquitetura e apresentamos também formas de projetar, implantar e monitorar sistemas baseados em microsserviços. Mas, o que fazer com as aplicações monolíticas que suportam importantes processos de negócio, estão em funcionamento e ainda irão evoluir por um longo tempo? Quando decidir fazer a migração de microsserviços para monolitos e como  fazê-lo?

Para decidir se uma aplicação monolítica grande e complexa deve ser refatorada em microsserviços, precisamos inicialmente responder algumas questões, como:

1. A aplicação ainda permanecerá em funcionamento por muito tempo? Será necessário fazer atualizações em suas funcionalidades? 
2. Atualmente o desenvolvimento e a implantação de novas funcionalidades são atividades trabalhosas e lentas?
3. As entregas de novas versões da aplicação normalmente apresentam bugs?
4. Existem problemas referentes à escalabilidade e à rápida implantação da aplicação?

Se as respostas a essas perguntas forem positivas e se já foram aplicadas ações prévias visando resolver essas questões sem obter sucesso, então, podemos dizer que a arquitetura monolítica é o problema. Nesse caso, a migração para a arquitetura de microsserviços poderá trazer muitos benefícios, incluindo maior facilidade para a realização de manutenção, testes e implantações e, portanto, maior rapidez e qualidade no processo de desenvolvimento. Além disso a arquitetura de microsserviços é altamente escalável e apresenta melhores condições para o isolamento de falhas. 

Migrando para Microsserviços

Transformar a aplicação monolítica em microsserviços é uma forma de modernização da aplicação, mas somente deve ser realizada se realmente for resolver uma parte considerável dos problemas existentes com a aplicação atual. 

Esse processo pode ser feito de duas formas:

1) criar uma nova versão da aplicação “do zero” ou

2) fazer uma migração gradativa para a arquitetura de microsserviços.

Implementar uma nova versão da aplicação “do zero” é conhecido como big bang rewrite. Parece simples resolver dessa forma, mas existem alguns problemas que precisam ser considerados:

1. É provável que muito tempo tenha sido gasto e muito trabalho tenha sido realizado para que a aplicação monolítica pudesse atender às necessidades do negócio até o momento atual. Então, é natural que um esforço considerável também seja necessário para desenvolvê-la na nova arquitetura.
2. Provavelmente será quase impossível parar de evoluir a aplicação monolítica atual para esperar que a nova aplicação baseada em microsserviços fique pronta para ser usada.
3. Além disso, é muito provável que, ao final desse processo de desenvolvimento, dado o tempo gasto, a nova aplicação esteja desatualizada com relação à atual necessidade do negócio.

Raramente essa é a melhor solução. Ao invés de usar essa abordagem, podemos fazer uma migração gradativa, onde as funcionalidades da aplicação monolítica vão sendo “transferidas” para os novos microsserviços que serão construídos.

Migração gradativa

Desta forma, o número de microsserviços vai aumentando e a aplicação monolítica vai diminuindo até desaparecer por completo. Durante esse processo, tanto os microsserviços quanto a aplicação monolítica precisam colaborar entre si para que as funcionalidades do negócio sejam atendidas.

Essa estratégia tem alguns desafios, mas certamente apresenta menos riscos que a abordagem big bang rewrite. Além disso, essa estratégia incremental de refatorar o monólito para microsserviços traz um retorno imediato do investimento. Isso ajuda a manter o processo de migração, que poderá durar muito tempo e poderá precisar de novos recursos. Ademais, cada microsserviço é desenvolvido usando novas tecnologias, novas técnicas de desenvolvimento e entregas e a equipe de software fica mais ágil e eficiente à medida que o tempo avança.

Durante esse processo, o ideal é que as alterações realizadas no monólito sejam somente para viabilizar a interação com os microsserviços. Ou seja, as novas funcionalidades ou alterações necessárias na aplicação para suportar novas necessidades dos processos de negócio devem ser implementadas, preferencialmente, já na nova arquitetura.

Construindo os Microsserviços

O processo de refatorar incrementalmente requer uma estratégia para definir quais microsserviços devem ser criados e em qual ordem.

Primeiramente, podemos considerar as novas funcionalidades que surgirem ao longo do processo. Como falamos, é desejável que elas sejam desenvolvidas já na nova tecnologia, mas respeitando as regras de criação de microsserviços e suas propriedades, conforme apresentamos no post “Microsserviços – Projetando”. Ou seja, se a nova funcionalidade for simples demais para caracterizar um microsserviço, poderá ser melhor atualizar o monólito para incorporar essa funcionalidade.

Supondo que a nova funcionalidade justifique a criação de um novo microsserviço, será necessário também criar os elementos que irão realizar a integração entre o monólito e o novo microsserviço a ser criado.Esses elementos são:

• Um API gateway para rotear as requisições para a nova funcionalidade no microsserviço e as requisições para as funcionalidades legadas no monólito
• Código para integrar o microsserviço e o monólito, principalmente para acesso aos bancos de dados e funcionalidades, que poderá usar um ou mais mecanismos de comunicação entre processos.

Entretanto, para viabilizar esse modelo de incremento de funcionalidades através de microsserviços e a própria migração gradativa da funcionalidade como um todo, é necessário garantir que a camada de apresentação da aplicação esteja completamente separada da camada de negócios e acesso aos dados, o que pode exigir uma alteração na aplicação. A comunicação entre as camadas deverá ser realizada exclusivamente através de uma API. Esta API encapsula para a camada de apresentação a funcionalidade de negócios e dados.

Extração gradativa das funcionalidades do monólito

A partir da separação em camadas da aplicação monolítica, pode-se iniciar o processo de extração gradativa das funcionalidades do monólito, implementando-as em microsserviços. Tais microsserviços incluirão a funcionalidade de negócios expondo-a como uma chamada de API.  Poderão, ainda, acessar o banco de dados do monólito ou já possuir sua própria base de dados independente.

O fato é que o processo de criação de cada microsserviço que substitui funcionalidades do monólito carrega consigo o desafio de se refatorar o domínio da antiga aplicação, isolando o domínio do novo componente. Essa separação normalmente envolve a quebra de dependências e a refatoração do banco de dados do monólito.

Também é fundamental priorizar as funcionalidades mais importantes da aplicação para serem implementadas em microsserviços. As seguintes características ajudam a identificar as funcionalidades que trarão mais benefício quando implementadas em microsserviços:

• funcionalidades que ainda irão evoluir bastante ao longo do tempo;
• partes do monólito que apresentam problemas de escalabilidade, desempenho ou confiabilidade;
• funcionalidades que facilitam a extração de outras funcionalidades.

Finalmente, a definição dos microsserviços que serão construídos para substituir a funcionalidade da aplicação monolítica pode partir da análise dos elementos da aplicação atual ou pode seguir um caminho independente, isto é, pode-se definir o conjunto de microsserviços ideal para a necessidade do negócio e depois mapear a migração de funcionalidades do monólito.

Nesse post analisamos estratégias para a refatoração de um monólito em microsserviços. Em um próximo artigo, vamos nos aprofundar no processo de separação e colaboração entre o monólito e os microsserviços que forem sendo construídos à medida que as funcionalidades são extraídas da aplicação original.