Partager via

Migrer des charges de travail AWS Lambda vers Azure Functions

La migration d’une charge de travail serverless qui utilise Amazon Web Services (AWS) Lambda vers Azure Functions nécessite une planification et une implémentation minutieuses. Cet article fournit des conseils essentiels pour vous aider à :

  • Effectuez un processus de découverte sur votre charge de travail existante.
  • Découvrez comment effectuer des activités de migration clés telles que la planification de la prémigration et l’évaluation de la charge de travail.
  • Évaluez et optimisez une charge de travail migrée.

Étendue

Cet article décrit la migration d’une instance AWS Lambda vers Azure Functions.

Cet article ne traite pas :

  • Migration vers votre propre solution d’hébergement de conteneur, par exemple via Azure Container Apps.
  • Hébergement de conteneurs AWS Lambda dans Azure.
  • Approches fondamentales de l’adoption d’Azure par votre organisation, telles que les zones d’atterrissage Azure ou d’autres rubriques traitées dans la méthodologie de migration du Cloud Adoption Framework.

Comparer les fonctionnalités

Cet article mappe les fonctionnalités AWS Lambda aux équivalents Azure Functions pour garantir la compatibilité.

Important

Vous pouvez choisir d’inclure l’optimisation dans votre plan de migration, mais Microsoft recommande un processus en deux étapes. Migrez d’abord les fonctionnalités « like-to-like », puis évaluez les opportunités d’optimisation sur Azure.

Les efforts d’optimisation doivent être continus et exécutés via les processus de contrôle des modifications de votre équipe de charge de travail. Une migration qui ajoute davantage de fonctionnalités pendant une migration entraîne des risques et étend inutilement le processus.

Perspective de la charge de travail

Cet article se concentre sur la migration d’une charge de travail AWS Lambda vers Azure Functions et les dépendances courantes pour les charges de travail serverless. Ce processus peut impliquer plusieurs services, car les charges de travail comprennent de nombreuses ressources et processus pour gérer ces ressources. Pour avoir une stratégie complète, vous devez combiner les recommandations présentées dans cet article avec un plan plus large qui inclut les autres composants et processus de votre charge de travail.

Effectuer un processus de découverte sur votre charge de travail existante

La première étape consiste à effectuer un processus de découverte détaillé pour évaluer votre charge de travail AWS Lambda existante. L’objectif est de comprendre les fonctionnalités et services AWS sur lesquels repose votre charge de travail. Compilez un inventaire complet de vos fonctions AWS Lambda à l’aide d’outils AWS tels que les kits SDK spécifiques au service, les API, CloudTrail et AWS CLI pour évaluer la charge de travail sur AWS. Vous devez comprendre les aspects clés suivants de votre inventaire AWS Lambda :

  • Cas d’utilisation
  • Paramètres
  • Configurations de sécurité et de mise en réseau
  • Systèmes d'outillage, de surveillance, de journalisation et d'observabilité
  • Dépendances
  • Objectifs de fiabilité et état de fiabilité actuel
  • Coût total de possession
  • Objectifs de performances et performances actuelles

Effectuer une planification de prémigration

Avant de commencer à migrer votre charge de travail, vous devez mapper les fonctionnalités AWS Lambda à Azure Functions pour garantir la compatibilité et développer un plan de migration. Vous pouvez ensuite sélectionner des charges de travail clés pour une preuve de concept.

Vous devez également mapper les services AWS dont Lambda dépend des dépendances équivalentes dans Azure.

Mapper les fonctionnalités AWS Lambda à Azure Functions

Les tableaux suivants comparent les concepts, ressources et propriétés AWS Lambda à leurs équivalents correspondants sur Azure Functions, en particulier le plan d’hébergement Flex Consumption.

Langues prises en charge

Langage de programmation Versions prises en charge par AWS Lambda Versions prises en charge par 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 Non prise en charge 7.4
.NET .NET 8 .NET 8, .NET 9, .NET Framework 4.8.1
Ruby 3.2, 3.3 Gestionnaires personnalisés
Allez Runtime du système d’exploitation uniquement Gestionnaires personnalisés
Rust Runtime du système d’exploitation uniquement Gestionnaires personnalisés

Modèle de programmation

