Compartilhar via

Migrar cargas de trabalho lambda do AWS para o Azure Functions

A migração de uma carga de trabalho sem servidor que usa o Lambda do Amazon Web Services (AWS) para o Azure Functions requer um planejamento e implementação cuidadosos. Este artigo fornece diretrizes essenciais para ajudá-lo:

  • Execute um processo de descoberta em sua carga de trabalho existente.
  • Saiba como executar as principais atividades de migração, como planejamento de pré-migração e avaliação de carga de trabalho.
  • Avaliar e otimizar uma carga de trabalho migrada.

Escopo

Este artigo descreve a migração de uma instância lambda do AWS para o Azure Functions.

Este artigo não aborda:

  • Migração para sua própria solução de hospedagem de contêiner, como por meio dos Aplicativos de Contêiner do Azure.
  • Hospedando contêineres lambda do AWS no Azure.
  • Abordagens fundamentais de adoção do Azure por sua organização, como zonas de destino do Azure ou outros tópicos abordados na metodologia de migração do Cloud Adoption Framework.

Comparar funcionalidade

Este artigo mapeia os recursos lambda do AWS para equivalentes do Azure Functions para ajudar a garantir a compatibilidade.

Importante

Você pode optar por incluir a otimização em seu plano de migração, mas a Microsoft recomenda um processo de duas etapas. Migre as funcionalidades "like-to-like" primeiro e, em seguida, avalie as oportunidades de otimização no Azure.

Os esforços de otimização devem ser contínuos e executados por meio dos processos de controle de alterações da sua equipe de carga de trabalho. Uma migração que adiciona mais recursos durante uma migração incorre em risco e estende desnecessariamente o processo.

Perspectiva da carga de trabalho

Este artigo se concentra em como migrar uma carga de trabalho lambda do AWS para o Azure Functions e as dependências comuns para cargas de trabalho sem servidor. Esse processo pode envolver vários serviços porque as cargas de trabalho compreendem muitos recursos e processos para gerenciar esses recursos. Para ter uma estratégia abrangente, você deve combinar as recomendações apresentadas neste artigo com um plano maior que inclua os outros componentes e processos em sua carga de trabalho.

Executar um processo de descoberta em sua carga de trabalho existente

A primeira etapa é realizar um processo de descoberta detalhado para avaliar sua carga de trabalho lambda do AWS existente. O objetivo é entender em quais recursos e serviços da AWS sua carga de trabalho depende. Compile um inventário abrangente de suas funções lambda da AWS usando ferramentas do AWS, como SDKs, APIs, CloudTrail e CLI do AWS específicos do serviço para avaliar a carga de trabalho no AWS. Você deve entender os seguintes aspectos principais do inventário lambda da AWS:

  • Casos de uso
  • Configurações
  • Configurações de segurança e rede
  • Mecanismos de ferramentas, monitoramento, registro em log e observabilidade
  • Dependências
  • Objetivos de confiabilidade e status de confiabilidade atual
  • Custo de propriedade
  • Metas de desempenho e desempenho atual

Executar o planejamento de pré-imigração

Antes de começar a migrar sua carga de trabalho, você deve mapear os recursos do Lambda do AWS para o Azure Functions para garantir a compatibilidade e desenvolver um plano de migração. Em seguida, você pode selecionar as principais cargas de trabalho para uma prova de conceito.

Você também precisa mapear os serviços do AWS dos quais o Lambda depende para as dependências equivalentes no Azure.

Mapear recursos do Lambda do AWS para o Azure Functions

As tabelas a seguir comparam conceitos, recursos e propriedades lambda do AWS com seus equivalentes correspondentes no Azure Functions, especificamente, o plano de hospedagem de Consumo Flex.

Idiomas com suporte

Linguagem de programação Versões com suporte do Lambda do AWS Versões com suporte do Azure Functions
Node.js 20, 22 20, 22
Python 3.9, 3.10, 3.11, 3.12, 3.13 3.9, 3.10, 3.11
Java 8, 11, 17, 21 8, 11, 17, 21
PowerShell Sem suporte 7.4
.NET .NET 8 .NET 8, .NET 9, .NET Framework 4.8.1
Rubi 3.2, 3.3 Manipuladores personalizados
Vá Runtime somente do sistema operacional Manipuladores personalizados
Ferrugem Runtime somente do sistema operacional Manipuladores personalizados

Modelo de programação

Característica AWS Lambda Funções do Azure
Gatilhos Integra-se a outros serviços do AWS por meio de fontes de evento. Fornece maneiras automáticas e programáticas de vincular funções lambda com fontes de evento. Aciona uma função com base em eventos específicos, como atualizações em um banco de dados ou uma nova mensagem em uma fila. Por exemplo, um gatilho do Azure Cosmos DB permite que as funções respondam automaticamente a inserções e atualizações em um contêiner do Azure Cosmos DB. Essa ação permite o processamento em tempo real de alterações de dados.

