Decidindo onde hospedar aplicações .NET na AWS

Por Adi Simon

Com a Amazon Web Services (AWS), você tem três tipos principais de computação para escolher: instâncias, contêineres e função como serviço. Embora todos eles possam ser usados para hospedar aplicações .NET, escolher o tipo certo pode ajudá-lo a obter a melhor arquitetura possível para sua aplicação. Nesta postagem do blog, analiso alguns tipos comuns de aplicações .NET e, em seguida, orientarei você sobre como navegar até os serviços de computação ideais para essas aplicações.

Serviços de computação para aplicações .NET

As aplicações .NET podem ser executadas em qualquer um dos serviços computacionais da AWS. Aqui estão alguns dos serviços mais comuns usados para executar aplicações .NET na AWS:

• As instâncias são servidores virtuais, permitindo que você altere seus recursos com um botão ou uma chamada de API. A AWS oferece instâncias do Amazon Elastic Compute Cloud (EC2), que vêm em famílias e tamanhos diferentes.
• Os contêineres são um método de virtualização do sistema operacional que permite executar uma aplicação e suas dependências em processos isolados de recursos. Os contêineres podem ser usados se você precisar controlar a instalação, a configuração e o gerenciamento do seu ambiente computacional. A AWS fornece duas plataformas de orquestração de contêineres: Amazon Elastic Container Service (ECS) e Amazon Elastic Kubernetes Service (EKS). O AWS Fargate é o mecanismo de computação sem servidor que você pode usar para executar contêineres sem precisar gerenciar os servidores subjacentes.
• As funções abstraem o ambiente de tempo de execução do código que você deseja aplicar. O AWS Lambda permite que você execute código sem a necessidade de instâncias ou contêineres do Amazon EC2.

Aplicações web e APIs

Em termos gerais, aplicações web e APIs respondem às solicitações de visualização e mutação de dados por meio do protocolo HTTP. Algumas de suas características desejadas incluem:

• Tempo de resposta rápido: os usuários finais esperam respostas rápidas, e até mesmo pequenos atrasos podem afetar significativamente sua experiência e taxas de conversão, conforme explicado em um artigo de pesquisa do Nielsen Norman Group.
• Carga imprevisível: pode ser difícil prever com precisão o volume de solicitações. Durante os períodos de pouco uso, talvez você queira diminuir seus recursos computacionais para ter um custo menor. Você também precisa ser capaz de escalar automaticamente os recursos em resposta ao aumento da demanda.
• Alta disponibilidade: aplicações web e móveis e suas APIs de back-end são as principais vitrines digitais de muitas empresas. Até mesmo um pequeno tempo de inatividade de aplicações web ou web APIs voltados para clientes internos ou externos pode afetar negativamente os negócios.

As implantações locais tradicionais geralmente incluem a hospedagem de aplicações web e APIs em máquinas virtuais que executam os Serviços de Informações da Internet (IIS) no Windows Server. O uso de instâncias Windows do Amazon EC2 pode imitar uma configuração local tradicional. No entanto, se você estiver desenvolvendo uma nova aplicação ou quiser mais benefícios da computação em nuvem, continue lendo.

As aplicações da Web geralmente consistem em uma mistura de conteúdo estático e dinâmico. O conteúdo estático inclui ativos como HTML, CSS, imagens e vídeos que não mudam com frequência. O conteúdo dinâmico é personalizado para cada cliente da aplicação web e requer processamento do lado do servidor, como a recuperação de dados de um banco de dados. Você precisa de pouca capacidade computacional para fornecer conteúdo estático, por isso é mais otimizado e econômico hospedar conteúdo estático em serviços de armazenamento como o Amazon Simple Storage Service (Amazon S3). Você também pode configurar o Amazon CloudFront como ponto de entrada para seus usuários em qualquer lugar do mundo acessarem o conteúdo com baixa latência. A arquitetura mostrada na Figura 1 é o que vou usar como linha de base para discutir suas opções de computação.

Figura 1: Amazon CloudFront com duas origens servindo conteúdo estático e dinâmico