Caractéristique AWS Lambda Les fonctions Azure
Déclencheurs S’intègre à d’autres services AWS via des sources d’événements. Fournit des méthodes automatiques et programmatiques pour lier des fonctions Lambda avec des sources d’événements. Déclenche une fonction basée sur des événements spécifiques, tels que des mises à jour dans une base de données ou un nouveau message dans une file d’attente. Par exemple, un déclencheur Azure Cosmos DB permet aux fonctions de répondre automatiquement aux insertions et mises à jour dans un conteneur Azure Cosmos DB. Cette action permet le traitement en temps réel des modifications de données.

Functions s’intègre également à Azure Event Grid, ce qui permet de traiter des événements à partir de services Azure, tels que Stockage Azure et Azure Media Services et sources d’événements externes. Event Grid sert de service de routage d’événements extensible centralisé qui complète les déclencheurs Functions et permet une haute scalabilité et une couverture étendue des sources d’événements.
Liaisons N’a pas de liaisons. Utilise les kits SDK AWS dans les fonctions Lambda pour gérer manuellement les interactions avec d’autres services AWS. Les liaisons, configurées comme entrées ou comme sorties, activent les connexions déclaratives aux services, ce qui réduit au minimum la nécessité d’un code explicite du Kit de développement logiciel (SDK). Par exemple, vous pouvez configurer des liaisons pour lire à partir du stockage Blob, écrire dans Azure Cosmos DB ou envoyer des e-mails via SendGrid sans gérer manuellement les intégrations.

Déclencheurs et liaisons d’événements

Déclencheur ou service AWS Lambda Déclencheur Azure Functions Descriptif
Passerelle d’API : requêtes HTTP Déclencheur HTTP Ces déclencheurs vous permettent de gérer directement les requêtes HTTP.
Service de file d’attente simple (SQS) Déclencheur de file d'attente de stockage Azure ou déclencheur de bus de service Azure Ces déclencheurs peuvent traiter les messages dans les files d’attente.
Service de notification simple (SNS) Déclencheur Event Grid ou déclencheur Service Bus Ces déclencheurs activent le traitement des notifications.
Kinesis (flux de données) Déclencheur Event Hubs Ces déclencheurs consomment des flux de données.
DynamoDB (modifications de table) Déclencheur de flux de modification Azure Cosmos DB Ces déclencheurs sont à l’écoute des modifications apportées aux tables.
Événements CloudWatch ou Planificateur EventBridge Déclencheur du minuteur Ces déclencheurs gèrent les fonctions planifiées ou basées sur le temps.
S3 (événements d’objets) Déclencheur de stockage d’objets blob Ces déclencheurs réagissent aux événements dans le stockage d’objets blob.
Amazon Relational Database Service (RDS) Déclencheur Azure SQL Ces déclencheurs réagissent aux modifications de base de données.
Diffusion en continu managée pour Apache Kafka (MSK) Déclencheur Apache Kafka Ces déclencheurs réagissent aux messages de rubrique Kafka.
Amazon ElastiCache Déclencheur Redis Azure Ces déclencheurs réagissent aux messages dans Redis.
Amazon MQ Déclencheur RabbitMQ Ces déclencheurs réagissent aux messages dans RabbitMQ.

Autorisations

AWS Lambda Les fonctions Azure
Le rôle d’exécution Lambda accorde des autorisations de fonctions Lambda pour interagir avec d’autres services AWS. Chaque fonction Lambda a un rôle de gestion des identités et des accès (IAM) associé qui détermine ses autorisations pendant son exécution. Les identités managées fournissent une identité pour votre application de fonction qui lui permet de s’authentifier auprès d’autres services Azure sans stocker d’informations d’identification dans le code. Le contrôle d’accès en fonction du rôle attribue les rôles appropriés à l’identité managée dans Microsoft Entra ID pour accorder l’accès aux ressources dont elle a besoin.
Instructions de stratégie basées sur les ressources :

- AWSLambda_FullAccess donne un accès complet à toutes les opérations Lambda, notamment la création, la mise à jour et la suppression de fonctions.

- AWSLambda_ReadOnlyAccess permet d’accéder en lecture seule aux fonctions Lambda et à leurs configurations.

- Stratégies IAM personnalisées.		 Rôles intégrés basés sur des ressources :

- Le rôle Propriétaire donne un accès complet, y compris la gestion des autorisations d’accès.

- Le rôle Contributeur peut créer et supprimer des applications de fonction, configurer des paramètres et déployer du code. Il ne peut pas gérer l’accès.