O Functions também se integra à Grade de Eventos do Azure, para que possa processar eventos de serviços do Azure, como o Armazenamento do Azure e os Serviços de Mídia do Azure e fontes de eventos externos. A Grade de Eventos serve como um serviço centralizado e extensível de roteamento de eventos que complementa gatilhos do Functions e permite alta escalabilidade e ampla cobertura de fonte de eventos.
Vinculações Não tem associações. Usa SDKs do AWS em funções lambda para gerenciar manualmente interações com outros serviços do AWS. As associações, configuradas como entrada ou saída, permitem conexões declarativas com serviços, o que minimiza a necessidade de código do SDK explícito. Por exemplo, você pode configurar associações para ler do Armazenamento de Blobs, gravar no Azure Cosmos DB ou enviar emails por meio do SendGrid sem gerenciar manualmente as integrações.

Sobre gatilhos e associações

Serviço ou gatilho do AWS Lambda Gatilho do Azure Functions Descrição
Gateway de API: solicitações HTTP Gatilho HTTP Esses gatilhos permitem que você manipule diretamente as solicitações HTTP.
Serviço de Fila Simples (SQS) Gatilho do Armazenamento de Filas do Azure ou Gatilho do Barramento de Serviço do Azure Esses gatilhos podem processar mensagens em filas.
SNS (Serviço de Notificação Simples) Gatilho da Grade de Eventos ou Gatilho do Barramento de Serviço Esses gatilhos habilitam o processamento de notificação.
Kinesis (fluxos de dados) Gatilho de Hubs de Eventos Esses gatilhos consomem fluxos de dados.
DynamoDB (alterações de tabela) Gatilho de feed de alterações do Azure Cosmos DB Esses gatilhos monitoram as alterações nas tabelas.
Eventos do CloudWatch ou Agendador EventBridge Gatilho do temporizador Esses gatilhos lidam com funções agendadas ou baseadas em tempo.
S3 (eventos de objeto) Gatilho de Armazenamento de Blobs Esses gatilhos reagem a eventos no armazenamento de blobs.
Serviço de Banco de Dados Relacional da Amazon (RDS) Gatilho SQL do Azure Esses gatilhos reagem às alterações de banco de dados.
Streaming Gerenciado para Apache Kafka (MSK) Gatilho do Apache Kafka Esses gatilhos reagem às mensagens de tópico do Kafka.
Amazon ElastiCache Gatilho do Azure Redis Esses gatilhos reagem a mensagens no Redis.
Amazon MQ Gatilho do RabbitMQ Esses gatilhos reagem a mensagens no RabbitMQ.

Permissões

AWS Lambda Funções do Azure
A função de execução do Lambda concede permissões às funções Lambda para interagir com outros serviços da AWS. Cada função Lambda tem uma função IAM (gerenciamento de acesso e identidade) associada que determina suas permissões durante a execução. As identidades gerenciadas fornecem uma identidade para seu aplicativo de funções que permite que ele se autentique com outros serviços do Azure sem armazenar credenciais no código. O controle de acesso baseado em função atribui funções apropriadas à identidade gerenciada na ID do Microsoft Entra para conceder acesso aos recursos necessários.
Declarações de política baseadas em recursos

- AWSLambda_FullAccess fornece acesso total a todas as operações lambda, incluindo a criação, atualização e exclusão de funções.

- AWSLambda_ReadOnlyAccess fornece acesso somente leitura para exibir as funções lambda e suas configurações.

– Políticas de IAM personalizadas.		 Funções padrão baseadas em recursos:

- A função Proprietário fornece acesso total, incluindo o gerenciamento de permissões de acesso.

- A função Colaborador pode criar e excluir aplicativos de funções, definir configurações e implantar código. Não pode gerenciar o acesso.

- A função Leitor de Monitoramento pode conceder acesso somente leitura a dados e configurações de monitoramento. Ele também pode alocar funções personalizadas.

URL da função

AWS Lambda Funções do Azure
https://<url-id>.lambda-url.<region>.on.aws - <appname>.azurewebsites.net (original, nome do host padrão global)

- <appname>-<randomhash>.<Region>.azurewebsites.net (novo nome de host padrão exclusivo)

Rede

