Partilhar via

Migrar cargas de trabalho do AWS Lambda para o Azure Functions

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

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

Âmbito de aplicação

Este artigo descreve a migração de uma instância do AWS Lambda 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 de Aplicativos de Contêiner do Azure.
  • Hospedagem de contêineres do AWS Lambda no Azure.
  • Abordagens fundamentais de adoção do Azure pela sua organização, como zonas de aterrissagem do Azure ou outros tópicos abordados na metodologia de migração do Cloud Adoption Framework.

Comparar funcionalidade

Este artigo mapeia recursos do AWS Lambda 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 primeiro funcionalidades "semelhantes a semelhantes" e, em seguida, avalie oportunidades de otimização no Azure.

Os esforços de otimização devem ser contínuos e executados através 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.

Perspetiva da carga de trabalho

Este artigo se concentra em como migrar uma carga de trabalho do AWS Lambda 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 é conduzir um processo de descoberta detalhado para avaliar sua carga de trabalho existente do AWS Lambda. 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 do AWS Lambda usando ferramentas da AWS, como SDKs específicos de serviço, APIs, CloudTrail e AWS CLI para avaliar a carga de trabalho na AWS. Você deve entender os seguintes aspectos-chave do seu inventário do AWS Lambda:

  • Casos de uso
  • Configurações
  • Configurações de segurança e rede
  • Ferramentas, monitorização, registo e mecanismos de observabilidade
  • Dependências
  • Objetivos de fiabilidade e estado de fiabilidade atual
  • Custo de propriedade
  • Metas de desempenho e desempenho atual

Executar o planeamento de pré-migração

Antes de começar a migrar sua carga de trabalho, você deve mapear os recursos do AWS Lambda 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 da AWS dos quais o Lambda depende para as dependências equivalentes no Azure.

Mapeie recursos do AWS Lambda para o Azure Functions

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

Idiomas suportados

Linguagem de programação Versões compatíveis com o AWS Lambda Versões suportadas do Azure Functions
Node.js 20, 22 20, 22
Píton 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 Não suportado 7.4
.NET .NET 8 .NET 8, .NET 9, .NET Framework 4.8.1
Rubi 3.2, 3.3 Manipuladores personalizados
Vai! Tempo de execução somente do sistema operacional Manipuladores personalizados
Ferrugem Tempo de execução somente do sistema operacional Manipuladores personalizados

Modelo de programação

Característica AWS Lambda Funções do Azure
Acionadores Integra-se com outros serviços da AWS via fontes de eventos. Fornece maneiras automáticas e programáticas de vincular funções do Lambda a fontes de eventos. 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. Esta ação permite o processamento em tempo real das alterações de dados.

O Functions também se integra à Grade de Eventos do Azure, para que possa processar eventos dos serviços do Azure, como o Armazenamento do Azure e os Serviços de Mídia do Azure, e fontes de eventos externas. O Event Grid serve como um serviço de roteamento de eventos centralizado e extensível que complementa os gatilhos do Functions, permitindo alta escalabilidade e ampla cobertura de fontes de eventos.
Vínculos Não tem vinculações. Usa SDKs da AWS em funções do Lambda para gerenciar manualmente interações com outros serviços da 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 SDK explícito. Por exemplo, você pode configurar associações para ler do Armazenamento de Blobs, gravar no Azure Cosmos DB ou enviar emails via SendGrid sem gerenciar manualmente as integrações.

Gatilhos e vinculações de eventos

