O blog da AWS

Acelere a refatoração de código utilizando as Recomendações Automatizadas do AWS Microservice Extractor for .NET

Por Leonardo Bonato Bizaro, Professional Services Intern, WWCO ProServe LATAM.

 

O desafio das aplicações monolíticas é que toda a lógica de negócios está na mesma base de código, tornando-a construída e implantada, principalmente, como uma entidade única. Isso limita os benefícios da nuvem e afeta a escalabilidade, pois um pico na demanda exige mudanças na arquitetura, afetando a disponibilidade da aplicação. O maior obstáculo para refatorar uma aplicação monolítica em microsserviços é o custo irrecuperável dos ciclos gastos para descobrir se a refatoração faz sentido, além da necessidade de usar várias ferramentas para correlacionar código-fonte e métricas de tempo de execução. Estes desafios fazem com que essa situação de refatoração não seja colocada em prática por todos os clientes, pois na maioria das vezes é difícil identificar partes do aplicativo a serem extraídas como serviços separados, agrupando funcionalidades.

Para evitar essas situações, o AWS Microservice Extractor for .NET vem para ajudar seu aplicativo a se transformar em um aplicativo de microsserviços, refatorando em um “novo aplicativo”, renovando incrementalmente seu aplicativo em uma arquitetura ideal para poder aproveitar todas as vantagens da nuvem. O Microservice Extractor é uma ferramenta assistencial que se torna um consultor e construtor para renovar aplicativos para “modelo de nuvem”.

O serviço faz a visualização, exibindo classes e dependências na interface do usuário, que pode então examinar a visualização e as classes relacionadas aos grupos, e o próprio Extractor atua na extração dos grupos criados como microsserviços. Como o maior obstáculo era quando os usuários precisavam examinar e criar estes grupos para refatoração,  o Extractor lançou as Recomendações Automáticas de Refatoração para ajudar a resolver este problema.

Com as Recomendações Automáticas de Refatoração, estamos reduzindo o tempo gasto pelo usuário na análise de classes para a elaboração de grupos. Esse recurso facilita a identificação e personalização de candidatos a microsserviços, identificando pontos de partida que são candidatos para extração usando heurística. Neste blog post, abordaremos o uso dessa ferramenta e saberemos mais sobre as etapas envolvidas na transformação de uma aplicação monolítica.

 

Visão geral da Solução

Figura 1 – Exemplo de aplicação da solução

 

A ferramenta é composta de quatro etapas: (1)Importação, (2)Visualização, (3)Agrupamento e (4)Extração. Estas etapas são aplicadas pelo Microservice Extractor em aplicações que utilizam frameworks nativos para C#, podendo aproveitar todas as vantagens em todas as etapas. Funciona com ASP.NET e MVC. Você pode inserir os dados de criação de perfil de runtime, que o ajudarão a receber métricas de tempo de execução coletadas que serão usadas para criar uma visualização de seu aplicativo. Você também pode analisar e incluir dados de compatibilidade de .NET (versão 6) na visualização.

O Microservice Extractor for .NET é uma ferramenta de aplicativo independente do Windows cujo único pré-requisito é ter uma conta da AWS. É uma ferramenta gratuita que pode ser usada quando você quiser. Você pode começar com vídeos e demonstrações da ferramenta, e workshops didáticos para aprender tudo o que precisa sobre a ferramenta. Esta é uma ferramenta completa que pode fazer um bom trabalho refatorando sua aplicação monolítica em microsserviços e tem potencial para ser uma ferramenta ainda melhor para esses casos de uso em um futuro próximo.

 

 

Pré-requisitos

  • Microservice Extractor for .NET deve ser instalado de forma gratuita aqui.
  • Uma Conta AWS deve ser utilizada para utilização da ferramenta e coleta de métricas pela AWS.
  • A engine MSBuild que será utilizada pela própria ferramenta.
  • Aplicação monolítica com framework nativo em C#, em .NET ASP.NET ou .NET Core ASP.NET, para realizar o procedimento de análise e agrupamento do Extractor.
  • Conhecimento em C# e Visual Studio.

Passo a passo

Este passo a passo irá guiá-lo através da extração de um serviço independente de uma aplicação ASP.NET monolítica.  Você usará o AWS Microservice Extractor for .NET para visualizar, agrupar e extrair partes da aplicação monolítica como serviços separados.

A aplicação utilizada simula uma aplicação three-tier em que os controladores chamam os serviços de negócios para concluir as solicitações do usuário e os serviços, por sua vez, chamam a camada de acesso ao banco de dados. Este é um padrão muito comum usado em aplicações ASP.NET MVC.

Figura 2 – Exemplo de aplicação monolítica para a solução.

 