AWS Lambda Funções do Azure
Todas as funções Lambda são executadas com segurança dentro de uma VPC (nuvem virtual privada) gerenciada pelo sistema padrão. Você também pode configurar sua função Lambda para acessar recursos em um VPC personalizado. Os aplicativos de funções podem ser protegidos pela rede e podem acessar outros serviços dentro da rede. O acesso à rede de entrada pode ser restrito apenas a uma lista de firewall de endereços IP e a uma rede virtual específica por meio de pontos de extremidade de serviço ou pontos de extremidade privados. O acesso à rede de saída é habilitado por meio do recurso de integração de rede virtual. O aplicativo de funções pode ter todo o seu tráfego restrito à sub-rede de uma rede virtual e também pode acessar outros serviços dentro dessa rede virtual.

Observabilidade e monitoramento

AWS Lambda Funções do Azure
O Amazon CloudWatch ajuda no monitoramento e na observabilidade coletando e acompanhando métricas, agregando e analisando logs, definindo alarmes, criando painéis personalizados e implementando respostas automatizadas para alterações no desempenho e nas métricas de recursos. O Azure Monitor fornece monitoramento abrangente e observabilidade para o Azure Functions, especialmente por meio de seu recurso do Application Insights.

O Application Insights coleta dados de telemetria, como taxas de solicitação, tempos de resposta e taxas de falha. Ele visualiza as relações de componente do aplicativo, monitora o desempenho em tempo real, registra diagnósticos detalhados e permite o acompanhamento de métricas personalizado. Esses recursos ajudam a manter o desempenho, a disponibilidade e a confiabilidade do Azure Functions, ao mesmo tempo em que habilitam dashboards personalizados, alertas e respostas automatizadas.
O Lambda do AWS gera dados de telemetria de suas invocações de função e pode exportar esses dados usando semântica OpenTelemetry. Você pode configurar as funções Lambda para enviar dados de telemetria para qualquer endpoint compatível com OpenTelemetry. Essa ação permite a correlação de rastreamentos e logs, dados de telemetria consistentes baseados em padrões e integração com outras ferramentas de observabilidade que dão suporte ao OpenTelemetry. Configure seu aplicativo de funções para exportar dados de log e rastreamento em um formato OpenTelemetry. Você pode exportar dados de telemetria para qualquer endpoint compatível usando o OpenTelemetry. O OpenTelemetry oferece benefícios como correlação de rastreamentos e logs, dados de telemetria consistentes baseados em padrões e integração com outros provedores. Você pode habilitar o OpenTelemetry no nível do aplicativo de funções na configuração do host e no projeto de código para otimizar a exportação de dados do código de função. Para obter mais informações, consulte Usar o OpenTelemetry com o Azure Functions.

Dimensionamento e simultaneidade

AWS Lambda Funções do Azure
O AWS usa um modelo de dimensionamento sob demanda. Dimensiona automaticamente suas operações funcionais em resposta à demanda. A concorrência, ou o número de solicitações manipuladas por uma instância, é sempre 1. As instâncias são adicionadas e removidas dinamicamente com base no número de eventos de entrada e na simultaneidade configurada para cada instância. Você pode definir a configuração de simultaneidade para o valor desejado.
A concorrência é sempre 1. A simultaneidade é configurável (>1).
Permite o escalonamento para 0. Permite o escalonamento para 0.

Proteção de partida a frio

AWS Lambda Funções do Azure
A simultaneidade provisionada reduz a latência e garante o desempenho previsível da função ao inicializar previamente um número solicitado de instâncias de função. A simultaneidade provisionada atende a aplicativos sensíveis à latência e é precificada separadamente da simultaneidade padrão. Os aplicativos de funções permitem que você configure a simultaneidade para cada instância, o que impulsiona sua escala. Várias tarefas podem ser executadas em paralelo na mesma instância do aplicativo, e as tarefas subsequentes na instância não incorrem na inicialização a frio. Os aplicativos de funções também têm instâncias sempre prontas . Os clientes podem especificar um número de instâncias pré-aquecidas para eliminar a latência de partida a frio e garantir um desempenho consistente. Os aplicativos de funções também se expandem para mais instâncias com base na demanda, enquanto mantêm as instâncias sempre prontas.
A simultaneidade reservada especifica o número máximo de instâncias simultâneas que uma função pode ter. Esse limite garante que uma parte da cota de simultaneidade da sua conta seja reservada exclusivamente para essa função. O Lambda do AWS é dimensionado dinamicamente para lidar com solicitações de entrada mesmo quando a simultaneidade reservada é definida, desde que as solicitações não excedam o limite de simultaneidade reservado especificado. O limite inferior para simultaneidade reservada no Lambda do AWS é 1. O limite superior para simultaneidade reservada no AWS Lambda é determinado pela cota de simultaneidade regional da conta. Por padrão, esse limite é de 1.000 operações simultâneas para cada região. O Azure Functions não tem um recurso equivalente à simultaneidade reservada. Para obter uma funcionalidade semelhante, isole funções específicas em aplicativos de funções separados e defina o limite máximo de expansão para cada aplicativo. O Azure Functions dimensiona dinamicamente ou adiciona mais instâncias e dimensiona ou remove instâncias dentro do conjunto de limites de expansão. Por padrão, os aplicativos executados em um plano de Consumo Flex começam com um limite configurável de 100 instâncias gerais. O menor valor máximo de contagem de instâncias é 40 e o valor máximo de contagem de instâncias com suporte mais alto é 1.000. As cotas de memória de assinatura regional também podem limitar o alcance de escalabilidade dos aplicativos de funções, mas você pode aumentar essa cota chamando o suporte.