Um serviço de computação sem servidor, como o AWS Lambda, permite que você atenda aos comportamentos desejados da aplicação mencionados anteriormente sem a sobrecarga de gerenciar a infraestrutura subjacente. A computação sem servidor vem com escalabilidade automática, alta disponibilidade integrada, maior agilidade e um modelo de cobrança de acordo com o uso. A Figura 2 mostra uma arquitetura com uma aplicação web ASP.NET ou uma API web implantada no AWS Lambda:

Figura 2: Arquitetura de aplicações web sem servidor na AWS

Essa arquitetura requer o .NET 6.0 ou posterior. Para novos projetos, essa arquitetura pode ser uma boa opção. No entanto, a base de código de aplicações legadas existentes pode primeiro precisar ser convertida para usar uma versão mais recente do .NET. Para isso, você pode usar ferramentas como o AWS Toolkit for .NET Refactoring ou o Porting Assistant para .NET para ajudar a converter suas aplicações C# ou VB.NET do .NET Framework 3.5 ou posterior para o .NET moderno.

Depois de portar a base de código da aplicação, a rearquitetura ainda pode levar muito tempo e esforço. Para esses cenários, colocar essas aplicações em contêineres e executá-los em serviços como Amazon ECS ou Amazon EKS é uma abordagem viável. Os contêineres são leves e geralmente iniciam mais rápido do que as máquinas virtuais. Se você já tem habilidades de Kubernetes em sua organização, optar pelo Amazon EKS pode proporcionar uma transição operacional mais tranquila.

Ambos os serviços de contêiner também oferecem suporte ao tipo de lançamento do AWS Fargate. (Observe que, no momento em que este artigo foi escrito, o Amazon EKS não oferece suporte a contêineres do Windows com o AWS Fargate.) Com o AWS Fargate, você não precisa mais provisionar, configurar ou escalar clusters de máquinas virtuais para executar contêineres. Isso elimina a necessidade de escolher tipos de servidor, quando escalar seus clusters ou otimizar o empacotamento de clusters.

A Figura 3 abaixo mostra a implantação de uma aplicação web ASP.NET no AWS Fargate, com balanceamento de carga em duas zonas de disponibilidade (AZ). Uma arquitetura semelhante pode ser usada para web APIs, embora as web APIs normalmente usem o Amazon API Gateway na frente do balanceador de carga da aplicação.

Figura 3: Cargas de trabalho com balanceamento de carga no AWS Fargate

Serviços em segundo plano

Diferentemente das aplicações da Web e das Web APIs, os serviços em segundo plano, como worker services, normalmente não têm uma interface de usuário. Eles são “headless” e geralmente são acionados em intervalos de tempo regulares ou em resposta a eventos do sistema, em vez de eventos do usuário. Podemos ainda dividir os worker services em duas subcategorias:

1. Os trabalhos em lote são executados em intervalos definidos e exigem recursos computacionais estáveis. Eles podem levar horas para serem concluídos. Os exemplos incluem trabalhos de reconciliação no final do mês ou processamento em lote noturno.
2. Os processos em segundo plano precisam estar disponíveis para realizar o processamento assíncrono sob demanda. Eles tendem a concluir seu trabalho em um período de tempo muito mais curto, geralmente em segundos ou minutos. Os exemplos incluem geração de relatórios e processamento de filas.

As opções para trabalhos em lotes de longa duração incluem Amazon EC2, Amazon ECS ou Amazon EKS (incluindo  AWS Fargate). Para todas essas opções, trabalhos tolerantes a falhas podem aproveitar as Instâncias Spot do Amazon EC2, que oferecem um custo até 90% menor em comparação com os preços sob demanda.

A migração dos serviços de trabalho locais e do Windows existentes para a nuvem oferece uma oportunidade de modernização. Por exemplo, em vez de implementar um serviço do Windows, o .NET moderno permite que aplicações worker service sejam executados no Linux usando o gerenciador de serviços “systemd”. Para trabalhos em lote em grande escala baseados em contêineres, o AWS Batch elimina a necessidade de você configurar e gerenciar a infraestrutura computacional, além de simplificar a coordenação de trabalhos em várias AZs em uma região da AWS. No entanto, nem todas as cargas de trabalho são adequadas para o AWS Batch. Visite o que fazer e o que não fazer no AWS Batch para obter mais informações sobre as características das cargas de trabalho adequadas.

