As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Considerar o .NET sem servidor

Visão geral do

A computação sem servidor tornou-se uma abordagem conhecida para criar e implantar aplicações. Isso se deve principalmente à escalabilidade e à agilidade que a abordagem sem servidor oferece ao criar uma arquitetura moderna. No entanto, é importante considerar o impacto nos custos da computação sem servidor em alguns cenários.

O Lambda é uma plataforma de computação sem servidor que permite que os desenvolvedores executem códigos sem a necessidade de servidores dedicados. O Lambda é uma opção particularmente atraente para desenvolvedores .NET que buscam reduzir os custos de infraestrutura. Com o Lambda, os desenvolvedores .NET podem desenvolver e implantar aplicações altamente escaláveis e com potencial para otimizar custos. Ao usar uma abordagem sem servidor, os desenvolvedores não provisionam mais servidores para lidar com solicitações de aplicações. Em vez disso, os desenvolvedores podem criar funções que são executadas sob demanda. Isso torna uma abordagem sem servidor mais escalável, gerenciável e potencialmente mais econômica do que executar, gerenciar e escalar máquinas virtuais. Como resultado, você paga apenas pelos recursos usados pela aplicação, sem precisar se preocupar com os recursos subutilizados ou os custos de manutenção do servidor.

Os desenvolvedores podem usar versões modernas e multiplataforma do .NET para criar aplicações sem servidor que sejam rápidas, eficientes e econômicas. O .NET Core e as versões mais recentes são um framework gratuito e de código aberto que é mais adequado para execução em plataformas sem servidor em relação às versões anteriores do .NET Framework. Isso permite que os desenvolvedores reduzam o tempo de desenvolvimento e aumentem a performance da aplicação. O .NET Modern também é compatível com diversas linguagens de programação, incluindo C# e F#. Por esse motivo, é uma opção atraente para desenvolvedores que desejam criar arquiteturas modernas na nuvem.

Esta seção explica como você pode obter redução de custos usando o Lambda como uma opção sem servidor. Você pode otimizar ainda mais os custos fazendo o ajuste fino dos perfis de execução de suas funções do Lambda, dimensionando corretamente a alocação de memória das suas funções do Lambda, usando AOT nativo e migrando para funções baseadas em Graviton.

Impacto do custo

O quanto você pode reduzir custos depende de vários fatores, incluindo quantas execuções suas funções sem servidor executarão, além da quantidade de memória alocada e da duração de cada função. AWS Lambda oferece um nível gratuito, que inclui um milhão de solicitações gratuitas por mês e 400.000 GB de segundos de tempo de computação por mês. Você pode reduzir significativamente os custos mensais de workloads que estão dentro ou perto desses limites de nível gratuito.

Também pode haver custos adicionais ao usar um balanceador de carga com funções do Lambda como destino. Isso é calculado como a quantidade de dados processados pelo balanceador de carga para os destinos do Lambda.

Recomendações de otimização de custos

Dimensionar corretamente suas funções do Lambda

O dimensionamento correto é uma prática essencial para a otimização de custos em funções do Lambda baseadas em .NET. Esse processo envolve a identificação da configuração de memória ideal que equilibra performance e economia, sem exigir alterações no código.

Ao configurar a memória para uma função do Lambda, variando de 128 MB a 10.240 MB, você também ajusta a quantidade de vCPU disponível durante a invocação. Isso permite que aplicações vinculadas à memória ou à CPU acessem recursos adicionais durante a execução, levando a uma possível redução na duração da invocação e no custo geral.

No entanto, identificar a configuração ideal para suas funções do Lambda baseadas em .NET pode ser um processo manual e demorado, especialmente se as alterações forem frequentes. A ferramenta Power Tuning do AWS Lambda pode ajudar você a identificar a configuração apropriada analisando um conjunto de configurações de memória em relação a um exemplo de carga útil.

Por exemplo, aumentar a memória de uma função do Lambda baseada em .NET pode levar a um melhor tempo total de invocação e a um custo reduzido sem afetar a performance. A configuração de memória ideal para uma função pode variar. A ferramenta AWS Lambda Power Tuning pode ajudar a identificar a configuração mais econômica para cada função.

No gráfico de exemplo a seguir, o tempo total de invocação melhora à medida que a memória aumenta para essa função do Lambda. Isso leva a uma redução no custo da execução total sem afetar a performance original da função. Para essa função, a configuração de memória ideal para a função é de 512 MB, pois é aqui que a utilização de recursos é mais eficiente para o custo total de cada invocação. Isso varia de acordo com a função, e o uso da ferramenta em suas funções do Lambda pode identificar se elas se beneficiam do dimensionamento correto.

