O blog da AWS

Caminhos de modernização para uma aplicação monolítica legada de .NET Framework na AWS

As organizações buscam oferecer soluções tecnológicas ideais com base nas necessidades de seus clientes. Embora possam estar em qualquer estágio da jornada de adoção da nuvem, as empresas geralmente acabam gerenciando e criando aplicativos monolíticos. No entanto, há muitos desafios nessa solução. A estrutura interna de um aplicativo monolítico dificulta a manutenção do código pelos desenvolvedores. Isso cria uma curva de aprendizado acentuada para novos desenvolvedores e aumenta os custos. Os monólitos exigem que várias equipes coordenem uma única versão grande, o que aumenta a carga de colaboração e transferência de conhecimento. À medida que uma empresa cresce, um aplicativo monolítico pode ter dificuldades para atender às demandas de uma base de usuários em expansão. Para resolver essas preocupações, os clientes devem avaliar sua prontidão para modernizar seus aplicativos na Nuvem AWS para atender às suas necessidades comerciais e técnicas.

Discutiremos uma abordagem para modernizar um aplicativo monolítico de três camadas (padrão MVC): uma camada web, uma camada de aplicação usando .NET Framework e uma camada de dados com um banco de dados relacional Microsoft SQL (MSSQL) Server. Existem três caminhos principais de modernização para aplicativos .NET: rehosting, replatforming e refactoring. Recomendamos seguir essa matriz de decisão para avaliar e decidir sobre seu caminho de migração, com base em seus requisitos específicos. Para este blog, vamos nos concentrar em uma estratégia de replatforming e refactor para projetar microsserviços fracamente acoplados, empacotados como contêineres leves e apoiados por um banco de dados específico.

Sua jornada de modernização

Os resultados da abordagem de modernização da sua organização oferecem a capacidade de escalar de forma otimizada de acordo com as demandas de seus clientes. Vamos mergulhar em uma abordagem guiada que alcança os objetivos de uma arquitetura moderna e, ao mesmo tempo, aborda escalabilidade, facilidade de manutenção, ciclos rápidos de implantação e otimização de custos.

Isso envolve quatro etapas:

  1. Quebra do monólito
  2. Conteinerização da aplicação
  3. Refatorar para .NET 6
  4. Migrar para um mecanismo de banco de dados específico e de menor custo.

1. Quebra do monólito

A migração para a nuvem da Amazon Web Services (AWS) tem muitas vantagens. Isso pode incluir maior velocidade de entrada no mercado e agilidade nos negócios, novas oportunidades de receita e economia de custos. Para aproveitar ao máximo, você deve modernizar continuamente os aplicativos da sua organização refatorando seus aplicativos monolíticos em microsserviços.

A decomposição de um aplicativo monolítico em microsserviços apresenta desafios técnicos que exigem uma sólida compreensão da base de código existente e do contexto dos domínios de negócios. Vários padrões são úteis para transformar incrementalmente um aplicativo monolítico em microsserviços e outros projetos distribuídos. No entanto, o processo de refatoração da base de código é manual, arriscado e demorado.

Para ajudar os desenvolvedores a acelerar a transformação, a AWS apresentou o AWS Microservice Extractor for .NET. Isso ajuda a dividir aplicativos de arquitetura e refatoração em projetos de código menores. Leia como o AWS Microservice Extractor for .NET ajudou nosso parceiro, Kloia, a acelerar a jornada de modernização de seus clientes e decompor um monólito.

O próximo caminho de modernização é conteinerizar seu aplicativo.

2. Conteinerizar

Por que você deve mudar para contêineres? Os contêineres oferecem uma maneira de ajudá-lo a criar, testar, implantar e reimplantar aplicativos em vários ambientes. Especificamente, Docker Containers fornece uma maneira confiável de reunir os componentes do aplicativo e empacotá-los em um único artefato de compilação. Isso é importante porque os aplicativos modernos geralmente são compostos de uma variedade de partes além do código, como dependências, binários ou bibliotecas do sistema. Mover aplicativos legados de .NET Framework para contêineres ajuda a otimizar a utilização do sistema operacional e obter consistência de tempo de execução.

Para acelerar esse processo, coloque esses aplicativos em contêineres Windows com o AWS App2Container (A2C). A2C é uma ferramenta de linha de comando para modernizar aplicativos .NET e Java em aplicativos conteinerizados. O A2C analisa e cria um inventário de todos os aplicativos executados em máquinas virtuais, on-premises ou em nuvem. Selecione o aplicativo que você deseja colocar em contêiner e o A2C empacota o artefato do aplicativo e as dependências identificadas em imagens de contêiner. Aqui está um artigo passo a passo e um workshop individualizado para você começar a usar o A2C.