- Le rôle Lecteur de surveillance peut accorder un accès en lecture seule aux données et paramètres de surveillance. Il peut également allouer des rôles personnalisés.

URL de la fonction

AWS Lambda Les fonctions Azure
https://<url-id>.lambda-url.<region>.on.aws - <appname>.azurewebsites.net (nom d’hôte par défaut global d’origine)

- <appname>-<randomhash>.<Region>.azurewebsites.net (nouveau nom d’hôte par défaut unique)

Réseautage

AWS Lambda Les fonctions Azure
Toutes les fonctions Lambda s’exécutent en toute sécurité à l’intérieur d’un cloud privé virtuel géré par le système par défaut (VPC). Vous pouvez également configurer votre fonction Lambda pour accéder aux ressources dans un VPC personnalisé. Les applications de fonction peuvent être sécurisées par le réseau et accéder à d’autres services à l’intérieur du réseau. L’accès réseau entrant ne peut être limité qu’à une liste de pare-feu d’adresses IP et à un réseau virtuel spécifique via des points de terminaison de service ou des points de terminaison privés. L’accès réseau sortant est activé via la fonctionnalité d’intégration de réseau virtuel. L’application de fonction peut avoir tout son trafic limité au sous-réseau d’un réseau virtuel et peut également accéder à d’autres services à l’intérieur de ce réseau virtuel.

Observabilité et supervision

AWS Lambda Les fonctions Azure
Amazon CloudWatch permet de surveiller et d’observer en collectant et en effectuant le suivi des métriques, en agrégeant et en analysant les journaux, en définissant des alarmes, en créant des tableaux de bord personnalisés et en implémentant des réponses automatisées aux modifications des performances des ressources et des métriques. Azure Monitor fournit une surveillance et une observabilité complètes pour Azure Functions, en particulier par le biais de sa fonctionnalité Application Insights.

Application Insights collecte des données de télémétrie telles que les taux de demande, les temps de réponse et les taux d’échec. Il visualise les relations des composants d’application, surveille les performances en temps réel, enregistre des diagnostics détaillés et permet le suivi des métriques personnalisé. Ces fonctionnalités permettent de maintenir les performances, la disponibilité et la fiabilité d’Azure Functions, tout en activant des tableaux de bord personnalisés, des alertes et des réponses automatisées.
AWS Lambda génère des données de télémétrie à partir de vos appels de fonction et peut exporter ces données à l’aide de la sémantique OpenTelemetry. Vous pouvez configurer vos fonctions Lambda pour envoyer ces données de télémétrie à n’importe quel point de terminaison conforme à OpenTelemetry. Cette action permet la corrélation des traces et des journaux, des données de télémétrie basées sur des normes cohérentes, et l’intégration à d’autres outils d’observabilité qui prennent en charge OpenTelemetry. Configurez votre application functions pour exporter les données de journal et de trace dans un format OpenTelemetry. Vous pouvez exporter des données de télémétrie vers n’importe quel point de terminaison conforme à l’aide d’OpenTelemetry. OpenTelemetry offre des avantages comme la corrélation des suivis et des journaux, des données de télémétrie cohérentes et standardisées, et l’intégration avec d’autres fournisseurs. Vous pouvez activer OpenTelemetry au niveau de l’application de fonction dans la configuration de l’hôte et dans votre projet de code pour optimiser l’exportation des données à partir de votre code de fonction. Pour plus d’informations, consultez Utiliser OpenTelemetry avec Azure Functions.

Mise à l’échelle et accès concurrentiel

AWS Lambda Les fonctions Azure
AWS utilise un modèle de mise à l’échelle à la demande. Adaptez automatiquement le fonctionnement de votre fonction en réponse à la demande. La concurrence, ou le nombre de requêtes gérées par une instance, est toujours 1. Les instances sont ajoutées et supprimées dynamiquement en fonction du nombre d’événements entrants et de la concurrence configurée pour chaque instance. Vous pouvez configurer le paramètre d’accès concurrentiel sur la valeur souhaitée.
La concurrence est toujours égale à 1. La concurrence est configurable (>1).
Prend en charge la mise à l’échelle à 0. Prend en charge la mise à l’échelle à 0.

Protection de démarrage à froid