Gatilho ou serviço do AWS Lambda Disparador do Azure Functions Descrição
API Gateway: solicitações HTTP Acionador HTTP Esses gatilhos permitem que você manipule solicitações HTTP diretamente.
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.
Serviço de Notificação Simples (SNS) Gatilho de grade de eventos ou gatilho do Service Bus Esses gatilhos permitem o processamento de notificações.
Kinesis (fluxos de dados) gatilho do Event Hubs Esses gatilhos consomem fluxos de dados.
DynamoDB (alterações de tabela) Gatilho de fluxo de alterações do Azure Cosmos DB Esses gatilhos escutam as alterações nas tabelas.
CloudWatch Events ou EventBridge Scheduler Gatilho do temporizador Esses gatilhos lidam com funções agendadas ou baseadas em tempo.
S3 (eventos de objetos) Gatilho de armazenamento de Blob Esses gatilhos reagem a eventos do armazenamento de blobs.
Serviço da Base de Dados Relacional da Amazon (RDS) Gatilho SQL do Azure Esses gatilhos reagem a alterações no banco de dados.
Streaming gerenciado para Apache Kafka (MSK) Apache Kafka disparador Esses gatilhos reagem às mensagens do tópico Kafka.
Amazon ElastiCache Gatilho Redis do Azure Esses gatilhos reagem a mensagens no Redis.
Amazon MQ Disparador 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 do Lambda para interagir com outros serviços da AWS. Cada função do Lambda tem uma função de gerenciamento de identidade e acesso (IAM) associada que determina suas permissões enquanto é executada. As identidades gerenciadas fornecem uma identidade para seu aplicativo de função 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 dá acesso total a todas as operações do Lambda, incluindo a criação, atualização e exclusão de funções.

- AWSLambda_ReadOnlyAccess dá acesso somente leitura para visualizar as funções do Lambda e suas configurações.

- Políticas personalizadas do IAM.		 Funções integradas baseadas em recursos

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

- A função de Colaborador pode criar e excluir aplicativos de função, definir configurações e implantar código. Não pode gerir 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 de host padrão global)

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

Ligação em rede

AWS Lambda Funções do Azure
Todas as funções do Lambda são executadas com segurança dentro de uma nuvem virtual privada (VPC) gerenciada pelo sistema. Você também pode configurar sua função do Lambda para acessar recursos em uma VPC personalizada. Os aplicativos de função 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ção 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 monitorização

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

O Application Insights coleta dados de telemetria, como taxas de solicitação, tempos de resposta e taxas de falha. Ele visualiza relacionamentos de componentes de aplicativos, monitora o desempenho em tempo real, registra diagnósticos detalhados e permite o rastreamento de métricas personalizadas. Esses recursos ajudam a manter o desempenho, a disponibilidade e a confiabilidade do Azure Functions, ao mesmo tempo em que habilitam painéis personalizados, alertas e respostas automatizadas.
O AWS Lambda gera dados de telemetria a partir de suas invocações de função e pode exportar esses dados usando a semântica OpenTelemetria. Você pode configurar as suas funções Lambda para enviar estas informações de telemetria para qualquer ponto de extremidade 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 suportam 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 ponto de extremidade compatível usando OpenTelemetry. O OpenTelemetry fornece 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ção na configuração do host e em seu projeto de código para otimizar a exportação de dados do seu código de função. Para obter mais informações, consulte Usar OpenTelemetry com o Azure Functions.

Dimensionamento e simultaneidade

AWS Lambda Funções do Azure
A AWS usa um modelo de escalabilidade sob demanda. Dimensione automaticamente a operação da sua função em resposta à demanda. A simultaneidade, ou o número de solicitações tratadas 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 definição de concorrência para o valor desejado.
A concorrência é sempre 1. A concorrência é configurável (>1).
Suporta escalonamento até 0. Suporta escalonamento até 0.

Proteção contra arranque a frio