Ao revisar o método Index() no arquivo Controller\HomeController.cs, vemos a criação de uma instância da classe Inventory. Em seguida, estamos chamando o método GetBestSellers() para obter os 6 produtos mais vendidos a serem listados na página inicial. Como você pode ver, esse método retorna uma Lista de objetos do modelo de dados do Produto.

Figura 3 – Estruturação da HomeController

Revendo Services\Inventory.cs, vemos vários métodos usando uma instância de Models\GadgetsOnlineEntities DbContext para buscar modelos de dados e filtrar com base em uma ou mais condições.

Figura 4 – Exemplo de aplicação da solução

 

Models\GadgetsOnlineEntities DbContext que chamará a camada de banco de dados:

Figura 5 – Modelo de entidades que atua com o banco de dados

Neste contexto, iremos importar a aplicação de exemplo ao AWS Microservice Extractor. Primeiramente, deve-se realizar a configuração inicial da ferramenta dentro da aba Settings.

Figura 6 – Tela inicial da ferramenta

Especificar a região AWS a ser utilizada, juntamente com um usuário IAM da AWS (perfil padrão ou perfil configurado pela AWS CLI com credenciais), e o diretório de trabalho que você deseja armazenar a saída da análise e extração.

Figura 7 – Exemplo de configurações realizadas dentro do Extractor

Agora, podemos trazer a aplicação .NET ao nosso serviço:

Figura 8 – Local de importação das aplicações ao Extractor

  1. Importação: Para a importação, basta clicar em Onboard application e dar um nome a nossa aplicação e apontar a fonte do projeto que se deseja utilizar:

Figura 9 – Exemplo de configuração de importação

Nesta etapa, existem configurações opcionais que não foram utilizadas nesta demonstração, porém é de utilidade retratar cada uma:

  • MSBuild path: especificar o caminho do MSBuild que será utilizado para buildar a aplicação. Por padrão, a ferramenta aponta para o caminho original do MSBuild caso ele tenha sido instalado lá.
  • Runtime profiling data: incluem métricas de uso de tempo de execução que podem ser destacadas no gráfico de visualização nas próximas etapas.
  • Analyze .NET Core Portability: A ativação dessa configuração requer que o Porting Assistant for .NET seja instalado na mesma máquina que o AWS Microservice Extractor for .NET. Essa configuração integra a análise de código-fonte com o Porting Assistant para analisar a compatibilidade de código para atualização para .NET / .NET Core.

Agora, pode-se iniciar a importação da aplicação. Isso iniciará a análise do código-fonte pelo Extractor. Esta análise será utilizada para criar um gráfico de dependência direcionada entre várias classes da aplicação. Este processo pode demorar alguns minutos, e depois de concluído podemos prosseguir para a próxima etapa para visualizar o gráfico de dependência.

Figura 10 – Exemplo de aplicação importada na ferramenta

  1. Visualização: Agora podemos visualizar o gráfico de dependência ao selecionar Launch visualization, e nos deparar com a seguinte estrutura:

 

Figura 11 – Exemplo de visualização de aplicação importada

É possível visualizar os tipos de Node como User Interface (acesso direto pelo usuário), Data Access (node ​​que acessará os dados), Service Access (node ​​que será acessado pelo seu serviço) e Multi-type nodes. Você também pode ver nós não extraíveis (como configurações).

As setas azuis mostram as dependências de entrada. Neste caso, Controladores MVC Store, Home e ShoppingCart. As setas laranjas mostram dependências de saída de um nó. Nesse caso, a classe Inventory tem uma dependência direta do GadgetsOnline DBContext e do modelo de dados Product. A visualização e o gráfico de dependência acima ilustram que, se extrairmos o Inventory como um microsserviço separado, precisaremos refatorar três controladores (Store, ShoppingCart e Home) para fazer chamadas de API remotas em vez da chamada de instância da classe Inventory local.

  1. Agrupamento: Será criado um grupo sob o node:

 

Figura 12 – Exemplo de criação de grupo

A criação do grupo diz respeito a quais nodes você deseja anexar em um conjunto e realizar posteriormente a operação de extração deste conjunto. Como nosso intuito é a extração apenas do Inventory como um microsserviço separado, o grupo foi criado apenas deste node.

Figura 13 – Grupo criado e visualizado

 

É possível visualizar os detalhes de um grupo ao clicar no mesmo. A lista de nodes mostra a classe Inventory. As classes apresentadas são extraídas como um serviço independente. Já a lista de Dependencies mostra as dependências que serão copiadas ou referenciadas no serviço independente extraído.

Basta pressionar “Extract group” para iniciar o processo de extração.

 

  1. Extração:

Figura 14 – Configuração de extração de um grupo