AWS Lambda Les fonctions Azure
La concurrence provisionnée réduit la latence et garantit les performances prévisibles des fonctions en préinitialisant un nombre demandé d’instances de fonction. La concurrence provisionnée convient aux applications sensibles à la latence et est facturée séparément de la concurrence standard. Les applications de fonction vous permettent de configurer la concurrence pour chaque instance, ce qui influence sa mise à l’échelle. Plusieurs travaux peuvent s’exécuter en parallèle dans la même instance de l’application, et les travaux suivants dans l’instance n’entraînent pas le démarrage à froid initial. Les applications de fonction disposent également d’instances toujours prêtes . Les clients peuvent spécifier un certain nombre d'instances préchauffées pour éliminer le délai de démarrage à froid et garantir des performances cohérentes. Les applications de fonction effectuent également un scale-out vers davantage d’instances en fonction de la demande, tout en conservant les instances toujours prêtes.
La concurrence réservée spécifie le nombre maximal d’instances simultanées qu’une fonction peut avoir. Cette limite garantit qu’une partie du quota d’accès concurrentiel de votre compte est réservée exclusivement à cette fonction. AWS Lambda effectue un scale-out dynamique pour gérer les requêtes entrantes même lorsque la concurrence réservée est définie, tant que les requêtes ne dépassent pas la limite de concurrence réservée spécifiée. La limite inférieure pour la concurrence réservée dans AWS Lambda est 1. La limite supérieure pour la concurrence réservée dans AWS Lambda est déterminée par le quota d’accès concurrentiel régional du compte. Par défaut, cette limite est de 1 000 opérations simultanées pour chaque région. Azure Functions n’a pas de fonctionnalité équivalente à la concurrence réservée. Pour obtenir des fonctionnalités similaires, isolez des fonctions spécifiques dans des applications de fonction distinctes et définissez la limite maximale de scale-out pour chaque application. Azure Functions effectue une mise à l'échelle dynamique, en ajoutant ou en supprimant des instances, tout en restant dans la limite de mise à l'échelle définie. Par défaut, les applications qui s’exécutent dans un plan Flex Consumption commencent par une limite configurable de 100 instances globales. La valeur de nombre d’instances maximale la plus faible est 40, et la valeur maximale de nombre d’instances la plus élevée prise en charge est de 1 000. Les quotas de mémoire d’abonnement régionaux peuvent également limiter la quantité d’applications de fonction pouvant être mises à l’échelle, mais vous pouvez augmenter ce quota en appelant le support.

Tarification

AWS Lambda Les fonctions Azure
- Paiement à l’utilisation pour le nombre total d’appels et la quantité de Go/s pour chaque instance (avec une concurrence fixe de 1)

- Incréments de 1 ms

- Niveau gratuit de 400 000 Gbits/s		 - Payer par utilisation pour le nombre total d’appels et pour les Go/s de chaque instance (avec appels simultanés configurables)

- Incréments de 100 ms

- Niveau gratuit de 100 000 Gbits/s

- Coûts basés sur la consommation

Stockage du code source

AWS Lambda Les fonctions Azure
AWS Lambda gère le stockage de votre code de fonction dans son propre système de stockage managé. Vous n’avez pas besoin de fournir davantage de stockage. Functions nécessite un conteneur de stockage Blob fourni par le client pour gérer le package de déploiement qui contient le code de votre application. Vous pouvez configurer les paramètres pour utiliser le même compte de stockage ou un autre compte de stockage pour les déploiements et gérer les méthodes d’authentification pour accéder au conteneur.

Développement local

Fonctionnalité AWS Lambda Fonctionnalité Azure Functions
- Interface de ligne de commande SAM

- LocalStack		 - Azure Functions [Outils principaux]

- Visual Studio Code

- Visual Studio

- GitHub Codespaces

- VSCode.dev

-Maven

- Coder et tester Azure Functions localement

Déploiement

Caractéristique AWS Lambda Les fonctions Azure
Package de déploiement - Fichier ZIP