AWS Lambda Funções do Azure
A simultaneidade provisionada reduz a latência e garante o desempenho previsível da função pré-inicializando um número solicitado de instâncias de função. A simultaneidade provisionada adequa-se a aplicativos sensíveis à latência e tem um preço separado da simultaneidade padrão. Os aplicativos de função permitem que você configure a simultaneidade para cada instância, o que impulsiona sua escala. Vários trabalhos podem ser executados em paralelo na mesma instância da aplicação, e os trabalhos subsequentes não sofrem o tempo inicial de arranque a frio. Os aplicativos de função também têm instâncias sempre prontas . Os clientes podem especificar várias instâncias pré-aquecidas para eliminar a latência de arranque a frio e garantir um desempenho consistente. As aplicações de funções também escalam para mais instâncias com base na procura, mantendo as instâncias sempre disponíveis.
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 AWS Lambda é 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 AWS Lambda é 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ção separados e defina o limite máximo de expansão para cada aplicativo. O Azure Functions expande dinamicamente ou adiciona mais instâncias e dimensiona ou remove instâncias dentro do limite de expansão definido. Por padrão, os aplicativos executados em um plano Flex Consumption 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 maior valor máximo de contagem de instâncias suportado é 1.000. As cotas de memória de assinatura regional também podem limitar a quantidade de funções que os aplicativos podem expandir, 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 o GB/s para cada instância (com uma simultaneidade fixa de 1)

- Incrementos de 1 ms

- Nível livre de 400.000 Gbps		 - Pagamentos baseados no uso para o total de invocações e para os gigabytes por segundo (GB/s) de cada instância (com configurações de invocações simultâneas)

- Incrementos de 100 ms

- Nível livre de 100.000 Gbps

- Custos baseados no consumo

Armazenamento de código-fonte

AWS Lambda Funções do Azure
O AWS Lambda gerencia o armazenamento do código da sua 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 Blob fornecido pelo cliente para manter o pacote de implantação que contém o código do seu 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

Funcionalidade do AWS Lambda Funcionalidade Azure Functions
- SAM CLI

- LocalStack		 - Ferramentas principais do Azure Functions

- Código do Visual Studio

- Visual Studio

- Espaços de código GitHub

- VSCode.dev

- Maven

- Codifique e teste o Azure Functions localmente

Implantação

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

