• 1 de novembro de 2022
• Blog

Como modernizar minhas aplicações legadas?

O desenvolvimento focado em Cloud tem se tornado a norma, mas ainda apresenta desafios para aplicações legadas.

Depois de passar muito tempo na neblina, finalmente chegamos a um estágio em o pensamento está mais direcionado à nuvem. Isso é ótimo, principalmente quando iniciamos o desenvolvimento de um software “greenfield” ou “do zero”, em que “tudo é mais fácil e o céu é o limite”.

Entretanto, como bem sabemos, desenvolvimento de software não é um mar de rosas e, na maioria esmagadora das vezes, temos que lidar com sistemas legados. É nesse momento que geralmente surgem algumas perguntas:

• Vale a pena transferir esse legado para a nuvem?
• Se eu transferir para a nuvem, como vai ser depois?
• Será que a nuvem é tão mágica assim? Meu software (que nunca foi escalável na vida) vai ser tornar ultra escalável quando ele estiver lá?

A resposta a essas perguntas está mais atrelada aos próximos passos do que a migração para a nuvem em si. Vamos bater um papo para entender melhor como tornar isso o menos traumático possível?

Strangler Fig Pattern

Umas das coisas mais comuns quando fazemos o lift-and shift é subir a aplicação na nuvem e deixa-la lá, quieta sem qualquer mudança.

Isso, em um primeiro momento, pode passar a sensação de dever cumprido. Mas, com o passar do tempo — com a conta chegando no final de cada mês e com aquela promessa de escalabilidade e elasticidade não cumprida —, começa a bater a dúvida: migrar o legado para nuvem foi a decisão certa?

Não se preocupe se você está nesse momento, isso é mais comum do que se imagina! Vamos ver como tentar resolver esse problema.

Existe um Pattern criado pelo lendário Martin Fowler, referência na área de arquitetura de software, chamado StranglerFigApplication (disponível na íntegra).

De maneira bem reduzida, ele diz que, em um primeiro momento, você só tem o legado. Mas, aos poucos, você pode estrangular as funcionalidades legadas até que o legado como um todo se torna um software moderno, conforme nos mostra a imagem abaixo.

A migração para a nuvem (baseado no StranglerFigApplication de Fowler)

Como “estrangular” meu legado e modernizá-lo na nuvem?

Sempre que fazemos o lift-and-shift, utilizamos como base o modelo de serviço IaaS — já que, geralmente, nesse primeiro momento colocamos o nosso software legado em VMs (Virtual Machines ou Máquinas Virtuais). Para entender melhor os modelos de serviço na nuvem, veja nosso artigo.

Porém, é após esse passo inicial que a brincadeira começa a ficar mais interessante. Para utilizar todo o poder computacional que a nuvem nos oferece, primeiro precisamos mapear funcionalidades do nosso legado que podemos “facilmente” migrar para um serviço PaaS ou SaaS na nuvem.

Vamos a exemplos para facilitar:

Imagine que você possui uma aplicação que faz o uso de armazenamento de dados não estruturados (imagens, arquivos de vídeo, textos etc.) nela mesma.

A longo prazo, essa característica pode comprometer o Storage da sua aplicação em relação ao espaço de armazenamento. Mas o pior mesmo é o fato de impossibilitar a escalabilidade do acesso aos arquivos de maneira exclusiva.

Vamos dizer que você identifica que sua aplicação está demorando para acessar esses arquivos por conta da necessidade de mais poder computacional para escalar. Nesse cenário, você vai precisar aumentar o poder computacional de toda a VM (escalabilidade vertical), já que, conforme dito anteriormente, todos os arquivos residem na mesma VM.

Um primeiro passo para aproveitar o que a nuvem oferece de melhor seria mover esses arquivos para um Storage na nuvem (S3 na AWS e Azure Storage no Azure).

Com isso, você:

• desacopla os arquivos da sua aplicação;
• configura o acesso a esses arquivos da melhor maneira possível;
• utiliza a redundância deles, mudando os arquivos menos acessados para camadas mais “frias;
• acaba pagando menos pelo armazenamento dos arquivos.

Neste exemplo simples, além de começar a desacoplar sua aplicação, você também provavelmente vai começar a economizar um bom montante no final do mês.

Outro exemplo: digamos que, na sua aplicação, existe um Job (processo de execução periódica) que é executado todo o dia em determinado(s) horário(s). É bem provável que você utilize algum serviço no banco de dados ou algo na aplicação para que a execução ocorra.

Entretanto, esse serviço está acoplado à sua aplicação e pode ser facilmente transportado para um serviço independente na sua nuvem utilizando a Arquitetura Serverless como solução (Lambda na AWS e Azure Functions no Azure).

Tanto a AWS quanto o Microsoft Azure disponibilizam 1 milhão de execuções gratuitas por mês. Em outras palavras, se seu Job não passar esse número de execuções por mês, você não vai ter custo. Mais um sinal claro de que remodelar seu legado pode render uma boa economia na nuvem.

Fechando a conta

Conforme vimos no post, a remodelagem do seu legado é fundamental para tirar proveito de tudo que a nuvem pode oferecer, tornando sua aplicação mais escalável, mais dinâmica, mais segura — e, principalmente, mais econômica.

Para saber como o Venturus pode ajudar no processo de remodelagem do seu legado na Nuvem, entre em contato com um de nossos especialistas.