- Image conteneur		 Fichier ZIP (pour le déploiement d’image conteneur, utilisez la référence SKU dédiée ou Premium.)
Taille du fichier ZIP (console) Maximum de 50 Mo 500 Mo maximum pour le déploiement ZIP
Taille de fichier ZIP (CLI/SDK) 250 Mo maximum pour le déploiement ZIP, 500 Mo maximum pour le fichier décompressé 500 Mo maximum pour le déploiement ZIP
Taille de l’image de conteneur 10 Go au maximum Prise en charge des conteneurs avec stockage flexible via Azure
Gestion des artefacts volumineux Utilisez des images conteneur pour des déploiements plus volumineux. Connectez des partages de stockage Blob ou Azure Files pour accéder aux fichiers volumineux depuis l'application.
Empaquetage de dépendances communes aux fonctions Calques Fichier .zip de déploiement, à la demande à partir du stockage, ou conteneurs (ACA, dédiés, références SKU EP uniquement)
Déploiement bleu-vert ou versionnage de fonction Utilisez des qualificateurs de fonction pour référencer un état spécifique de votre fonction à l’aide d’un numéro de version ou d’un nom d’alias. Les qualificateurs permettent la gestion des versions et les stratégies de déploiement progressif. Utilisez des systèmes d’intégration continue et de livraison continue pour les déploiements bleu-vert.

Limites de délai d’expiration et de mémoire

Caractéristique Limites AWS Lambda Limites d’Azure Functions
Délai d'exécution 900 secondes (15 minutes) Le délai d’attente par défaut est de 30 minutes. Le délai maximal d’attente n’est pas lié. Toutefois, la période de grâce donnée à une exécution de fonction est de 60 minutes pendant la mise à l’échelle et 10 minutes pendant les mises à jour de la plateforme. Pour plus d’informations, consultez Durée de délai d’expiration des applications de fonction.
Mémoire configurable 128 Mo à 10 240 Mo, par incréments de 64 Mo Functions prend en charge les tailles d’instance de 2 Go et de 4 Go . Chaque région d’un abonnement donné a une limite de mémoire de 512 000 Mo pour toutes les instances d’applications, que vous pouvez augmenter en appelant la prise en charge. L’utilisation totale de la mémoire de toutes les instances dans toutes les applications de fonction d’une région doit rester dans ce quota.

Bien que 2 Go et 4 Go soient les options de taille d’instance, la concurrence pour chaque instance peut être supérieure à 1. Par conséquent, une seule instance peut gérer plusieurs exécutions simultanées, en fonction de la configuration. La configuration appropriée de l’accès concurrentiel peut vous aider à optimiser l’utilisation des ressources et à gérer les performances. En équilibrant les paramètres d’allocation de mémoire et d’accès concurrentiel, vous pouvez gérer efficacement les ressources allouées à vos applications de fonction et garantir un contrôle efficace des performances et des coûts. Pour plus d’informations, consultez Quotas de mémoire d’abonnement régional.

Gestion des secrets

AWS Lambda Les fonctions Azure
AWS Secrets Manager vous permet de stocker, gérer et récupérer des secrets tels que des informations d’identification de base de données, des clés API et d’autres informations sensibles. Les fonctions lambda peuvent récupérer des secrets à l’aide du Kit de développement logiciel (SDK) AWS. Nous vous recommandons d’utiliser des approches sans secret comme les identités managées pour permettre un accès sécurisé aux ressources Azure sans coder en dur les informations d’identification. Lorsque des secrets sont requis, comme pour les systèmes partenaires ou hérités, Azure Key Vault fournit une solution sécurisée pour stocker et gérer les secrets, les clés et les certificats.
AWS Systems Manager Parameter Store est un service qui stocke les données de configuration et les secrets. Les paramètres peuvent être chiffrés à l’aide d’AWS KMS et récupérés par les fonctions Lambda à l’aide du Kit de développement logiciel (SDK) AWS.
Les fonctions lambda peuvent stocker les paramètres de configuration dans les variables d’environnement. Les données sensibles peuvent être chiffrées avec une clé KMS pour un accès sécurisé.		 Azure Functions utilise les paramètres d’application pour stocker les données de configuration. Ces paramètres correspondent directement aux variables d’environnement pour faciliter l’utilisation dans la fonction. Ces paramètres peuvent être chiffrés et stockés en toute sécurité dans la configuration d’Azure App Service.
Pour les scénarios plus avancés, Azure App Configuration fournit des fonctionnalités robustes pour gérer plusieurs configurations. Il active l’indicateur des fonctionnalités et prend en charge les mises à jour dynamiques entre les services.

Gestion de l'état