- Imagem de container		 Arquivo ZIP (Para implementação de imagem de contentor, use o SKU dedicado ou premium.)
Tamanho do ficheiro ZIP (consola) 50 MB no máximo 500 MB no máximo para implantação ZIP
Tamanho do ficheiro ZIP (CLI/SDD) 250 MB no máximo para implantação ZIP, 500 MB no máximo para ficheiro descompactado 500 MB no máximo para implantação ZIP
Tamanho da imagem do contêiner Máximo de 10 GB Suporte a contêineres com armazenamento flexível via Azure
Manuseamento de grandes artefactos Use imagens de contêiner para implantações maiores. Anexe compartilhamentos de Armazenamento de Blob ou Arquivos do Azure para acessar arquivos grandes do aplicativo.
Agrupamento de dependências comuns em funções Camadas Implantação . Zip, sob demanda do armazenamento, ou contêineres (ACA, dedicado, apenas 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 sua função usando um número de versão ou um nome de alias. Os qualificadores permitem o gerenciamento de versões e estratégias de implantação gradual. Use sistemas de integração contínua e entrega contínua para implantações azul-verde.

Tempo limite e limites de memória

Característica Limites do AWS Lambda 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 à execução de uma função é de 60 minutos durante o scale-in e 10 minutos durante as atualizações da plataforma. Para obter mais informações, consulte Duração do tempo limite da aplicação funcional.
Memória configurável 128 MB a 10.240 MB, em incrementos de 64 MB O Functions suporta tamanhos de instância de 2 GB e 4 GB . Cada região de uma determinada subscrição tem um limite de memória de 512.000 MB para todas as instâncias de aplicações, que pode aumentar ligando para o suporte. O uso total de memória de todas as instâncias em todas as aplicações de funções numa região deve permanecer dentro deste limite de cota.

Embora 2 GB e 4 GB sejam as opções de tamanho de 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 equilibrar a alocação de memória e as configurações de simultaneidade, você pode gerenciar efetivamente os recursos alocados para seus aplicativos de função e garantir um desempenho eficiente e controle de custos. Para obter mais informações, consulte Cotas de memória de assinatura regional.

Gestão de segredos

AWS Lambda Funções do Azure
O AWS Secrets Manager permite armazenar, gerenciar e recuperar segredos, como credenciais de banco de dados, chaves de API e outras informações confidenciais. As funções do Lambda podem recuperar segredos usando o AWS SDK. 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 segredos são necessários, como para sistemas herdados ou de parceiros, o Azure Key Vault fornece uma solução segura para armazenar e gerenciar segredos, chaves e certificados.
Parameter Store do AWS Systems Manager é um serviço que guarda dados de configuração e segredos. Os parâmetros podem ser criptografados usando o AWS KMS e recuperados por funções do Lambda usando o AWS SDK.
As funções do Lambda podem armazenar definições de configuração em variáveis de ambiente. Os dados confidenciais podem ser criptografados com uma chave KMS para acesso seguro.		 O Azure Functions usa configurações de 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 Aplicativo do Azure fornece recursos robustos para gerenciar várias configurações. Ele permite a sinalização de recursos e suporta atualizações dinâmicas entre serviços.

Gestão do Estado

AWS Lambda Funções do Azure
O AWS Lambda lida com o gerenciamento de estado simples usando serviços como Amazon S3 para armazenamento de objetos, DynamoDB para armazenamento de estado NoSQL rápido e escalável e SQS para tratamento de filas de mensagens. Esses serviços garantem a persistência e a consistência dos dados nas execuções de funções do 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 Blob, Armazenamento de Filas e Armazenamento de Tabelas. Ele permite funções para ler e gravar 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
Não há orquestração nativa de estados. Use o AWS Step Functions para fluxos de trabalho. As funções duráveis ajudam com a gestão de estado complexo, fornecendo orquestração de fluxo de trabalho durável e entidades com estado. Ele permite operações de longa duração, pontos de verificação automáticos e persistência de estado confiável. Esses recursos permitem a criação de fluxos de trabalho complexos para garantir tolerância a falhas e escalabilidade para aplicativos com monitoração de estado.

Outras diferenças e considerações

Característica AWS Lambda Funções do Azure
Funções de agrupamento Cada função do AWS Lambda é uma entidade independente. Um aplicativo de função serve como um contêiner para várias funções. Ele fornece um contexto de execução compartilhado e 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. O Functions também usa uma estratégia de dimensionamento por função, onde cada função é dimensionada independentemente, exceto para gatilhos HTTP, Armazenamento de Blob e Funções Duráveis. Essas funções desencadeadas são dimensionadas em seus próprios grupos.
Domínios personalizados Ativado via API Gateway Você pode configurar domínios personalizados diretamente em um aplicativo de função ou no Gerenciamento de API do Azure.
Suporte de contêiner personalizado Suporta contêineres personalizados por meio do Lambda Container Image O Azure Functions dá suporte a contêineres personalizados que são 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 médio porte do seu inventário total. Essas cargas de trabalho servem como base para a sua migração de prova de conceito. Você pode testar o processo e identificar possíveis desafios sem correr o risco de grandes interrupções em suas operações.

  2. Teste iterativamente e recolha feedback.

    Use a prova de conceito para coletar feedback, identificar lacunas e ajustar o processo antes de dimensionar para cargas de trabalho maiores. Essa abordagem iterativa garante que, no momento em que você passar para a migração em grande escala, você abordará os desafios potenciais e refinará o processo.

Criar os recursos de migração

Esta etapa é uma fase transitória de desenvolvimento. Durante essa fase, você cria código-fonte, modelos de infraestrutura como código (IaC) 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.

Adapte o código de função, os arquivos de configuração e a infraestrutura como arquivos de código

Para atualizar o código para os requisitos de tempo de execução do Azure Functions:

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

Leitura do Amazon S3 versus armazenamento de Blob do Azure

Código do AWS Lambda (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()}`);
});

Gravação no Amazon Simple Queue Service (SQS) versus Armazenamento de Filas do Azure

Código do AWS Lambda (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}`);
});

