Transformar uma aplicação monolítica em microsserviços é uma forma de modernizar a aplicação. O processo de transformar uma aplicação monolítica em microsserviços é uma tarefa muito complexa e delicada.
A arquitetura monolítica é uma arquitetura tradicional de desenvolvimento de sistema de software. Ela se baseia no princípio de que todos os processos dentro de uma mesma solução estão ligados. Isso quer dizer que são acoplados, que estão dentro de uma base de dados similar e executam processos como um único serviço.
Já a arquitetura de microsserviços veio para solucionar problemas enfrentados pela arquitetura monolítica. É um modelo que desenvolve pequenos serviços que realizam funções independentes.
Por serem independentes, podem atender demandas específicas em uma solução maior. É um processo menos tradicional que a arquitetura monolítica.
Primeiros passos para refatorar uma aplicação
Para que a migração de uma para a outra se torne uma tarefa mais simplificada, existem alguns caminhos possíveis de se seguir.
Não deve-se fazer uma reescrita total da aplicação. Ou seja, é extremamente arriscado direcionar todos os esforços do time para reescrever a aplicação do zero e, geralmente resulta em problemas que acabam levando mais tempo que o planejado.
O mais recomendado é refatorar aos poucos a aplicação monolítica.
Construir uma aplicação de forma incremental, rodando cada novo microsserviço em conjunto da aplicação original. Com o passar do tempo, a quantidade de funcionalidades implementadas em microsserviços vai mostrar que o monolito encolheu tanto que em algum momento ele deixará de existir.
Quando uma aplicação monolítica se tornar ingerenciável, deve-se parar de tornar um monolito maior. Quando necessário implementar uma nova funcionalidade, não se deve adicionar esse código ao monolito. Ao invés disso, a melhor estratégia é colocar o novo código em um microsserviço próprio para isso.
Neste cenário surge o Glue Code, que são as dependências responsáveis pelo acesso aos dados. Geralmente o serviço usará bibliotecas e componentes de acesso a dados da aplicação original.
O glue code é chamado também de camada anticorrupção, já evita que o microsserviço seja poluído com problemas da aplicação legada. Desenvolver uma camada anticorrupção não é algo muito comum, mas é essencial quando se quer manter uma aplicação confiável.
Com isso em mente, esse Glue Code pode seguir três estratégias:
– Invocar uma API remota, fornecida pelo monolito;
– Acessar a base de dados do monolito diretamente;
– Manter a própria cópia da base com parte dos dados necessários para o microsserviço, que estará sincronizada com a base do monolito.
E o que acontece ao implementarmos novas estratégias?
Implementar novas funcionalidades como um microsserviço tem uma série de benefícios. Essa estratégia impede que o monolito se torne cada vez mais ingerenciável, ao mesmo tempo que permite que o serviço possa ser desenvolvido, implantado e escalado de maneira independente do monolito.
Outra estratégia que ajuda a encolher a aplicação monolítica é separar a camada de apresentação da lógica de negócio e do acesso a dados.
Geralmente existe uma separação muito clara entre a camada de apresentação e as camadas de regras de negócio e dados. E isto é o que permite fazer a separação do monolito em duas aplicações menores.
Uma aplicação será o frontend, e a outra o backend. Uma vez separados, o frontend fará chamadas independentes ao backend.
Separar um monolito dessa maneira permite que o time desenvolva, implante e escale duas aplicações de maneira independente.
Esta estratégia, no entanto, é somente uma solução parcial. É bem comum que se troque um problema enorme por dois problemas menores, mas que no contexto geral ainda são um problema a ser resolvido. Será necessário usar uma outra estratégia para eliminar os monolitos restantes.
Essa outra estratégia é transformar os módulos existentes dentro de um monolito em microsserviços. Cada vez que se extrai um módulo e o transforma em um serviço, o monolito encolhe. Uma vez que tenha convertido muitos módulos, o monolito deixará de ser um problema. Ou ele irá sumir ou vai acabar virando um microsserviço.
Converter um módulo em microsserviço requer tempo e paciência
Uma aplicação monolítica grande geralmente terá dezenas ou centenas de módulos, todos dispostos a serem extraídos. Saber quais módulos converter primeiro pode ser desafiador. Uma boa abordagem é começar com alguns módulos que são fáceis de extrair.
Isto trará experiência com arquitetura de microsserviços e com o processo de extração. Esses módulos ficam mais fáceis depois de extraídos. Uma vez que convertido um módulo desses para um serviço, é possível desenvolver e implantar ele de maneira independente do monolito, o que vai acelerar o desenvolvimento.
Outra abordagem interessante é extrair os módulos que possuem requisitos diferentes do resto da aplicação. Por exemplo, um módulo que utiliza recursos específicos do servidor como muita memória ou CPU. Conforme extraído estes módulos específicos, é possível ver como se tornará mais fácil escalar os microsserviços.
O primeiro passo ao extrair um módulo é definir a interface entre o módulo e o monolito. Geralmente será um contrato bidirecional, pois é comum o monolito precisar de dados do microsserviço e vice-versa.
Se a lógica de negócio do monolito estiver muito acoplada, talvez seja difícil de extrair apenas o necessário para o microsserviço, então é possível que uma refatoração interna no monolito seja necessária para continuar avançando com essa extração.
Uma vez que extraído um módulo, é mais um serviço que permite ao time desenvolver, implantar e escalar mais facilmente do restante do monolito. Sendo possível, inclusive, reescrever este serviço do zero mais tarde, uma vez que o módulo já foi isolado.
Cada vez que extraído um novo serviço, estará um passo mais perto de ter uma aplicação 100% em microsserviços.
Website: https://www.viceri.com.br/