Preços

AWS Lambda Funções do Azure
- Pagamento por uso para a contagem total de invocações e para os GB/s de cada instância (com uma concorrência fixa de 1)

- Incrementos de 1 ms

- Camada gratuita de 400.000 Gbps		 - Pagamento por uso para a contagem total de invocações e para os gigabytes por segundo de cada instância (com invocações simultâneas configuráveis)

- Incrementos de 100 ms

- Camada gratuita de 100.000 Gbps

- Custos baseados em consumo

Armazenamento de código-fonte

AWS Lambda Funções do Azure
O Lambda do AWS gerencia o armazenamento do código de função em seu próprio sistema de armazenamento gerenciado. Você não precisa fornecer mais armazenamento. O Functions requer um contêiner de Armazenamento de Blobs fornecido pelo cliente para manter o pacote de implantação que contém o código do aplicativo. Você pode definir as configurações para usar a mesma conta de armazenamento ou uma conta de armazenamento diferente para implantações e gerenciar métodos de autenticação para acessar o contêiner.

Desenvolvimento local

Recurso Lambda do AWS Recurso do Azure Functions
- CLI de SAM

- LocalStack		 – Ferramentas principais do Azure Functions

- Visual Studio Code

– Visual Studio

- Codespaces do GitHub

- VSCode.dev

- Maven

- Codificar e testar o Azure Functions localmente

Implantação

Característica AWS Lambda Funções do Azure
Pacote de implantação - Arquivo ZIP

- Imagem do contêiner		 Arquivo ZIP (para implantação de imagem de contêiner, utilize um SKU do tipo dedicado ou premium.)
Tamanho do arquivo ZIP (console) Máximo de 50 MB Máximo de 500 MB para implantação ZIP
Tamanho do arquivo ZIP (CLI/SDK) Limite máximo de 250 MB para implantação de arquivo ZIP, limite máximo de 500 MB para arquivos descompactados. Máximo de 500 MB para implantação ZIP
Tamanho da imagem do contêiner Máximo de 10 GB Suporte a contêineres com armazenamento flexível por meio do Azure
Manipulação de artefatos grandes Use imagens de contêiner para implantações maiores. Anexe compartilhamentos de Armazenamento de Blobs ou Arquivos do Azure para acessar arquivos grandes do aplicativo.
Empacotando dependências comuns em funções Camadas Implantação. Zip, sob demanda do armazenamento ou contêineres (somente ACA, dedicados, SKUs EP)
Implantação azul-verde ou versionamento de funções Use qualificadores de função para fazer referência a um estado específico da função usando um número de versão ou um nome de alias. Os qualificadores permitem o gerenciamento de versão e estratégias de implantação gradual. Use a integração contínua e os sistemas de entrega contínua para implantações azul-verde.

Tempo limite e limites de memória

Característica Limites do Lambda do AWS Limites do Azure Functions
Tempo limite de execução 900 segundos (15 minutos) O tempo limite padrão é de 30 minutos. O tempo limite máximo é ilimitado. No entanto, o período de carência dado a uma execução de função é de 60 minutos durante o dimensionamento e 10 minutos durante as atualizações da plataforma. Para obter mais informações, consulte Tempo limite do aplicativo de funções.
Memória configurável 128 MB a 10.240 MB, em incrementos de 64 MB O Functions dá suporte a tamanhos de instância de 2 GB e 4 GB . Cada região em uma determinada assinatura tem um limite de memória de 512.000 MB para todas as instâncias de aplicativos, o que pode aumentar chamando o suporte. O uso total de memória de todas as instâncias em todos os aplicativos de funções em uma região deve permanecer dentro dessa cota.

Embora 2 GB e 4 GB sejam as opções de tamanho da instância, a simultaneidade para cada instância pode ser maior que 1. Portanto, uma única instância pode lidar com várias execuções simultâneas, dependendo da configuração. Configurar a simultaneidade adequadamente pode ajudar a otimizar o uso de recursos e gerenciar o desempenho. Ao balancear as configurações de alocação e simultaneidade de memória, você pode gerenciar efetivamente os recursos alocados para seus aplicativos de funções e garantir um desempenho eficiente e controle de custo. Para obter mais informações, consulte cotas de memória de assinatura regionais.