Na seção acima, caso a opção “Usar invocações de método remoto” seja selecionada, o AWS Microservice Extractor substituirá as invocações da classe de inventário local pelas chamadas remotas da API REST como parte do processo de extração. Caso a outra opção seja selecionada, a aplicação extraída continuará tendo a invocação para métodos locais.

 

Depois que a extração estiver concluída, dois diretórios são disponibilizados: o Extracted service que disponibiliza o projeto com a aplicação extraída e o Modified application code que disponibiliza o projeto da aplicação antiga porém com as antigas dependências sendo chamadas API para o microsserviço.

Figura 15 – Exemplo de mensagem de sucesso de extração

Observe que o AWS Microservice Extractor fará o possível para compilar o serviço recém-criado, mas isso não é uma garantia. Talvez você ainda precise corrigir referências ou atualizar pacotes NuGet para compilar o projeto de API Web.

  • Extracted Service: abra o arquivo de solução na pasta de Extracted Service para abrir o projeto ASP.NET no Visual Studio e revisar a estrutura do projeto. Você verá que um ApiController chamado InventoryController foi criado. Esse controlador possui mapeamento com os métodos públicos da classe Inventory, expondo-os como APIs REST. Você verá todos os tipos de modelo de dados e DBContext referenciados pelos serviços de Inventory extraídos e copiados na pasta Models.

Figura 16 – Exemplo de aplicação extraída como microserviço

  • Modified application code: abra o arquivo de solução na pasta Modified application code para abrir o projeto ASP.NET no Visual Studio e revisar a cópia da aplicação monolítica atualizada. Na pasta Controllers, revise cada controlador. As chamadas de classe de Inventory locais são convertidas em chamadas de API remotas usando o EndpointAdapter.

Figura 17 – Exemplo de aplicação monolítica atualizada após extração de uma de suas dependências

Revise a pasta EndpointAdapter que foi criada como parte do processo de extração. Ele tem uma classe InventoryEndpointFactory que pode alternar entre chamadas de API REST remotas e chamadas de classe de Inventário locais com base em um sinalizador chamado RemoteRoutingToMicroservice em um arquivo web.config local.

Figura 18 – Exemplo de aplicação monolítica atualizada após extração de uma de suas dependências

Lembrando que após a utilização do Microservice Extractor for .NET, você deve concluir a refatoração pós-extração para fazer com que o serviço extraído e o restante da aplicação monolítica se comuniquem entre si usando REST APIs.

Recursos adicionais

Para a realização desse blog foi utilizado uma workshop disponibilizada pela AWS com o intuito de demonstrar as etapas de processo para a utilização do Microservice Extractor for .NET.

Caso existam mais dúvidas, é possível consultar a documentação a respeito da ferramenta aqui.

Desinstalação da solução

Se não houver mais interesse em manter a solução, você pode efetuar a remoção da mesma através da desinstalação da ferramenta AWS Microservice Extractor, apagando as pastas dos diretórios que foram utilizados, e excluindo o usuário IAM que foi utilizado dentro do Extractor, se preferível.

 

Conclusão

Sua unica aplicação monolítica agora são duas aplicações diferentes se comunicando por meio de APIs REST, enquanto a experiência do usuário final permanece a mesma. Desta forma, você consegue desfrutar de todas as qualidades e pontos positivos da refatoração em microserviços em sua própria aplicação já existente.

O AWS Microservice Extractor for .NET pode ajudá-lo a extrair serviços independentes de suas aplicações monolíticas em .NET. Ao usar essa ferramenta, você pode simplificar e acelerar sua migração para microsserviços.

O Extractor usa análise de código-fonte e métricas de tempo de execução para produzir uma visualização que mostra gráficos de dependência, métricas de execução (por exemplo, contagens de chamadas de tempo de execução) e referências estáticas entre artefatos de código (por exemplo, classes). Você pode usar a visualização e as contagens de chamadas para entender as dependências entre os componentes e identificar as os componentes mais chamados. Depois de selecionar as dependências para preparar partes da aplicação para extração, você pode usar o AWS Microservice Extractor for .NET para extrair endpoints de API. O Extractor extrai o código subjacente a esses endpoints de API substituindo chamadas locais por chamadas remotas. Você pode então desenvolver, construir e implantar esses projetos como achar melhor. A AWS recomenda que você teste completamente seu aplicativo depois de transformá-lo com o AWS Microservice Extractor for .NET antes de usá-lo em produção.

 

Sobre os autores

Leonardo Bonato Bizaro é Professional Services Intern no time de ProServe LATAM. Presente desde março, vem abraçando a grande oportunidade recebida através da constante busca de experiência e aprendizado na AWS para crescimento e desenvolvimento profissional.

 

 

 

 

Revisor

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

 

 

 

 

 

 

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 workloads Microsoft na nuvem AWS.