AWS Lambda Les fonctions Azure
AWS Lambda gère une gestion d’état simple à l’aide de services tels qu’Amazon S3 pour le stockage d’objets, DynamoDB pour un stockage d’état NoSQL rapide et évolutif et SQS pour la gestion des files d’attente de messages. Ces services garantissent la persistance et la cohérence des données entre les exécutions de fonctions lambda. Azure Functions utilise AzureWebJobsStorage pour gérer l’état en activant des liaisons et des déclencheurs avec des services stockage Azure tels que Stockage Blob, Stockage File d’attente et Stockage Table. Elle permet aux fonctions de lire et d'écrire facilement l'état. Pour une gestion d’état plus complexe, Durable Functions fournit des fonctionnalités avancées d’orchestration de flux de travail et de persistance d’état à l’aide du stockage Azure.

Orchestration avec état

AWS Lambda Les fonctions Azure
Aucune orchestration d’état intégrée. Utilisez AWS Step Functions pour les flux de travail. Durable Functions aide à la gestion des états complexes en fournissant une orchestration de workflows durables et des entités persistantes. Il permet des opérations longues, des points de contrôle automatiques et une persistance d’état fiable. Ces fonctionnalités permettent de créer des workflows complexes pour garantir la tolérance aux pannes et la scalabilité des applications avec état.

Autres différences et considérations

Caractéristique AWS Lambda Les fonctions Azure
Fonctions de regroupement Chaque fonction AWS Lambda est une entité indépendante. Une application de fonction sert de conteneur pour plusieurs fonctions. Il fournit un contexte d’exécution partagé et une configuration pour les fonctions qu’il contient. Le traitement de plusieurs fonctions en tant qu’entité unique simplifie le déploiement et la gestion. Functions utilise également une stratégie de mise à l’échelle par fonction, où chaque fonction est mise à l’échelle indépendamment, à l’exception des déclencheurs HTTP, Stockage Blob et Fonctions durables. Ces fonctions déclenchées effectuent un scale-in de leur propre groupe.
Domaines personnalisés Activé via la passerelle d’API Vous pouvez configurer des domaines personnalisés directement sur une application de fonction ou sur Gestion des API Azure.
Prise en charge des conteneurs personnalisés Prend en charge les conteneurs personnalisés via Lambda Container Image Azure Functions prend en charge les conteneurs personnalisés qui s’exécutent dans un environnement Container Apps.

Créer un plan de migration

  1. Sélectionnez les charges de travail clés pour une preuve de concept.

    Commencez par sélectionner une à deux charges de travail de taille moyenne et non critique dans votre inventaire total. Ces charges de travail servent de base pour votre projet pilote de migration. Vous pouvez tester le processus et identifier les défis potentiels sans risquer d’interruption majeure de vos opérations.

  2. Testez itérativement et recueillez des commentaires.

    Utilisez la preuve de concept pour recueillir des commentaires, identifier les lacunes et affiner le processus avant d’effectuer une mise à l’échelle vers des charges de travail plus volumineuses. Cette approche itérative garantit qu’au moment où vous passez à la migration à grande échelle, vous résolvez les défis potentiels et affinez le processus.

Générer les ressources de migration

Cette étape est une phase de développement transitionnelle. Au cours de cette phase, vous créez du code source, des modèles d’infrastructure en tant que modèles iaC et des pipelines de déploiement pour représenter la charge de travail dans Azure. Vous devez adapter le code de fonction pour la compatibilité et les bonnes pratiques avant de pouvoir effectuer la migration.

Adapter le code de fonction, les fichiers de configuration et l’infrastructure en tant que fichiers de code

Pour mettre à jour le code pour les exigences du runtime Azure Functions :

Les extraits de code suivants sont des exemples de code commun du SDK. Le code AWS Lambda est mappé aux déclencheurs, liaisons ou extraits de code du Kit de développement logiciel (SDK) correspondants dans Azure Functions.

Lecture à partir d’Amazon S3 comparée au Stockage Blob Azure

Code Lambda d'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());
};

Code Azure Functions (déclencheur)

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

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

Écriture dans Amazon Simple Queue Service (SQS) comparée au Stockage File d’attente Azure

Code Lambda d'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();
};

Code Azure Functions (déclencheur)

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

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

Écriture dans DynamoDB et Azure Cosmos DB

Code Lambda d'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); 
};