Gerenciamento de segredos

AWS Lambda Funções do Azure
O Gerenciador de Segredos da AWS permite que você armazene, gerencie e recupere segredos, como credenciais de banco de dados, chaves de API e outras informações confidenciais. As funções Lambda podem recuperar segredos usando o SDK do AWS. Recomendamos que você use abordagens sem segredo, como identidades gerenciadas, para habilitar o acesso seguro aos recursos do Azure sem credenciais de codificação. Quando os segredos são necessários, como para sistemas de parceiros ou herdados, o Azure Key Vault fornece uma solução segura para armazenar e gerenciar segredos, chaves e certificados.
O Repositório de Parâmetros do AWS Systems Manager é um serviço que armazena dados e segredos de configuração. Os parâmetros podem ser criptografados usando o KMS do AWS e recuperados por funções Lambda usando o SDK do AWS.
As funções Lambda podem armazenar configurações em variáveis de ambiente. Dados confidenciais podem ser criptografados com uma chave KMS para acesso seguro.		 O Azure Functions usa as configurações do aplicativo para armazenar dados de configuração. Essas configurações são mapeadas diretamente para variáveis de ambiente para facilitar o uso dentro da função. Essas configurações podem ser criptografadas e armazenadas com segurança na configuração do Serviço de Aplicativo do Azure.
Para cenários mais avançados, a Configuração de Aplicativos do Azure fornece recursos robustos para gerenciar várias configurações. Ele habilita a sinalização de recursos e dá suporte a atualizações dinâmicas em todos os serviços.

Gerenciamento de estado

AWS Lambda Funções do Azure
O AWS Lambda manipula o gerenciamento de estado simples usando serviços como Amazon S3 para armazenamento de objetos, DynamoDB para armazenamento de estado NoSQL rápido e escalonável e SQS para tratamento de fila de mensagens. Esses serviços garantem a persistência e a consistência de dados em execuções de função Lambda. O Azure Functions usa AzureWebJobsStorage para gerenciar o estado habilitando associações e gatilhos com serviços de Armazenamento do Azure, como Armazenamento de Blobs, Armazenamento de Filas e Armazenamento de Tabelas. Ele permite que as funções leiam e escrevam facilmente o estado. Para um gerenciamento de estado mais complexo, o Durable Functions fornece recursos avançados de orquestração de fluxo de trabalho e persistência de estado usando o Armazenamento do Azure.

Orquestração com estado

AWS Lambda Funções do Azure
Nenhuma orquestração nativa de estado. Use as funções de etapa do AWS para fluxos de trabalho. Durable Functions ajuda no gerenciamento de estado complexo, fornecendo orquestração de fluxo de trabalho durável e entidades com estado persistente. Isso permite operações de execução longa, pontos de verificação automáticos e persistência de estado confiável. Esses recursos permitem criar fluxos de trabalho complexos para garantir a tolerância a falhas e a escalabilidade para aplicativos com estado.

Outras diferenças e considerações

Característica AWS Lambda Funções do Azure
Funções de agrupamento Cada função Lambda do AWS é uma entidade independente. Um aplicativo de funções serve como um contêiner para várias funções. Ele fornece um contexto de execução compartilhado e uma configuração para as funções que ele contém. Tratar várias funções como uma única entidade simplifica a implantação e o gerenciamento. As funções também usam uma estratégia de dimensionamento por função, em que cada função é dimensionada independentemente, exceto para gatilhos HTTP, Armazenamento de Blobs e Funções Duráveis. Essas funções disparadas são dimensionadas em seus próprios grupos.
Domínios personalizados Habilitado por meio do Gateway de API Você pode configurar domínios personalizados diretamente em um aplicativo de funções ou no Gerenciamento de API do Azure.
Suporte a contêiner personalizado Dá suporte a contêineres personalizados por meio da Imagem de Contêiner lambda O Azure Functions dá suporte a contêineres personalizados executados em um ambiente de Aplicativos de Contêiner.

Criar um plano de migração

  1. Selecione as principais cargas de trabalho para uma prova de conceito.

    Comece selecionando uma a duas cargas de trabalho não críticas de tamanho médio do inventário total. Esse conjunto de tarefas serve como base para seu projeto piloto de migração. Você pode testar o processo e identificar possíveis desafios sem arriscar grandes interrupções em suas operações.

  2. Teste iterativamente e reúna comentários.

    Use a prova de conceito para coletar comentários, identificar lacunas e ajustar o processo antes de dimensionar para cargas de trabalho maiores. Essa abordagem iterativa garante que, quando você iniciar a migração em larga escala, resolva os desafios potenciais e refine o processo.

