Criando aplicações .NET para AWS

A Amazon Web Services (AWS) é membro da .NET Foundation e um dos principais promotores da linguagem. Atualmente, os engenheiros da AWS dão suporte a vários produtos open source do .NET, dando suporte a esses projetos e a outros que estão em um crescimento contínuo.

O suporte inclui as plataformas mais modernas do .NET, inclusive a versão 3.1 do .NET Core.

Como o próprio nome indica, a AWS fornece um grande conjunto de serviços online, que variam de soluções de infraestrutura, como máquinas virtuais e gerenciamento de containers, até produtos de armazenamento, como bancos de dados específicos ou gerenciados, além de diversos outros produtos.

Como todos esses serviços são baseados na nuvem, toda a interação é feita por meio de chamadas de API (geralmente do tipo RESTful). Um desenvolvedor pode optar por interagir diretamente com essas APIs, no entanto, a AWS reconhece que isso adiciona complexidade a um projeto e, portanto, fornece ferramentas de desenvolvimento específicos para uma linguagem ou framework (SDK,
Software Development Kits, no inglês) que executam toda essa interação para o desenvolvedor.

Todos os SDKs da AWS fornecem suporte a todo ciclo de vida da API, como gerenciamento de credenciais, tentativas de uma requisição, empacotamento de dados e serialização. Tudo isso economiza tempo e esforço para um desenvolvedor que deseja interagir com os produtos e serviços da AWS.

Um exemplo de SDK específico é o SDK da AWS para o .NET.

O SDK para .NET

Em novembro de 2009, a AWS lançou seu SDK para o .NET, onde fornece uma estrutura que lhes permite fácil acesso aos seus serviços.

A AWS atualiza o SDK do .NET diariamente, portanto, é raro quando lançam um novo recurso ou serviço e o SDK não seja atualizado no mesmo dia. O SDK do .NET simplifica o uso dos serviços da AWS, fornecendo um conjunto de bibliotecas de maneira consistente e familiar às pessoas desenvolvedoras .NET.

Todo serviço da AWS acessível por meio de uma API possui um SDK disponível no NuGet em nuget.org. Os SDKs específicos do serviço seguem o padrão de nomeação do AWSSDK.ServiceName, conforme mostrado na Figura 1.
 

Figura 1- Configuração do NuGet no JetBrains Rider após pesquisar por AWS
 

Existem também algumas abstrações de alto nível que ajudam as pessoas desenvolvedoras a gerenciar melhor algumas das tarefas mais comuns, como logs, transferências de arquivos e autenticação. Essas abstrações de alto nível têm uma convenção de nomenclatura diferenciada, dada por AWS.AbstractionName. Um exemplo de uma abstração é o AWS.Logger. Esse SDK é uma biblioteca de alto nível que agrupa as bibliotecas mais comuns de log do .NET, oferecendo a capacidade de salvar os logs de entrada diretamente no serviço de monitoramento e observação do AWS, o CloudWatch. Podemos observar os diferentes pacotes do AWS.Logger NuGet na Figura 2.

Figura 2 - Gerenciador de Pacotes NuGet do Visual Studio 2019 após pesquisar por AWS.Logger
 

Quando é instalado um pacote AWSSDK de uma API específica, geralmente serão exibidos dois pacotes sendo instalados, o AWSSDK.Core e o AWSSDK.ServiceName, como é mostrado na Figura 3.
 

Figura 3 - Instalando o pacote AWSSDK.S3 no Visual Studio
 

Todos os pacotes de serviços dependem de uma biblioteca principal, que realiza o empacotamento, a assinatura das solicitações e demais tarefas para permitir o envio de requisições via API e o recebimento de respostas da AWS. Os pacotes específicos de serviço simplesmente expõem a API e as classes de modelo relacionadas àquele serviço. O mesmo pode acontecer se for instalado um SDK de alto nível. A Figura 2 mostra um pacote chamado AWS.Logger.Core. A instalação de qualquer um dos outros pacotes do AWS.Logger também instalará o pacote Core. Observe que isso não ocorre em todos os SDKs de alto nível.