Para aplicações que geralmente têm vida curta e precisam estar disponíveis sob demanda, você pode usar serviços de computação sem servidor para processamento em segundo plano. Esses processos em segundo plano podem ser concluídos em um período de tempo muito curto (por exemplo, em segundos) e podem aproveitar as vantagens do AWS Lambda, que pode ser programado usando o Amazon EventBridge Scheduler ou pesquisado em uma fila do Amazon SQS (Figura 4).

Figura 4: Usando o Lambda para processos em segundo plano de curta duração

Para processos em segundo plano de execução mais longa, uma opção é hospedá-los com o Amazon EC2, o Amazon ECS ou o Amazon EKS. No entanto, ao usar esses serviços, é importante considerar os requisitos de disponibilidade e suas implicações de custo. As instâncias spot do Amazon EC2 podem ajudar você a minimizar os custos, mas esteja ciente de que o preço spot pode flutuar acima do preço máximo que você define quando a demanda de capacidade é alta, por isso é melhor usá-lo para cargas de trabalho tolerantes a falhas. Outra opção é dividir os processos em segundo plano em várias etapas menores que podem ser executadas por várias funções do Lambda usando o AWS Step Functions para orquestrá-las, conforme mostrado na Figura 5:

Figura 5: Usando o fluxo de trabalho padrão do Step Function para encadear várias funções lambda

Conclusão

A execução de cargas de trabalho .NET em uma instância Windows do Amazon EC2 ou em contêineres do Windows no Amazon ECS ou no Amazon EKS geralmente pode ser vista como a abordagem padrão. No entanto, é importante considerar as características da aplicação e outros fatores de influência, como operações, eficiência de desempenho e o custo para chegar ao serviço certo para hospedar cargas de trabalho.

Se você deseja criar uma nova aplicação .NET ou migrar as existentes para a nuvem, executar o .NET no Linux e aproveitar os serviços sem servidor — como AWS Lambda, AWS Step Functions e AWS Fargate — e a integração com outros serviços baseados em nuvem — como Amazon EventBridge, Amazon S3 e Amazon SQS — tende a produzir os melhores resultados.

A AWS tem significativamente mais serviços e mais recursos dentro desses serviços do que qualquer outro provedor de nuvem, tornando mais rápido, fácil e econômico mover suas aplicações existentes para a nuvem e criar praticamente qualquer coisa que você possa imaginar. Ofereça às suas aplicações Microsoft a infraestrutura de que elas precisam para gerar os resultados comerciais que você deseja. Visite nossos blogs sobre o .NET na AWS e AWS Database para obter orientações e opções adicionais para suas cargas de trabalho da Microsoft. Entre em contato conosco para iniciar sua jornada de migração e modernização hoje mesmo.

TAGS: .NET, Microsoft

Este blog em português é uma tradução do blog original em inglês.

Sobre o Autor

Adi Simon é arquiteto de soluções parceiras na AWS, especializado em migrar, executar e modernizar cargas de trabalho da Microsoft na AWS. Ele tem uma vasta experiência em design e desenvolvimento de software e trabalhou para uma empresa de consultoria de TI de nível 1 e instituições financeiras líderes.

Tradutores e Revisores

	Luiz Rampanelli é um Solutions Architect no time da AWS Latam. Possui mais de 10 anos de experiência com workloads Microsoft em nuvem e ambientes híbridos. Atua com desenho de soluções seguindo as melhores práticas para que os clientes possam aproveitar ao máximo os benefícios da nuvem da AWS.
	Marcelo Baptista é Solutions Architect no time de AWS LATAM. Trabalha com soluções de TI há mais de 30 anos, com experiência em vários seguimentos de mercado e diferentes ambientes tecnológicos. Especialista em DevOps, Computing e HPC, hoje atua como Arquiteto de Soluções, apoiando os clientes nos seus desafios, buscando as melhores soluções para as suas necessidades.