Construir os ativos de migração

Esta etapa é uma fase de desenvolvimento transitório. Durante essa fase, você cria o código-fonte, modelos de IaC (infraestrutura como código) e pipelines de implantação para representar a carga de trabalho no Azure. Você deve adaptar o código de função para compatibilidade e práticas recomendadas antes de executar a migração.

Adaptar código de função, arquivos de configuração e infraestrutura como arquivos de código

Para atualizar o código para os requisitos de runtime do Azure Functions:

Os snippets a seguir são exemplos de código SDK comum. O código AWS Lambda corresponde aos gatilhos, associações ou trechos de código do SDK correspondentes no Azure Functions.

Leitura de dados do Amazon S3 versus Azure Blob Storage

Código Lambda do AWS (SDK)

const AWS = require('aws-sdk');
const s3 = new AWS.S3();

exports.handler = async (event) => {
const params = {
Bucket: 'my-bucket',
Key: 'my-object.txt',
};
const data = await
s3.getObject(params).promise();
console.log('File content:',
data.Body.toString());
};

Código do Azure Functions (gatilho)

import { app } from '@azure/functions';

app.storageblob('blobTrigger', { 
path: 'my-container/{blobName}',
connection: 'AzureWebJobsStorage',
}, async (context, myBlob) => { 
context.log(`Blob content:
${myBlob.toString()}`);
});

Escrevendo no Amazon Simple Queue Service (SQS) vs Armazenamento de Filas do Azure

Código Lambda do AWS (SDK)

const AWS = require('aws-sdk');
const sqs = new AWS.SQS(); 

exports.handler = async (event) => {
const params = {
QueueUrl:
'https://sqs.amazonaws.com/123456789012/MyQueue',
MessageBody: 'Hello, world!',
};
await
sqs.sendMessage(params).promise();
};

Código do Azure Functions (gatilho)

import { app } from '@azure/functions';

app.queue('queueTrigger', { 
queueName: 'myqueue-items',
connection: 'AzureWebJobsStorage',
}, async (context, queueMessage) => {
context.log(`Queue message: 
${queueMessage}`);
});

Escrevendo no DynamoDB versus Azure Cosmos DB

Código Lambda do AWS (SDK)

const AWS = require('aws-sdk'); 
const dynamoDb = new AWS.DynamoDB.DocumentClient();   

exports.handler = async (event) => { 
const params = { 
TableName: 'my-table', 
Key: { id: '123' }, 
}; 
const data = await dynamoDb.get(params).promise(); 
console.log('DynamoDB record:', data.Item); 
};

Código do Azure Functions (gatilho)

import { app } from '@azure/functions';  

app.cosmosDB('cosmosTrigger', { 
connectionStringSetting: 'CosmosDBConnection', 
databaseName: 'my-database', 
containerName: 'my-container', 
leaseContainerName: 'leases', 
}, async (context, documents) => { 
documents.forEach(doc => { 
context.log(`Cosmos DB document: ${JSON.stringify(doc)}`); 
}); 
});

Eventos do Amazon CloudWatch versus um gatilho de temporizador do Azure

Código Lambda do AWS (SDK)

exports.handler = async (event) => {
console.log('Scheduled event:', event); 
};

Código do Azure Functions (gatilho)

import { app } from '@azure/functions'; 