Observando o pacote e as DLLs verificamos que ambos têm o mesmo nome. Assim, adicionar o pacote AWSSDK.S3 a um projeto resultará na adição de AWSSDK.S3.dll ao diretório \bin. Uma coisa a ser observada, é que embora o namespace seja semelhante ao nome do pacote e da DLL, eles não são idênticos. Embora o nome da .dll seja AWSSDK.S3.dll, como mostra a Figura 4, o namespace usado para acessar essa funcionalidade é Amazon.S3.
 

Figura 4 - Navegador de objetos do Visual Studio no AWSSDK.S3
 

Trabalhar com o SDK é semelhante a trabalhar com qualquer outra referência de projeto. Por exemplo, o serviço da AWS mostrado na Figura 4 é o S3, também conhecido como Amazon Simple Storage Service. O S3 é um serviço de armazenamento de objetos que oferece escalabilidade, disponibilidade de dados, segurança e desempenho. O código a seguir demonstra o uso do SDK para manter um arquivo no S3:

///<resumo> Exemplo de execução em uma aplicação web ASP.NET MVC  que salva o arquivo S3 de maneira assíncrona</resumo>
using Amazon;
using Amazon.S3;
using Amazon.S3.Model;
 
public async Task<string> SaveAsync(string path)
{   
    try
    {
        string fileName = "NDC-Booth.jpg";
        string filePath = Path.Combine(path, fileName);
        RegionEndpoint bucketRegion = RegionEndpoint.USWest2;
 
        var putRequest = new PutObjectRequest
        {
            BucketName = "infoq-article-bucket",
            Key = fileName,
            ContentType = "image/jpeg",
            FilePath = filePath
        };
 
        putRequest.Metadata.Add("x-amz-meta-title", "2020 AWS Booth at NDC London");
 
        using (IAmazonS3 client = new AmazonS3Client(bucketRegion))
        {
    var results = await client.PutObjectAsync(putRequest).ConfigureAwait(false);
           return results.ETag;            
        }
    }
    catch (AmazonS3Exception e)
    {
        logger.Error("Amazon error saving to S3", e);
    }
    catch (Exception e)
    {
        logger.Error("Unknown error saving to S3", e);
    }
    return null;
}  

Este exemplo copia uma imagem do diretório web local e o coloca no S3. Ao usar o SDK, não é necessário se preocupar em gerenciar a autenticação, a verificação ou as tentativas, pois elas simplesmente funcionam. Além disso, enquanto este exemplo usa um método assíncrono, uma versão síncrona que não retorna uma tarefa também está disponível para os casos em que uma abordagem síncrona seria mais apropriada. Nesse caso, o método síncrono seria mais parecido com o código abaixo:
 

public string Save(string path)
{
…
using (IAmazonS3 client = new AmazonS3Client(bucketRegion))
       {
            var response = client.PutObject(putRequest);
            return response.ETag;
       }
	…
}

Seu método de chamada também precisaria mudar devido à alteração no tipo de retorno. Para aqueles que trabalham no .NET Core, a comunicação assíncrona é o padrão; no entanto, a comunicação síncrona é comum em aplicações .NET mais antigas.

Toolkits da AWS

Como podemos ver, o SDK ajuda as pessoas desenvolvedoras a interagir com os serviços da AWS de dentro das aplicações .NET. No entanto, elas usam o SDK de forma programática, portanto, ele não oferece suporte à interação personalizada com os serviços da AWS. É aí que entram os Toolkits. Cada uma dos principais IDEs usadas para .NET possui seu próprio Toolkit. Atualmente, existem toolkits para Visual Studio, VS Code e JetBrains Rider, que são extensões projetadas para ajudar a criar, depurar e implantar aplicações .NET na AWS.

É possível instalar o toolkit através do IDE. No Visual Studio. Pode ser acessado via Extensions > Manage extensions > Visual Studio Marketplace, como mostra a Figura 5.
 

Figura 5 - Adicionando o AWS Toolkit ao Visual Studio 2019
 

No JetBrains Rider, é possível instalar o toolkit através do caminho, Configure > Plugins, na tela inicial, como mostra a Figura 6.
 

Figura 6 - Adicionar o AWS Toolkit ao JetBrains Rider
 