Depois que seu aplicativo estiver em contêiner, você poderá optar por se autogerenciar usando o Amazon EC2 para hospedar Docker com contêineres Windows. Você também pode usar o Amazon Elastic Container Service (ECS) ou o Amazon Elastic Kubernetes Service (Amazon EKS). Esses são serviços de orquestração de contêineres totalmente gerenciados que permitem que você se concentre na criação e no gerenciamento de aplicativos, em vez da infraestrutura subjacente. Leia Amazon ECS vs Amazon EKS: entendendo os serviços de contêiner da AWS.

Na próxima seção, discutiremos dois aspectos principais para otimizar os custos em nosso cenário de modernização:

  1. Custos de licenciamento da execução de cargas de trabalho em servidores Windows.
  2. Custo de licenciamento do SQL Server.

3. Refatorar para .NET 6

Para lidar com os custos de licenciamento de Windows, considere mudar para um ambiente Linux adotando .NET (Core) e usando Dockerfile para um contêiner Linux. Clientes como GoDataFeed se beneficiam ao portar aplicativos .NET Framework para .NET 6 mais recente e executá-los na AWS. A equipe de .NET melhorou significativamente o desempenho com o .NET 6, incluindo uma melhoria de 30 a 40% no desempenho do soquete em Linux. Eles adicionaram otimizações específicas de ARM64 nas bibliotecas .NET, que permitem que os clientes executem em AWS Graviton.

Você também pode optar por mudar para uma opção serverless usando AWS Lambda (que oferece suporte ao .NET 6 runtime) ou executar seus contêineres no ECS com o Fargate, um mecanismo de computação serverless e com pagamento conforme o uso. O AWS Fargate baseado em processadores AWS Graviton2 pode reduzir custos em até 20% e aumentar o desempenho em até 40% em comparação com instâncias x86 baseadas em Intel. Se você precisar de controle total sobre a máquina virtual (VM) subjacente de um aplicativo, sistema operacional, armazenamento e aplicação de patches, execute aplicativos .NET 6 em instâncias Linux do Amazon EC2. Eles são alimentados pelos processadores Intel e AMD de última geração.

Para ajudar os clientes a portar seus aplicativos para o .NET 6 mais rapidamente, a AWS adicionou suporte ao .NET 6 ao Porting Assistant for .NET. Porting Assistant é uma ferramenta de análise que verifica aplicativos em .NET Framework (3.5+) para gerar uma avaliação de compatibilidade com .NET Core ou .NET 5+ de destino. Isso ajuda você a priorizar aplicativos para portabilidade com base no esforço necessário. Ele identifica APIs e pacotes incompatíveis de seus aplicativos .NET Framework e encontra substituições conhecidas. Você pode consultar um vídeo de demonstração que explica esse processo.

4. Migrar de SQL Server para um mecanismo de banco de dados de custo mais baixo

A AWS defende que você crie aplicativos distribuídos, altamente escaláveis e orientados por casos adequados às suas necessidades específicas. Do ponto de vista do banco de dados, a AWS oferece mais de 15 mecanismos criados especificamente para dar suporte a diversos modelos de dados. Além disso, as arquiteturas de microsserviços empregam acoplamento fraco, para que cada microsserviço individual possa armazenar e recuperar informações de seu próprio armazenamento de dados de forma independente. Ao implantar o padrão de banco de dados por serviço, você pode escolher os armazenamentos de dados mais ideais (relacionais ou não relacionais) para seus requisitos de aplicativos e negócios.

Para o propósito deste blog, vamos nos concentrar em uma alternativa de banco de dados relacional para o SQL Server. Para lidar com os custos de licenciamento do SQL Server, os clientes podem considerar a mudança para um mecanismo de banco de dados relacional de código aberto. O Amazon Relational Database Service (Amazon RDS) é compatível com MySQL, MariaDB e PostgreSQL. Vamos nos concentrar no PostgreSQL com um caminho de migração bem definido. O Amazon RDS é compatível com dois tipos de bancos de dados Postgres: Amazon RDS for PostgreSQL e Amazon Aurora PostgreSQL Compatible Edition. Para ajudar você a escolher, leia Amazon RDS for PostgreSQL ou o Amazon Aurora PostgreSQL é uma escolha melhor para mim?

Depois de decidir sobre o sabor do Amazon RDS, a próxima pergunta seria “qual é a estratégia de migração certa para mim?” Considere o seguinte:

  1. Converão de esquema
  2. Migração de dados
  3. Refatoração de aplicações

Conversão de esquema