app.timer('timerTrigger', { schedule: '0 */5 * * * *', // Runs every 5 minutes }, async (context, myTimer) => { if (myTimer.isPastDue) { context.log('Timer is running late!'); } context.log(Timer function executed at: ${new Date().toISOString()}); });

SNS (Serviço de Notificação Simples) do Amazon versus um gatilho da Grade de Eventos do Azure

Código Lambda do AWS (SDK)

const AWS = require('aws-sdk'); 
const sns = new AWS.SNS();   

exports.handler = async (event) => { 
const params = { 
Message: 'Hello, Event Grid!', 
TopicArn: 'arn:aws:sns:us-east-1:123456789012:MyTopic', 
}; 
await sns.publish(params).promise(); 
};

Código do Azure Functions (gatilho)

import { app } from '@azure/functions'; 

app.eventGrid('eventGridTrigger', {}, 
async (context, eventGridEvent) => { 

context.log(`Event Grid event: 
${JSON.stringify(eventGridEvent)}`); 

});

Amazon Kinesis versus um gatilho dos Hubs de Eventos do Azure

Código Lambda do AWS (SDK)

const AWS = require('aws-sdk'); 
const kinesis = new AWS.Kinesis();   

exports.handler = async (event) => { 
const records = 
event.Records.map(record => 
Buffer.from(record.kinesis.data, 
'base64').toString()); 
console.log('Kinesis records:', records); 
};

Código do Azure Functions (gatilho)

import { app } from '@azure/functions'; 
app.eventHub('eventHubTrigger', {  
connection: 'EventHubConnection',  
eventHubName: 'my-event-hub',  
}, async (context, eventHubMessages) => 
{  
eventHubMessages.forEach(message => 
{  
context.log(`Event Hub message: 
${message}`);  
});  
});

Consulte os seguintes repositórios do GitHub para comparar o código Lambda do AWS e o código do Azure Functions:

Ajustar as configurações

Verifique se o tempo limite da função e as configurações de memória são compatíveis com o Azure Functions. Para obter mais informações sobre configurações configuráveis, consulte host.json referência para o Azure Functions.

Siga as práticas recomendadas para permissões, acesso, rede e configurações de implantação.

Configurar permissões

Siga as práticas recomendadas ao configurar permissões em seus aplicativos de funções. Para obter mais informações, consulte Configurar o aplicativo de funções e a conta de armazenamento com a identidade gerenciada.

main.bicep

// User-assigned managed identity that the function app uses to reach Storage and Service Bus
module processorUserAssignedIdentity './core/identity/userAssignedIdentity.bicep' = {
  name: 'processorUserAssignedIdentity'
  scope: rg
  params: {
    location: location
    tags: tags
    identityName: !empty(processorUserAssignedIdentityName) ? processorUserAssignedIdentityName : '${abbrs.managedIdentityUserAssignedIdentities}processor-${resourceToken}'
  }
}

Para obter mais informações, consulte rbac.bicep.

Configurar o acesso à rede

O Azure Functions dá suporte à integração de rede virtual, que fornece acesso ao aplicativo de funções aos recursos em sua rede virtual. Após a integração, seu aplicativo roteia o tráfego de saída pela rede virtual. Em seguida, seu aplicativo pode acessar recursos ou pontos de extremidade privados usando regras que só permitem tráfego proveniente de sub-redes específicas. Se o destino for um endereço IP fora da rede virtual, o endereço IP de origem será um dos endereços listados nas propriedades do aplicativo, a menos que você configure um gateway NAT.

Ao habilitar a integração de rede virtual para seus aplicativos de funções, siga as práticas recomendadas no TSG para integração de rede virtual para aplicativos Web e aplicativos de funções.

main.bicep

// Virtual network and private endpoint
module serviceVirtualNetwork 'app/vnet.bicep' = {
  name: 'serviceVirtualNetwork'
  scope: rg
  params: {
    location: location
    tags: tags
    vNetName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
  }
}  

module servicePrivateEndpoint 'app/storage-PrivateEndpoint.bicep' = {
  name: 'servicePrivateEndpoint'
  scope: rg
  params: {
    location: location
    tags: tags
    virtualNetworkName: !empty(vNetName) ? vNetName : '${abbrs.networkVirtualNetworks}${resourceToken}'
    subnetName: serviceVirtualNetwork.outputs.peSubnetName
    resourceName: storage.outputs.name
  }
}

Para obter mais informações, consulte VNet.bicep e storage-PrivateEndpoint.bicep.

Definir configurações de implantação

As implantações seguem um único caminho. Depois de compilar o código do projeto e fechá-lo em um pacote de aplicativos, implante-o em um contêiner de Armazenamento de Blobs. Quando o aplicativo é iniciado, ele obtém o pacote e executa o código de função a partir dele. Por padrão, a mesma conta de armazenamento que armazena metadados de host internos, como AzureWebJobsStorage, também serve como o contêiner de implantação. No entanto, você pode usar uma conta de armazenamento alternativa ou escolher seu método de autenticação preferencial definindo as configurações de implantação do aplicativo. Para obter mais informações, consulte detalhes da tecnologia de implantação e defina as configurações de implantação.

Gerar arquivos IaC

  • Use ferramentas como Bicep, modelos do Azure Resource Manager ou Terraform para criar arquivos IaC para implantar recursos do Azure.

  • Defina recursos como o Azure Functions, contas de armazenamento e componentes de rede em seus arquivos IaC.

  • Use este repositório de exemplos de IaC para exemplos que usam recomendações e práticas recomendadas do Azure Functions.

Use ferramentas para refatoração

Use ferramentas como o GitHub Copilot no VS Code para obter ajuda com refatoração de código, refatoração manual para alterações específicas ou outros auxílios de migração.

Observação

Use o Modo do agente no GitHub Copilot no VS Code.

Os artigos a seguir fornecem exemplos específicos e etapas detalhadas para facilitar o processo de migração:

Desenvolver um processo passo a passo para a migração do dia 0

Desenvolva estratégias de failover e failback para sua migração e teste-as minuciosamente em um ambiente de pré-produção. Recomendamos que você execute testes de ponta a ponta antes de finalmente fazer a transição do Lambda do AWS para o Azure Functions.

  • Validar funcionalidade

    • Código e teste o Azure Functions localmente.

    • Teste cada função minuciosamente para garantir que ela funcione conforme o esperado. Esses testes devem incluir entrada/saída, gatilhos de evento e verificação de associações.

    • Use ferramentas como extensões curl ou REST Client no VS Code para enviar solicitações HTTP para funções disparadas por HTTP.

    • Para outros gatilhos, como temporizadores ou filas, verifique se os gatilhos são disparados corretamente e as funções são executadas conforme o esperado.

  • Validar o desempenho

    • Realize testes de desempenho para comparar a nova implantação do Azure Functions com a implantação anterior do Lambda do AWS.

    • Monitore métricas como tempo de resposta, tempo de execução e consumo de recursos.

    • Use o Application Insights para monitoramento, análise de log e solução de problemas durante a fase de teste.

  • Solucionar problemas usando o recurso diagnosticar e resolver problemas

    Use o recurso diagnosticar e resolver problemas no portal do Azure para solucionar problemas de seu aplicativo de funções. Essa ferramenta fornece um conjunto de recursos de diagnóstico que podem ajudá-lo a identificar e resolver problemas comuns rapidamente, como falhas de aplicativo, degradação de desempenho e problemas de configuração. Siga as etapas e recomendações de solução de problemas guiadas que a ferramenta fornece para resolver problemas que você identifica.

Avaliar o estado final da carga de trabalho migrada

Antes de desativar recursos na AWS, você precisa ter certeza de que a plataforma atende às expectativas atuais de carga de trabalho e que nada bloqueia a manutenção da carga de trabalho ou o desenvolvimento adicional.

Implantar e testar funções para validar o desempenho e a correção.

Publicar no Azure

Implante cargas de trabalho usando o recurso de publicação do VS Code . Você também pode implantar cargas de trabalho da linha de comando usando as Ferramentas Principais do Azure Functions ou a CLI do Azure. O Azure DevOps e o GitHub Actions também usam o One Deploy.

Explorar cenários de migração de exemplo

Use o repositório MigrationGetStarted como um modelo para iniciar sua prova de conceito. Esse repositório inclui um projeto pronto para implantar o Azure Functions que tem a infraestrutura e os arquivos de código-fonte para ajudá-lo a começar.

Se preferir usar o Terraform, use o MigrationGetStarted-Terraform em vez disso.

Otimizar e monitorar o desempenho do aplicativo no Azure

Depois de migrar sua carga de trabalho, recomendamos que você explore mais recursos no Azure. Esses recursos podem ajudá-lo a atender aos requisitos futuros de carga de trabalho e ajudar a fechar lacunas.

Usar o Application Insights para monitoramento e solução de problemas

Habilite o Application Insights para seu aplicativo de funções para coletar dados de telemetria detalhados para monitoramento e solução de problemas. Você pode habilitar o Application Insights por meio do portal do Azure ou no arquivo de configuração host.json do aplicativo de funções. Depois de habilitar o Application Insights, você pode:

  • Coletar dados de telemetria. O Application Insights fornece vários dados de telemetria, como logs de solicitação, métricas de desempenho, exceções e dependências.

  • Analise logs e métricas. Acesse o painel do Application Insights no portal do Azure para visualizar e analisar logs, métricas e outros dados de telemetria. Use as ferramentas internas para criar consultas personalizadas e visualizar dados para obter insights sobre o desempenho e o comportamento do seu aplicativo de funções.

  • Configurar alertas. Configure alertas no Application Insights para notificar você sobre problemas críticos, degradação de desempenho ou eventos específicos. Esses alertas ajudam você a monitorar proativamente e responder rapidamente aos problemas.

Otimizar para custo e desempenho

  • Dimensionamento e otimização de desempenho:

    • Use recursos de dimensionamento automático para lidar com cargas de trabalho variadas com eficiência.

    • Otimize o código de função para melhorar o desempenho reduzindo o tempo de execução, otimizando dependências e usando práticas de codificação eficientes.

    • Implemente estratégias de cache para reduzir o processamento e a latência repetidos para dados acessados com frequência.

  • Gerenciamento de custos:

    • Use as ferramentas de Gerenciamento de Custos da Microsoft para monitorar e analisar os custos do Azure Functions.

    • Configure alertas de orçamento e custo para gerenciar e prever despesas efetivamente.