Após a instalação, o toolkit fornece acesso aos serviços da AWS por meio da IDE. Por exemplo, ao trabalhar no Visual Studio, o toolkit fornece um módulo adicional, o AWS Explorer. Após abrir o AWS Explorer, uma lista de diferentes serviços da AWS fica visível, exibindo com quais podemos trabalhar. A maioria deles permite criar ou excluir itens, além de modificar algumas das propriedades dos mesmos. A Figura 7 mostra o arquivo carregado do exemplo anterior.
 

Figura 7 - Usando o toolkit para examinar um arquivo carregado em um bucket S3
 

Os toolkits têm diferentes níveis de maturidade e suporte. Os toolkits do VS Code e do JetBrains, por exemplo, se concentram no desenvolvimento serverless, portanto, não há a mesma lista de serviços disponíveis no AWS Explorer. A Figura 8 mostra a janela do AWS Explorer no JetBrains Rider (a esquerda) e no VS Code (a direita).
 

Figura 8 - Janelas do AWS Explorer no JetBrains Rider e no VS Code
 

Os toolkits fornecem mais funcionalidade à IDE além da capacidade de gerenciar alguns dos serviços da AWS, que é a adição de mais opções de modelos de projeto, como mostra a Figura 9.
 

Figura 9 - Caixa de diálogo Novo Projeto do Visual Studio 2019 filtrada para modelos da AWS
 

Existem nove modelos adicionais no Visual Studio, principalmente na criação de aplicações serverless da AWS ou projetos Lambda em C#, F# e node.js. Todas as linguagens possuem suportes no Visual Studio e na AWS. O JetBrains Rider também tem um modelo a mais, o "AWS Serverless Application". O fato de haver apenas modelos de aplicações serverless é apropriado, pois esse é o único "tipo de aplicação" novo na AWS, todas as demais aplicações do lado do servidor no .NET já possuem suporte.

O último conjunto de recursos fornecidos pelo toolkit é a ajuda na implantação da aplicação .NET. O suporte fornecido pelo toolkit depende do tipo de projeto e da aplicação com a qual estamos trabalhando. Uma aplicação ASP.NET Core terá a opção de "Publish to AWS Elastic Beanstalk". Se a mesma aplicação tiver o suporte ao Docker ativado na solução .NET, ela obterá uma opção de implantação adicional para o "Publish Container to AWS". Podemos ver um exemplo na Figura 10.
 

Figura 10 - Opções de publicação ao trabalhar em uma aplicação ASP.NET Core no Docker
 

A escolha da abordagem "Publish to AWS Elastic Beanstalk" fará com que o toolkit nos guie pela implantação em um ambiente existente no Elastic Beanstalk ou nos ajude a configurar uma nova aplicação do Elastic Beanstalk. Embora não seja exatamente uma plataforma como serviço (PaaS), o Elastic Beanstalk se parece muito com um PaaS porque remove o trabalho de provisionar e configurar recursos da AWS. A implantação em uma nova instância exige várias decisões: (1) O tipo de instância do EC2 (máquina virtual) que desejamos usar, (2) se desejamos ou não implantar em várias instâncias e (3) que tipo de balanceador de carga iremos usar se implantarmos em mais de uma instância. Também podemos selecionar várias configurações de segurança ou seguir o padrão. Este é um excelente ponto de partida para aqueles que desejam lançar uma aplicação Web na AWS para ver como ela funciona.

As aplicações já configuradas para oferecer suporte ao Docker possuem recursos adicionais. Esses recursos giram em torno do Amazon Elastic Container Service (ECS) e permitem que as pessoas desenvolvedoras executem a aplicação como um serviço, como uma tarefa "run-right-now" ou como uma tarefa agendada. Também podemos fazer o upload da definição de container no Elastic Container Registry para que ela esteja disponível na seleção ao trabalhar no ECS. Se estivermos implantando um site, podemos selecionar a opção "service", como mostrado abaixo na Figura 11.
 

Figura 11 - Usando o Visual Studio para publicar um container na AWS
 