Recomendamos que você conclua esse exercício regularmente, como parte de qualquer teste de integração quando novas atualizações forem lançadas. Se houver atualizações com pouca frequência, faça esse exercício periodicamente para garantir que as funções estejam ajustadas e dimensionadas corretamente. Depois de identificar a configuração de memória apropriada para suas funções do Lambda, você pode adicionar o dimensionamento correto aos seus processos. A ferramenta AWS Lambda Power Tuning gera uma saída programática que pode ser usada por seus fluxos de trabalho de CI/CD durante o lançamento do novo código. Isso permite que você automatize a configuração de memória.

Você pode baixar a ferramenta Power Tuning do AWS Lambda gratuitamente. Para obter instruções sobre como usar a ferramenta, consulte Como executar a máquina de estado em GitHub.

O Lambda também é compatível com o AOT nativo, o que permite que aplicações .NET sejam pré-compiladas. Isso pode ajudar a reduzir custos ao diminuir os tempos de execução das funções .NET. Para obter mais informações sobre a criação de funções nativas de AOT, consulte .NET functions with native AOT compilation na documentação do Lambda.

Evitar tempo de espera ocioso

A duração da função do Lambda é uma dimensão usada para calcular o faturamento. Quando o código de função faz uma chamada de bloqueio, você é cobrado pelo tempo que ele espera para receber uma resposta. Esse tempo de espera pode aumentar quando as funções do Lambda são encadeadas ou quando uma função está atuando como orquestradora para outras funções. Se você tiver fluxos de trabalho, como operações em lote ou sistemas de entrega de pedidos, isso aumenta a sobrecarga de gerenciamento. Além disso, talvez não seja possível concluir toda a lógica do fluxo de trabalho e o tratamento de erros dentro do tempo limite máximo do Lambda de 15 minutos.

Em vez de lidar com essa lógica no código da função, recomendamos que você reestruture sua solução para usar o AWS Step Functions como orquestrador do fluxo de trabalho. Ao usar um fluxo de trabalho padrão, você é cobrado por cada transição de estado dentro do fluxo de trabalho, em vez da duração total do fluxo de trabalho. Além disso, você pode mover o suporte para novas tentativas, condições de espera, fluxos de trabalho de erro e retornos de chamada para a condição de estado a fim de permitir que suas funções do Lambda se concentrem na lógica de negócios. Para obter mais informações, consulte Otimizando seus AWS Lambda custos — Parte 2 no blog sobre AWS computação.

Migrar para funções baseadas em Graviton

As funções do Lambda alimentadas pelos processadores Graviton2 de próxima geração agora estão disponíveis ao público em geral. As funções do Graviton2, usando uma arquitetura de processador baseada em ARM, foram projetadas para oferecer uma performance até 19% melhor a um custo 20% menor para uma variedade de workloads sem servidor. Com menor latência e melhor performance, as funções baseadas em processadores Graviton2 são ideais para alimentar aplicações sem servidor de missão crítica.

A migração para funções do Lambda baseadas em Graviton pode ser uma opção econômica para desenvolvedores .NET que desejam otimizar seus custos do Lambda. As funções baseadas em Graviton usam processadores baseados em ARM em vez dos processadores x86 tradicionais. Isso pode levar a uma economia significativa de custos sem sacrificar a performance.

Embora haja vários benefícios em migrar para funções baseadas em Graviton, também há vários desafios e considerações que recomendamos que você considere. Por exemplo, funções baseadas em Graviton exigem o uso do Amazon Linux 2, que pode não ser compatível com todas as aplicações .NET. Além disso, pode haver problemas de compatibilidade com bibliotecas ou dependências de terceiros que não são compatíveis com processadores baseados em ARM.

Se você estiver executando aplicações .NET Framework e quiser aproveitar as vantagens da tecnologia sem servidor com o Lambda, considere a possibilidade de portar as aplicações para o .NET Modern usando o Assistente de Portabilidade para .NET. Isso pode ajudar você a acelerar a migração de aplicações .NET legadas para o .NET Modern, permitindo que a aplicação seja executada no Linux.

O gráfico a seguir compara os resultados das arquiteturas x86 e ARM/Graviton2 para uma função que calcula números primos.

A função está usando um único thread. A menor duração para as duas arquiteturas é relatada quando a memória é configurada com 1,8 GB. Acima disso, as funções do Lambda têm acesso a mais de uma vCPU, mas, nesse caso, a função não pode usar a capacidade adicional. Pelo mesmo motivo, os custos ficam estáveis com uma memória de até 1,8 GB. Com mais memória, os custos aumentam porque não há benefícios adicionais de performance para essa workload. O processador Graviton2 está claramente fornecendo melhor performance e custos mais baixos para essa função de computação intensiva.

Para configurar sua função para usar um processador baseado em ARM com Graviton, faça o seguinte:

Recursos adicionais do