Escrever para o DynamoDB versus o Azure Cosmos DB

Código do AWS Lambda (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 timer do Azure

Código do AWS Lambda (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()}); });

Amazon Simple Notification Service (SNS) versus um gatilho de grade de eventos do Azure

Código do AWS Lambda (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 vs. um acionador do Azure Event Hubs

Código do AWS Lambda (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 do AWS Lambda e o código do Azure Functions:

Ajustar definições de configuração

Certifique-se de que as configurações de tempo limite e memória da sua função 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ção. Para obter mais informações, consulte Configurar seu aplicativo de função e conta de armazenamento com 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 dá ao seu aplicativo de função acesso a recursos em sua rede virtual. Após a integração, seu aplicativo roteia o tráfego de saída através da rede virtual. Em seguida, seu aplicativo pode acessar pontos de extremidade ou recursos privados usando regras que permitem apenas o tráfego 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 seu aplicativo, a menos que você configure um gateway NAT.

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

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 criar o código do projeto e compactá-lo em um pacote de aplicativo, implante-o em um contêiner de Armazenamento de Blob. Quando ele é iniciado, seu aplicativo recebe o pacote e executa seu código de função a partir dele. Por padrão, a mesma conta de armazenamento que armazena metadados internos do host, como AzureWebJobsStorage, também serve como contêiner de implantação. No entanto, você pode usar uma conta de armazenamento alternativa ou escolher seu método de autenticação preferido definindo as configurações de implantação do seu aplicativo. Para obter mais informações, consulte Detalhes da tecnologia de implantação e Definir 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 Azure Functions, contas de armazenamento e componentes de rede em seus arquivos IaC.

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

Utilizar ferramentas para refatorar código

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 Agente em GitHub Copilot no Visual Studio 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 primeiro dia (Dia 0)

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

  • Validar funcionalidade

    • Codifique e teste o Azure Functions localmente.

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

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

    • Para outros gatilhos, como temporizadores ou filas, certifique-se de que os gatilhos sejam acionados corretamente e que as funções sejam 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 AWS Lambda.

    • 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 do seu aplicativo de função. Essa ferramenta fornece um conjunto de recursos de diagnóstico que podem ajudá-lo a identificar e resolver rapidamente problemas comuns, como falhas de aplicativos, degradação de desempenho e problemas de configuração. Siga as etapas de solução de problemas guiadas e as recomendações que a ferramenta fornece para resolver os problemas identificados.

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 ou o desenvolvimento adicional da carga de trabalho.

Implante e teste funções para validar seu desempenho e 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 a partir da linha de comando usando as Ferramentas Principais do Azure Functions ou a CLI do Azure. O Azure DevOps e as Ações do GitHub também usam One Deploy.

Explore exemplos de cenários de migração

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

Se preferir usar o Terraform, use MigrationGetStarted-Terraform.

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ção 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ção. 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 informações sobre o desempenho e o comportamento do seu aplicativo funcional.

  • Configure alertas. Configure alertas no Application Insights para notificá-lo de problemas críticos, degradação de desempenho ou eventos específicos. Estes alertas ajudam-no a monitorizar proativamente e a responder rapidamente a problemas.

Otimize o custo e o desempenho

  • Dimensionamento e otimização de desempenho:

    • Use os recursos de dimensionamento automático para lidar com cargas de trabalho variáveis de forma eficiente.

    • 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 repetido e a latência para dados acessados com frequência.

  • Gestão de custos:

    • Use as ferramentas do Microsoft Cost Management para monitorar e analisar os custos do Azure Functions.

    • Configure alertas de orçamento e custos para gerenciar e prever despesas de forma eficaz.