Transformar uma aplicação monolítica em microsserviços poder ser uma tarefa muito complexa. Conheça alguns caminhos possíveis de se seguir quando estiver refatorando sua aplicação monolítica
Transformar uma aplicação monolítica em microsserviços é uma forma de modernizar a aplicação.
E se você trabalha com tecnologia, deve saber que o processo de transformar uma aplicação monolítica em microsserviços é uma tarefa muito complexa e delicada. Exige tempo e paciência de todos os envolvidos.
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 seus 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 quando estiver refatorando sua aplicação monolítica.
A primeira dica é não fazer uma reescrita total da sua aplicação. Ou seja, esqueça a ideia de direcionar todos os esforços do time para reescrever a aplicação do zero.
Isso é extremamente arriscado e geralmente resulta em problemas que acabam levando mais tempo que o planejado.
Vá devagar! O mais recomendado é refatorar aos poucos sua aplicação monolítica. Construa 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 sua aplicação monolítica se tornar ingerenciável, deve-se parar de tornar seu monolito maior.
Se você tiver de implementar uma nova funcionalidade, não adicione 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.
Glue Code
É neste cenário que 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 sua aplicação original.
O glue code é chamado também de camada anti-corrupção, já evita que o microsserviço seja poluído com problemas da aplicação legada.
Desenvolver uma camada anti-corrupçã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 sua 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 seu 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.
A cada novo serviço criado, será experimentado um pouco mais dos benefícios desta arquitetura.
Entretanto, essa abordagem não acaba com todos os problemas do monolito. Para tentar consertar esses problemas, é necessário quebrar o monolito em partes cada vez menores.
Outra estratégia que ajuda a encolher a aplicação monolítica é separar a sua 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 seu 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.
Essa estratégia, no entanto, é somente uma solução parcial. É bem comum que você troque um problema enorme por dois problemas menores, mas que no contexto geral ainda são um problemão a ser resolvido.
Você terá de 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 você extrai um módulo e o transforma em um serviço, o monolito encolhe. Uma vez que tenha sido 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.
Converter um módulo em um microsserviço é algo que requer tempo. Uma dica é priorizar módulos que mudam com frequência.
Isto trará experiência com arquitetura de microsserviços e com o processo de extração.
Depois que você extrair esses módulos mais fáceis, poderá partir para os mais complexos.
Uma vez que você tenha convertido um módulo desses para um serviço, você pode 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, pegar aquele módulo que utiliza recursos específicos do servidor como muita memória ou CPU. Conforme você vai extraindo estes módulos específicos, você vai 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 você tenha 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 você extrair um novo serviço, estará um passo mais perto de ter uma aplicação 100% em microsserviços.
Com o passar do tempo, seu monolito encolherá e a virada de chave entre as arquiteturas se tornará algo natural.
Quer saber mais como sua empresa pode aplicar isso na prática? A Viceri conta com especialistas que podem te ajudar. Fale com a gente!