Code Azure Functions (déclencheur)

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)}`); 
}); 
});

Événements Amazon CloudWatch par rapport à un déclencheur de minuteur Azure

Code Lambda d'AWS (SDK)

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

Code Azure Functions (déclencheur)

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) par rapport à un déclencheur Azure Event Grid

Code Lambda d'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(); 
};

Code Azure Functions (déclencheur)

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

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

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

});

Amazon Kinesis versus un déclencheur Azure Event Hubs

Code Lambda d'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); 
};

Code Azure Functions (déclencheur)

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}`);  
});  
});

Consultez les référentiels GitHub suivants pour comparer le code AWS Lambda et le code Azure Functions :

Ajuster les paramètres de configuration

Vérifiez que les paramètres de délai d’attente et de mémoire de votre fonction sont compatibles avec Azure Functions. Pour plus d’informations sur les paramètres configurables, consultez host.json référence pour Azure Functions.

Suivez les meilleures pratiques recommandées pour les autorisations, l’accès, la mise en réseau et les configurations de déploiement.

Configurer les autorisations

Suivez les bonnes pratiques lorsque vous configurez des autorisations sur vos applications de fonction. Pour plus d’informations, consultez Configurer votre application de fonction et votre compte de stockage avec une identité managée.

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}'
  }
}

Pour plus d’informations, consultez rbac.bicep.

Configurer l’accès réseau

Azure Functions prend en charge l’intégration de réseau virtuel, ce qui permet à votre application de fonction d’accéder aux ressources de votre réseau virtuel. Après l’intégration, votre application achemine le trafic sortant via le réseau virtuel. Votre application peut ensuite accéder aux points de terminaison privés ou aux ressources à l’aide de règles qui autorisent uniquement le trafic à partir de sous-réseaux spécifiques. Si la destination est une adresse IP en dehors du réseau virtuel, l’adresse IP source est l’une des adresses répertoriées dans les propriétés de votre application, sauf si vous configurez une passerelle NAT.

Lorsque vous activez l’intégration de réseau virtuel pour vos applications de fonction, suivez les meilleures pratiques de TSG pour l’intégration de réseau virtuel pour les applications web et les applications de fonction.

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
  }
}

Pour plus d’informations, consultez VNet.bicep et storage-PrivateEndpoint.bicep.

Configurer les paramètres de déploiement

Les déploiements suivent un chemin unique. Une fois que vous avez généré votre code de projet et le compressez dans un package d’application, déployez-le dans un conteneur de stockage d’objets blob. Au démarrage, votre application obtient le package et exécute votre code de fonction à partir de celui-ci. Par défaut, le même compte de stockage qui stocke les métadonnées d’hôte interne, telles que AzureWebJobsStorage, sert également de conteneur de déploiement. Toutefois, vous pouvez utiliser un autre compte de stockage ou choisir votre méthode d’authentification préférée en configurant les paramètres de déploiement de votre application. Pour plus d’informations, consultez les détails de la technologie de déploiement et configurez les paramètres de déploiement.

Générer des fichiers IaC

  • Utilisez des outils tels que Bicep, des modèles Azure Resource Manager ou Terraform pour créer des fichiers IaC pour déployer des ressources Azure.

  • Définissez des ressources telles qu’Azure Functions, les comptes de stockage et les composants réseau dans vos fichiers IaC.

  • Utilisez ce référentiel d’exemples IaC pour obtenir des exemples qui utilisent des recommandations et des bonnes pratiques Azure Functions.

Utiliser des outils pour la refactorisation

Utilisez des outils tels que GitHub Copilot dans VS Code pour obtenir de l’aide sur la refactorisation du code, la refactorisation manuelle pour des modifications spécifiques ou d’autres aides à la migration.

Remarque

Utilisez le mode Agent dans GitHub Copilot dans VS Code.

Les articles suivants fournissent des exemples spécifiques et des étapes détaillées pour faciliter le processus de migration :

Développer un processus pas à pas pour la migration day-0