O processo de publicação também permite definir e selecionar permissões e balanceadores de carga. Depois de concluído, a aplicação estará disponível e poderá ser gerenciada da mesma forma que qualquer outro container, podendo aumentar ou diminuir a quantidade de containers em execução usando o balanceador de carga, configurando o dimensionamento automático ou executando outras tarefas específicas que são necessárias para garantir que a aplicação esteja disponível para consumo.

Outro suporte ao .NET

O .NET SDK e os toolkits para as IDEs não são as únicas ferramentas criadas pela AWS para oferecer suporte ao .NET. Existem também o AWS Tools para o PowerShell, o AWS Tools para o Azure DevOps (anteriormente chamado de AWS Tools para Visual Studio Team Services) e o AWS Extensions para a CLI do .NET. As Ferramentas da AWS para o PowerShell permitem que as pessoas desenvolvedoras e administradoras gerenciem os serviços e recursos da AWS no ambiente de script do PowerShell e suportem muitas das mesmas ações que o AWS SDK. As ferramentas do PowerShell também oferecem suporte à automação do gerenciamento de serviços da AWS, assim podemos gerenciar os recursos da AWS com as mesmas ferramentas do PowerShell nos ambientes Windows, Linux e MacOS.

As Ferramentas da AWS para o Azure DevOps não são específicas do .NET, mas são um conjunto de extensões para o Microsoft Team Foundation Server (TFS) e do Azure DevOps que facilitam a implantação das aplicações .NET usando a AWS. Podemos usar o processo de criação e lançamento existente para implantar aplicações diretamente no AWS Elastic Beanstalk ou no AWS Lambda, além de interagir com outros serviços, como o Amazon S3 ou o AWS CodeDeploy.

As extensões da AWS para o CLI do .NET são extensões de ferramentas adicionais focadas na criação e implantação de aplicações .NET Core e ASP.NET Core. Muitos desses comandos são os mesmos usados ​​no AWS Toolkit para Visual Studio, para que possamos testar a implantação inicial por meio do Visual Studio e, em seguida, usar a linha de comando para automatizar a implantação desse ponto em diante. Existem três conjuntos diferentes de extensão para o CLI do .NET, um para o Amazon ECS, um para o AWS Elastic Beanstalk e outro para o AWS Lambda.

A AWS apoia o desenvolvimento .NET há mais de uma década. Como mencionado anteriormente, muitos dos serviços da AWS, como o EC2 e o Lambda, têm suporte para várias versões do .NET incorporadas nos sistemas. Máquinas ou containers virtuais do Windows suportam todas as estruturas .NET, enquanto as VMs, containers e ambientes serverless baseados no Linux suportam o .NET Core. Os SDKs fornecem suporte programático aos serviços da AWS, permitindo que as pessoas desenvolvedoras não se preocupem com autenticação, tentativas de requisição ou outros problemas de infraestrutura, se concentrando na criação das aplicações.

Outras ferramentas disponíveis incluem os toolkits específicos da IDE que oferecem às pessoas desenvolvedoras a capacidade de interagir com vários serviços da AWS no navegador, o AWS Tools para PowerShell para gerenciar serviços da AWS no ambiente de script, o AWS Tools para Visual Studio Team Service e a AWS Extensions para o .NET CLI. Todas essas ferramentas são atualizadas regularmente, algumas diariamente, para acompanhar as mudanças que acontecem nos serviços da AWS, no .NET Framework e também para ajudar a acompanhar os paradigmas de desenvolvimento para melhorar o suporte à nuvem.

A AWS também procura contratar pessoas desenvolvedoras .NET experientes em todo o mundo. Podemos ver as vagas em aberto para pessoas interessadas em ajudar a AWS a melhorar ainda mais o universo .NET!

Sobre o autor

Com mais de 25 anos de experiência em desenvolvimento de software (mais de 15 somente em .NET), o Dr. Bill traz uma abordagem pragmática ao desenvolvimento de software. Com muito desse tempo investido em consultoria e projetos, trabalhou em uma variedade deles utilizando diversos designs e abordagens de desenvolvimento. Recentemente mudou para o lado sombrio da força e usa sua experiência de desenvolvimento em uma função de gerenciamento de produtos, na qual atua como Defensor das pessoas desenvolvedoras .NET da AWS, ajudando a criar uma experiência mais rica para elas.