O AWS Schema Conversion Tool (SCT) é uma ferramenta gratuita que pode ajudá-lo a converter seu banco de dados existente de um mecanismo para outro. O AWS SCT é compatível com vários bancos de dados de origem, incluindo Microsoft SQL Server, Oracle e MySQL. Você pode escolher entre mecanismos de banco de dados de destino, como Amazon Aurora PostgreSQL Compatible Edition, ou optar por configurar um data lake usando o Amazon S3. O AWS SCT fornece uma interface gráfica do usuário que se conecta diretamente aos bancos de dados de origem e destino para buscar os objetos de esquema atuais. Quando conectado, você pode gerar um relatório de avaliação de migração de banco de dados para obter um resumo de alto nível do esforço de conversão e dos itens de ação.

Migração de dados

Quando a migração do esquema for concluída, você poderá mover seus dados do banco de dados de origem para o banco de dados de destino. Dependendo dos requisitos de disponibilidade do aplicativo, você pode executar um trabalho de extração simples que executa uma cópia única dos dados de origem no novo banco de dados. Ou você pode usar uma ferramenta que copia os dados atuais e continua a replicar todas as alterações até que você esteja pronto para passar para o novo banco de dados. Uma dessas ferramentas é o AWS Database Migration Service (AWS DMS), que ajuda a migrar bancos de dados relacionais, data warehouses, bancos de dados NoSQL e outros tipos de armazenamentos de dados.

Com o AWS DMS, você pode realizar migrações únicas e replicar alterações contínuas para manter as origens e os destinos sincronizados. Quando os bancos de dados de origem e de destino estão sincronizados, você pode colocar seu banco de dados offline e mover suas operações para o banco de dados de destino. Leia Microsoft SQL Server para Amazon Aurora com compatibilidade PostgreSQL para obter um manual ou use este workshop autoguiado para migrar para um banco de dados compatível com PostgreSQL usando SCT e DMS.

Refatoração de aplicações

Cada mecanismo de banco de dados tem suas diferenças e nuances, e a mudança para um novo mecanismo de banco de dados, como de MSSQL Server para PostgreSQL, exigirá refatoração de código. Após a conclusão da migração inicial do banco de dados, reescrever manualmente o código do aplicativo, alterar drivers do banco de dados e verificar se o comportamento da aplicação não foi alterado exige um esforço significativo. Isso envolve risco potencial de erros ao fazer grandes alterações no código da aplicação.

A AWS criou o Babelfish para Aurora PostgreSQL para simplificar a migração de aplicativos do SQL Server para a edição compatível com o Amazon Aurora PostgreSQL. O Babelfish para Aurora PostgreSQL é um novo recurso da edição compatível com o Amazon Aurora PostgreSQL que permite ao Aurora entender comandos de aplicativos escritos para o Microsoft SQL Server. Com o Babelfish, o Aurora PostgreSQL agora entende T-SQL, dialeto SQL proprietário do Microsoft SQL Server. Ele oferece suporte ao mesmo protocolo de comunicação, portanto, seus aplicativos que foram originalmente escritos para o SQL Server agora podem funcionar com o Aurora. Leia sobre como migrar do SQL Server para o Babelfish para Aurora PostgreSQL. Certifique-se de executar a ferramenta Babelfish Compass para determinar se o aplicativo contém algum recurso SQL não suportado atualmente pelo Babelfish.

A Figura 1 mostra o estado antes e depois do seu aplicativo com base no caminho de modernização descrito neste blog. O nível do aplicativo consiste em microsserviços executados em clusters do Amazon ECS Fargate (ou funções de AWS Lambda), e a camada de dados é executada no Amazon Aurora (PostgreSQL).

Figura 1. Uma rearquitetura modernizada baseada em microsserviços

Conclusão

Neste post, mostramos um caminho de migração para um aplicativo monolítico de .NET Framework para uma pilha moderna baseada em microsserviços na AWS. Discutimos as ferramentas da AWS para dividir o monólito em microsserviços e conteinerizar a aplicação. Também discutimos estratégias de otimização de custos migrando para sistemas baseados em Linux e usando mecanismos de banco de dados de código aberto. Se você quiser saber mais sobre estratégias de modernização, leia este guia prescritivo.

 

Este artigo foi traduzido do Blog de AWS em Inglês

 

Sobre o autor

Ramakant Joshi é um Sr Solutions Architect na AWS, especializado nos domínios de analytics e serverless. Ele tem mais de 20 anos de experiência em desenvolvimento e arquitetura de software e é apaixonado por ajudar clientes a modernizarem sua arquitetura de nuvem.

 

 

 

 

Revisores

Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 15 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em LATAM, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.