Développez des stratégies de basculement et de retour arrière pour votre migration et testez-les soigneusement dans un environnement de préproduction. Nous vous recommandons d’effectuer des tests de bout en bout avant de passer d’AWS Lambda à Azure Functions.

  • Valider les fonctionnalités

    • Codez et testez Azure Functions localement.

    • Testez soigneusement chaque fonction pour vous assurer qu’elle fonctionne comme prévu. Ces tests doivent inclure la vérification des entrées/sorties, des déclencheurs d’événements et des liaisons.

    • Utilisez des outils tels que curl ou des extensions client REST sur VS Code pour envoyer des requêtes HTTP pour les fonctions déclenchées par HTTP.

    • Pour les autres déclencheurs, tels que les minuteurs ou les files d’attente, assurez-vous que les déclencheurs se déclenchent correctement et que les fonctions s’exécutent comme prévu.

  • Valider les performances

    • Effectuez des tests de performances pour comparer le nouveau déploiement d’Azure Functions avec le déploiement AWS Lambda précédent.

    • Surveillez les métriques telles que le temps de réponse, l’heure d’exécution et la consommation des ressources.

    • Utilisez Application Insights pour la supervision, l’analyse des journaux et la résolution des problèmes pendant la phase de test.

  • Résoudre les problèmes à l’aide de la fonctionnalité diagnostiquer et résoudre les problèmes

    Utilisez la fonctionnalité diagnostiquer et résoudre les problèmes dans le portail Azure pour résoudre les problèmes de votre application de fonction. Cet outil fournit un ensemble de fonctionnalités de diagnostic qui peuvent vous aider à identifier et résoudre rapidement les problèmes courants, tels que les incidents d’application, la dégradation des performances et les problèmes de configuration. Suivez les étapes de dépannage guidées et les recommandations fournies par l’outil pour résoudre les problèmes que vous identifiez.

Évaluer l’état final de la charge de travail migrée

Avant de mettre hors service des ressources dans AWS, vous devez être sûr que la plateforme répond aux attentes actuelles en matière de charge de travail et que rien ne bloque la maintenance de la charge de travail ou le développement ultérieur.

Déployez et testez des fonctions pour valider leurs performances et leur exactitude.

Déployer sur Azure

Déployez des charges de travail à l’aide de la fonctionnalité de publication VS Code . Vous pouvez également déployer des charges de travail à partir de la ligne de commande à l’aide d’Azure Functions Core Tools ou d’Azure CLI. Azure DevOps et GitHub Actions utilisent également One Deploy.

Explorer des exemples de scénarios de migration

Utilisez le référentiel MigrationGetStarted comme modèle pour commencer votre preuve de concept. Ce dépôt inclut un projet Azure Functions prêt à déployer qui dispose des fichiers d’infrastructure et de code source pour vous aider à commencer.

Si vous préférez utiliser Terraform, utilisez MigrationGetStarted-Terraform à la place.

Optimiser et surveiller les performances de l’application sur Azure

Après avoir migré votre charge de travail, nous vous recommandons d’explorer d’autres fonctionnalités sur Azure. Ces fonctionnalités peuvent vous aider à répondre aux futures exigences de charge de travail et à combler les lacunes.

Utiliser Application Insights pour la supervision et la résolution des problèmes

Activez Application Insights pour votre application de fonction afin de collecter des données de télémétrie détaillées pour la surveillance et la résolution des problèmes. Vous pouvez activer Application Insights via le portail Azure ou dans le fichier de configuration host.json de l’application de fonction. Après avoir activé Application Insights, vous pouvez :

  • Collecter des données de télémétrie. Application Insights fournit différentes données de télémétrie telles que les journaux de requête, les métriques de performances, les exceptions et les dépendances.

  • Analysez les journaux et les métriques. Accédez au tableau de bord Application Insights à partir du Portail Azure pour visualiser et analyser les journaux, les métriques et d’autres données de télémétrie. Utilisez les outils intégrés pour créer des requêtes personnalisées et visualiser des données pour obtenir des insights sur les performances et le comportement de votre application de fonction.

  • Configurer des alertes. Configurez des alertes dans Application Insights pour vous informer des problèmes critiques, de la dégradation des performances ou des événements spécifiques. Ces alertes vous aident à surveiller et à répondre rapidement aux problèmes de manière proactive.

Optimiser les coûts et les performances

  • Optimisation de la mise à l’échelle et des performances :

    • Utilisez des fonctionnalités de mise à l’échelle automatique pour gérer efficacement différentes charges de travail.

    • Optimisez le code de fonction pour améliorer les performances en réduisant le temps d’exécution, en optimisant les dépendances et en utilisant des pratiques de codage efficaces.

    • Implémentez des stratégies de mise en cache pour réduire le traitement et la latence répétés pour les données fréquemment sollicitées.

  • Gestion des coûts :

    • Utilisez les outils Microsoft Cost Management pour surveiller et analyser vos coûts Azure Functions.

    • Configurez des alertes de budget et de coût pour gérer et prédire efficacement les dépenses.