Freigeben über

Migrieren von AWS Lambda-Workloads zu Azure Functions

Die Migration einer serverlosen Workload, die Amazon Web Services (AWS) Lambda zu Azure Functions verwendet, erfordert eine sorgfältige Planung und Implementierung. Dieser Artikel enthält wichtige Anleitungen, die Ihnen helfen:

  • Führen Sie einen Ermittlungsprozess für Ihre vorhandene Workload aus.
  • Erfahren Sie, wie Sie wichtige Migrationsaktivitäten wie die Vormigrationsplanung und die Workloadbewertung durchführen.
  • Bewerten und Optimieren einer migrierten Workload.

Umfang

In diesem Artikel wird die Migration einer AWS Lambda-Instanz zu Azure Functions beschrieben.

In diesem Artikel wird folgendes nicht behandelt:

  • Migration zu Ihrer eigenen Containerhostinglösung, z. B. über Azure-Container-Apps.
  • Hosting von AWS Lambda-Containern in Azure.
  • Grundlegende Ansätze der Azure-Einführung durch Ihre Organisation, wie z. B. Azure-Zielzonen oder andere Themen, die in der Migrationsmethodik des Cloud Adoption Frameworks behandelt werden.

Vergleich der Funktionalität

Dieser Artikel ordnet die Merkmale von AWS Lambda den entsprechenden Funktionen in Azure zu, um die Kompatibilität sicherzustellen.

Von Bedeutung

Sie können die Optimierung in Ihren Migrationsplan einbeziehen, aber Microsoft empfiehlt einen zweistufigen Prozess. Migrieren Sie zuerst "Like-to-like"-Funktionen, und bewerten Sie dann Optimierungsmöglichkeiten in Azure.

Optimierungsbemühungen sollten kontinuierlich sein und über die Änderungskontrollprozesse Ihres Workload-Teams gesteuert werden. Eine Migration, die während einer Migration mehr Funktionen hinzufügt, führt zu Risiken und erweitert den Prozess unnötig.

Arbeitsauslastungsperspektive

Dieser Artikel befasst sich mit der Migration einer AWS Lambda-Workload zu Azure Functions und den allgemeinen Abhängigkeiten für serverlose Workloads. Dieser Prozess kann mehrere Dienste umfassen, da Workloads viele Ressourcen und Prozesse umfassen, um diese Ressourcen zu verwalten. Um eine umfassende Strategie zu haben, müssen Sie die in diesem Artikel vorgestellten Empfehlungen mit einem größeren Plan kombinieren, der die anderen Komponenten und Prozesse in Ihrer Workload enthält.

Durchführung eines Ermittlungsprozesses für Ihre vorhandene Workload

Der erste Schritt besteht darin, einen detaillierten Ermittlungsprozess durchzuführen, um Ihre vorhandene AWS Lambda-Workload zu bewerten. Ziel ist es zu verstehen, welche AWS-Features und -Dienste Ihre Workload benötigt. Kompilieren Sie einen umfassenden Bestand Ihrer AWS Lambda-Funktionen mithilfe von AWS-Tools wie servicespezifische SDKs, APIs, CloudTrail und AWS CLI, um die Workload auf AWS zu bewerten. Sie sollten die folgenden wichtigen Aspekte Ihres AWS Lambda-Inventars verstehen:

  • Anwendungsfälle
  • Konfigurationen
  • Sicherheits- und Netzwerkeinrichtung
  • Werkzeuge, Überwachung, Protokollierung und Beobachtbarkeitsmechanismen
  • Abhängigkeiten
  • Zuverlässigkeitsziele und aktueller Zuverlässigkeitsstatus
  • Die Betriebskosten
  • Leistungsziele und aktuelle Leistung

Durchführen der Vormigrationsplanung

Bevor Sie mit der Migration Ihrer Workload beginnen, müssen Sie AWS Lambda-Features Azure Functions zuordnen, um Kompatibilität sicherzustellen und einen Migrationsplan zu entwickeln. Anschließend können Sie wichtige Workloads für einen Machbarkeitsnachweis auswählen.

Sie müssen die AWS-Dienste, von denen Lambda abhängig ist, auch den entsprechenden Abhängigkeiten in Azure zuordnen.

Zuordnen von AWS Lambda-Features zu Azure Functions

In den folgenden Tabellen werden AWS Lambda-Konzepte, Ressourcen und Eigenschaften mit ihren entsprechenden Entsprechungen in Azure Functions verglichen, insbesondere mit dem Flex-Verbrauch-Hostingplan.

Unterstützte Sprachen

Programmiersprache Unterstützte AWS Lambda-Versionen Unterstützte Versionen von Azure-Funktionen
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 Nicht unterstützt 7.4
.NET .NET 8 .NET 8, .NET 9, .NET Framework 4.8.1
Rubin 3.2, 3.3 Benutzerdefinierte Handler
Go Betriebssystemsspezifische Runtime Benutzerdefinierte Handler
Rost Betriebssystemsspezifische Runtime Benutzerdefinierte Handler

Programmiermodell

Merkmal AWS Lambda Azure-Funktionen
Auslöser Integriert mit anderen AWS-Diensten mittels Ereignisquellen. Bietet automatische und programmgesteuerte Methoden zum Verknüpfen von Lambda-Funktionen mit Ereignisquellen. Eine Funktion mithilfe spezifischer Ereignisse auslösen, wie beispielsweise bei Aktualisierungen in einer Datenbank oder einer neuen Nachricht in einer Warteschlange. Beispielsweise ermöglicht ein Azure Cosmos DB-Trigger Funktionen automatisch auf Einfügungen und Updates in einem Azure Cosmos DB-Container zu reagieren. Diese Aktion ermöglicht die Echtzeitverarbeitung von Datenänderungen.

Funktionen sind auch in Azure Event Grid integriert, sodass Ereignisse aus Azure-Diensten wie Azure Storage und Azure Media Services und externen Ereignisquellen verarbeitet werden können. Event Grid dient als zentralisierter, erweiterbarer Ereignisroutingdienst, der Funktionentrigger ergänzt und eine hohe Skalierbarkeit und breite Ereignisquellenabdeckung ermöglicht.
Bindungen Hat keine Bindungen. Verwendet AWS-SDKs innerhalb von Lambda-Funktionen, um Interaktionen mit anderen AWS-Diensten manuell zu verwalten. Bindungen, die als Eingabe oder Ausgabe konfiguriert sind, ermöglichen deklarative Verbindungen mit Diensten, die den Bedarf an expliziten SDK-Code minimieren. Sie können z. B. Bindungen so konfigurieren, dass sie aus Blob Storage lesen, in Azure Cosmos DB schreiben oder E-Mails über SendGrid senden, ohne die Integrationen manuell zu verwalten.

Ereignistrigger und Bindungen

AWS Lambda-Trigger oder -Dienst Auslöser für Azure Functions BESCHREIBUNG
API-Gateway: HTTP-Anforderungen HTTP-Trigger Mit diesen Triggern können Sie HTTP-Anforderungen direkt verarbeiten.
Einfacher Warteschlangendienst (SQS) Azure Queue Storage Trigger oder Azure Service Bus Trigger Diese Trigger können Nachrichten in Warteschlangen verarbeiten.
Einfacher Benachrichtigungsdienst (Simple Notification Service, SNS) Event Grid-Trigger oder Service Bus-Trigger Diese Trigger ermöglichen die Benachrichtigungsverarbeitung.
Kinesis (Datenströme) Event Hubs-Trigger Diese Trigger nutzen Datenströme.
DynamoDB (Tabellenänderungen) Azure Cosmos DB – Änderungsfeedauslöser Diese Trigger lauschen auf Änderungen in Tabellen.
CloudWatch Events oder EventBridge Scheduler Timertrigger Diese Trigger behandeln geplante oder zeitbasierte Funktionen.
S3 (Objektereignisse) Blob Storage-Trigger Diese Trigger reagieren auf Ereignisse im Blobspeicher.
Amazon Relational Database Service (RDS) Azure SQL-Trigger Diese Trigger reagieren auf Datenbankänderungen.
Verwaltetes Streaming für Apache Kafka (MSK) Apache Kafka-Trigger Diese Trigger reagieren auf Kafka-Themenmeldungen.
Amazon ElastiCache Azure Redis-Trigger Diese Trigger reagieren auf Nachrichten in Redis.
Amazon MQ RabbitMQ-Trigger Diese Trigger reagieren auf Nachrichten in RabbitMQ.

Erlaubnisse

AWS Lambda Azure-Funktionen
Die Lambda-Ausführungsrolle gewährt Lambda-Funktionen Berechtigungen für die Interaktion mit anderen AWS-Diensten. Jede Lambda-Funktion verfügt über eine zugeordnete Identitäts- und Zugriffsverwaltungsrolle (IAM), die ihre Berechtigungen bestimmt, während sie ausgeführt wird. Verwaltete Identitäten stellen eine Identität für Ihre Funktions-App bereit, die es ermöglicht, sich bei anderen Azure-Diensten zu authentifizieren, ohne Anmeldeinformationen im Code zu speichern. Die rollenbasierte Zugriffssteuerung weist der verwalteten Identität in der Microsoft Entra-ID geeignete Rollen zu, um Zugriff auf die benötigten Ressourcen zu gewähren.
Ressourcenbasierte Richtlinienanweisungen:

- AWSLambda_FullAccess bietet vollzugriff auf alle Lambda-Vorgänge, einschließlich Erstellen, Aktualisieren und Löschen von Funktionen.

– AWSLambda_ReadOnlyAccess ermöglicht schreibgeschützten Zugriff auf die Ansicht von Lambda-Funktionen und deren Konfigurationen.

– Benutzerdefinierte IAM-Richtlinien.		 Ressourcenbasierte integrierte Rollen:

– Die Rolle "Besitzer" gewährt vollzugriff, einschließlich der Zugriffsberechtigungsverwaltung.

– Die Rolle "Mitwirkender" kann Funktions-Apps erstellen und löschen, Einstellungen konfigurieren und Code bereitstellen. Es kann den Zugriff nicht verwalten.

– Die Rolle „Überwachungsleser” kann schreibgeschützten Zugriff auf Überwachungsdaten und -einstellungen gewähren. Sie kann auch benutzerdefinierte Rollen zuweisen.

Funktions-URL

AWS Lambda Azure-Funktionen
https://<url-id>.lambda-url.<region>.on.aws - <appname>.azurewebsites.net (originaler, globaler Standardhostname)

- <appname>-<randomhash>.<Region>.azurewebsites.net (neuer, eindeutiger Standardhostname)

Vernetzung

AWS Lambda Azure-Funktionen
Alle Lambda-Funktionen werden sicher in einer standardmäßigen vom System verwalteten virtuellen privaten Cloud (VM) ausgeführt. Sie können Ihre Lambda-Funktion auch so konfigurieren, dass sie auf Ressourcen in einer benutzerdefinierten VPC zugreifen kann. Funktions-Apps können netzwerksicher sein und auf andere Dienste innerhalb des Netzwerks zugreifen. Der eingehende Netzwerkzugriff kann nur auf eine Firewallliste mit IP-Adressen und auf ein bestimmtes virtuelles Netzwerk über Dienstendpunkte oder private Endpunkte beschränkt werden. Der ausgehende Netzwerkzugriff wird über das Feature für die Integration des virtuellen Netzwerks aktiviert. Die Funktions-App kann den gesamten Datenverkehr auf das Subnetz eines virtuellen Netzwerks beschränken und auch auf andere Dienste innerhalb dieses virtuellen Netzwerks zugreifen.

Einblick und Überwachung

AWS Lambda Azure-Funktionen
Amazon CloudWatch hilft bei der Überwachung und Beobachtbarkeit, indem Metriken gesammelt und nachverfolgt, Protokolle aggregiert und analysiert werden, Alarme festgelegt, benutzerdefinierte Dashboards erstellt und automatisierte Antworten auf Änderungen der Ressourcenleistung und -metrik implementiert werden. Azure Monitor bietet umfassende Überwachung und Beobachtbarkeit für Azure Functions, insbesondere durch die Funktion "Application Insights".

Application Insights sammelt Telemetriedaten wie Anforderungsraten, Reaktionszeiten und Fehlerraten. Es visualisiert Anwendungskomponentenbeziehungen, überwacht die Leistung in Echtzeit, protokolliert detaillierte Diagnosen und ermöglicht die benutzerdefinierte Metrikverfolgung. Diese Funktionen tragen dazu bei, die Leistung, Verfügbarkeit und Zuverlässigkeit von Azure-Funktionen aufrechtzuerhalten und gleichzeitig benutzerdefinierte Dashboards, Warnungen und automatisierte Antworten zu aktivieren.
AWS Lambda generiert Telemetriedaten aus Ihren Funktionsaufrufen und kann diese Daten mithilfe der OpenTelemetry-Semantik exportieren. Sie können Ihre Lambda-Funktionen so konfigurieren, dass diese Telemetriedaten an einen beliebigen OpenTelemetry-kompatiblen Endpunkt gesendet werden. Diese Aktion ermöglicht die Korrelation von Traces und Protokollen, konsistenten, standardbasierten Telemetriedaten und die Integration mit anderen Überwachungstools, die OpenTelemetry unterstützen. Konfigurieren Sie Ihre Funktionen-App so, dass Protokoll- und Ablaufverfolgungsdaten in einem OpenTelemetry-Format exportiert werden. Sie können Telemetriedaten mithilfe von OpenTelemetry in einen beliebigen kompatiblen Endpunkt exportieren. OpenTelemetry bietet Vorteile wie die Korrelation von Ablaufverfolgungen und Protokollen, konsistente standardbasierte Telemetriedaten und die Integration mit anderen Anbietern. Sie können OpenTelemetry auf Der Ebene der Funktions-App in der Hostkonfiguration und in Ihrem Codeprojekt aktivieren, um den Datenexport aus Dem Funktionscode zu optimieren. Weitere Informationen finden Sie unter Verwenden von OpenTelemetry mit Azure-Funktionen.

Skalierung und Parallelität

AWS Lambda Azure-Funktionen
AWS verwendet ein On-Demand-Skalierungsmodell. Skalieren Sie ihren Funktionsvorgang automatisch als Reaktion auf den Bedarf. Die Nebenläufigkeit, also die Anzahl der Anfragen, die von einer Instanz verarbeitet werden, beträgt immer 1. Instanzen werden basierend auf der Anzahl der eingehenden Ereignisse und der konfigurierten Parallelität für jede Instanz dynamisch hinzugefügt und entfernt. Sie können die Parallelitätseinstellung auf ihren gewünschten Wert konfigurieren.
Nebenläufigkeit ist immer 1. Parallelität ist konfigurierbar (>1).
Unterstützt die Skalierung auf 0. Unterstützt die Skalierung auf 0.

Kaltstartschutz

AWS Lambda Azure-Funktionen
Die bereitgestellte Parallelität reduziert die Latenz und sorgt für vorhersehbare Funktionsleistung, indem eine angeforderte Anzahl von Funktionsinstanzen vorab initialisiert wird. Vorgesehene Parallelität eignet sich für Anwendungen, die empfindlich auf Latenz sind, und wird separat von der Standardparallelität abgerechnet. Mit Funktions-Apps können Sie die Parallelität für jede Instanz konfigurieren, die die Skalierung steuert. Mehrere Aufträge können in derselben Instanz der App parallel ausgeführt werden, und nachfolgende Aufträge in der Instanz führen nicht zum anfänglichen Kaltstart. Funktions-Apps haben auch immer einsatzbereite Instanzen. Kunden können eine Anzahl vorgewärmter Instanzen angeben, um die Kaltstartlatenz zu beseitigen und eine konsistente Leistung sicherzustellen. Funktions-Apps lassen sich je nach Bedarf auf weitere Instanzen aufskalieren, wobei die immer verfügbaren Instanzen erhalten bleiben.
Reservierte Parallelität gibt die maximale Anzahl gleichzeitiger Instanzen an, die eine Funktion aufweisen kann. Dieser Grenzwert stellt sicher, dass ein Teil des Parallelitätskontingents Ihres Kontos ausschließlich für diese Funktion reserviert wird. AWS Lambda skaliert dynamisch, um eingehende Anforderungen zu verarbeiten, auch wenn reservierte Parallelität festgelegt ist, solange die Anforderungen den angegebenen reservierten Parallelitätsgrenzwert nicht überschreiten. Die untere Grenze für reservierte Parallelität in AWS Lambda ist 1. Die obere Grenze für die reservierte Parallelität in AWS Lambda wird durch das regionale Parallelitätskontingent des AWS-Kontos bestimmt. Dieser Grenzwert beträgt standardmäßig 1.000 gleichzeitige Vorgänge für jede Region. Azure Functions verfügt nicht über ein entsprechendes Feature zur reservierten Parallelität. Um ähnliche Funktionen zu erzielen, isolieren Sie bestimmte Funktionen in separate Funktions-Apps, und legen Sie die maximale Skalierungsgrenze für jede App fest. Azure Functions skaliert dynamisch nach außen, indem es weitere Instanzen hinzufügt, und skaliert nach innen, indem es Instanzen entfernt, und bleibt dabei innerhalb der festgelegten Skalierungsgrenzen. Standardmäßig beginnen Apps, die in einem Flex-Verbrauchsplan ausgeführt werden, mit einem konfigurierbaren Grenzwert von insgesamt 100 Instanzen. Der niedrigste maximal zulässige Instanzanzahlswert ist 40, und der höchste unterstützte maximale Instanzenanzahlswert beträgt 1.000. Regionale Abonnementspeicherkontingente können auch einschränken, wie viele Funktions-Apps skaliert werden können, aber Sie können dieses Kontingent durch Aufrufen der Unterstützung erhöhen.

Preisgestaltung

AWS Lambda Azure-Funktionen
– Nutzungsbasierte Zahlung für die Gesamtzahl der Aufrufe und für die verbrauchten GB pro Sekunde für jede Instanz (bei einer festen Nebenläufigkeit von 1)

– Inkremente von 1 ms

- 400.000 Gbps kostenloser Stufe		 - Bezahlen Sie pro Verwendung für die Gesamtzahl der Aufrufe und für die GB/s jeder Instanz (mit konfigurierbaren gleichzeitigen Aufrufen)

– Inkremente von 100 ms

– 100.000 GBit/s Free-Tarif

- Verbrauchsbasierte Kosten

Quellcodespeicher

AWS Lambda Azure-Funktionen
AWS Lambda verwaltet den Speicher Ihres Funktionscodes in einem eigenen verwalteten Speichersystem. Sie müssen keinen weiteren Speicher bereitstellen. Funktionen erfordern einen vom Kunden bereitgestellten Blob Storage-Container, um das Bereitstellungspaket zu verwalten, das den Code Ihrer App enthält. Sie können die Einstellungen für die Verwendung desselben oder eines anderen Speicherkontos für Bereitstellungen konfigurieren und Authentifizierungsmethoden für den Zugriff auf den Container verwalten.

Lokale Entwicklung

AWS Lambda-Funktion Das Azure Functions-Feature
- SAM CLI

- LocalStack		 – Azure Functions Core Tools

- Visual Studio Code

- Visual Studio

- GitHub Codespaces

- VSCode.dev

– Maven

- Code und lokales Testen von Azure Functions

Einsatz

Merkmal AWS Lambda Azure-Funktionen
Bereitstellungspaket - ZIP-Datei

- Containerabbild		 ZIP-Datei (verwenden Sie für die Bereitstellung von Containerimages die dedizierte oder Premium-SKU.)
ZIP-Dateigröße (Konsole) 50 MB maximal maximal 500 MB für ZIP-Bereitstellung
ZIP-Dateigröße (CLI/SDK) maximal 250 MB für ZIP-Bereitstellung, maximal 500 MB für entpackt maximal 500 MB für ZIP-Bereitstellung
Größe des Containerimage maximal 10 GB Containerunterstützung mit flexiblem Speicher über Azure
Umgang mit großen Artefakten Verwenden Sie Containerimages für größere Bereitstellungen. Fügen Sie Blob Storage- oder Azure Files-Freigaben an, um auf große Dateien aus der App zuzugreifen.
Packen allgemeiner Abhängigkeiten in Funktionen Schichten Bereitstellung von ZIP-Dateien, auf Abruf aus dem Speicher oder Containern (nur ACA, dedizierte, EP-SKUs)
Blau-Grün-Bereitstellung oder Funktionsversionsverwaltung Verwenden Sie Funktionsqualifizierer, um auf einen bestimmten Status Ihrer Funktion zu verweisen, indem Sie entweder eine Versionsnummer oder einen Aliasnamen verwenden. Qualifizierer ermöglichen Versionsverwaltung und Strategien für schrittweise Bereitstellung. Verwenden Sie kontinuierliche Integration und kontinuierliche Bereitstellungssysteme für blaugrüne Bereitstellungen.

Timeout- und Speicherbeschränkungen

Merkmal AWS Lambda-Grenzwerte Azure Functions-Grenzwerte
Ausführungstimeout 900 Sekunden (15 Minuten) Das Standardtimeout beträgt 30 Minuten. Der maximale Timeout ist ungebunden. Die an eine Funktionsausführung übergebene Karenzzeit beträgt jedoch 60 Minuten während der Skalierung und 10 Minuten während Plattformupdates. Weitere Informationen finden Sie unter Funktions-App-Timeoutdauer.
Konfigurierbarer Speicher 128 MB bis 10.240 MB, in Schritten von 64 MB Funktionen unterstützen 2-GB- und 4-GB-Instanzengrößen . Jede Region in einem bestimmten Abonnement hat eine Speichergrenze von 512.000 MB für alle Instanzen von Apps, die Sie durch Aufrufen der Unterstützung erhöhen können. Die Gesamtspeicherauslastung aller Instanzen in allen Funktions-Apps in einer Region muss innerhalb dieses Kontingents bleiben.

Obwohl 2 GB und 4 GB die Instanzengrößenoptionen sind, kann die Parallelität für jede Instanz höher als 1 sein. Daher kann eine einzelne Instanz je nach Konfiguration mehrere gleichzeitige Ausführungen verarbeiten. Das geeignete Konfigurieren der Parallelität kann dazu beitragen, die Ressourcennutzung zu optimieren und die Leistung zu verwalten. Durch das Ausgleichen der Speicherzuweisung und Parallelitätseinstellungen können Sie die Ressourcen, die Ihren Funktions-Apps zugeordnet sind, effektiv verwalten und eine effiziente Leistung und Kostenkontrolle gewährleisten. Weitere Informationen finden Sie unter "Speicherkontingente für regionale Abonnements".

Verwaltung von Geheimnissen

AWS Lambda Azure-Funktionen
MIT AWS Secrets Manager können Sie geheime Schlüssel wie Datenbankanmeldeinformationen, API-Schlüssel und andere vertrauliche Informationen speichern, verwalten und abrufen. Lambda-Funktionen können geheime Schlüssel mithilfe des AWS SDK abrufen. Es wird empfohlen, geheimnislose Ansätze wie verwaltete Identitäten zu verwenden, um einen sicheren Zugriff auf Azure-Ressourcen ohne fest codierte Anmeldeinformationen zu ermöglichen. Wenn geheime Schlüssel erforderlich sind, z. B. für Partner- oder Legacysysteme, bietet Azure Key Vault eine sichere Lösung zum Speichern und Verwalten von Geheimschlüsseln, Schlüsseln und Zertifikaten.
AWS Systems Manager Parameter Store ist ein Dienst, der Konfigurationsdaten und geheime Schlüssel speichert. Parameter können mithilfe von AWS KMS verschlüsselt und von Lambda-Funktionen mithilfe des AWS SDK abgerufen werden.
Lambda-Funktionen können Konfigurationseinstellungen in Umgebungsvariablen speichern. Vertrauliche Daten können mit einem KMS-Schlüssel für den sicheren Zugriff verschlüsselt werden.		 Azure Functions verwendet Anwendungseinstellungen zum Speichern von Konfigurationsdaten. Diese Einstellungen werden direkt Umgebungsvariablen zugeordnet, um die Benutzerfreundlichkeit innerhalb der Funktion zu erleichtern. Diese Einstellungen können verschlüsselt und sicher in der Azure App Service-Konfiguration gespeichert werden.
Für erweiterte Szenarien bietet die Azure App-Konfiguration robuste Features für die Verwaltung mehrerer Konfigurationen. Sie ermöglicht das Kennzeichnen von Features und unterstützt dynamische Updates über Dienste hinweg.

Zustandsverwaltung

AWS Lambda Azure-Funktionen
AWS Lambda verarbeitet einfache Zustandsverwaltung mithilfe von Diensten wie Amazon S3 für Objektspeicherung, Amazon DynamoDB für schnelle und skalierbare NoSQL-Zustandsspeicherung und Amazon SQS für die Behandlung von Nachrichtenwarteschlangen. Diese Dienste stellen die Datenpersistenz und Konsistenz über Lambda-Funktionsausführungen hinweg sicher. Azure Functions verwendet AzureWebJobsStorage zur Zustandsverwaltung, indem es Bindungen und Trigger mit Azure Storage-Diensten wie Blob Storage, Warteschlangenspeicher und Tabellenspeicher aktiviert. Sie ermöglicht Funktionen das einfache Lesen und Schreiben des Zustands. Für komplexere Zustandsverwaltung bietet Durable Functions erweiterte Workflow-Orchestrierungs- und Zustandspersistenzfunktionen mithilfe von Azure Storage.

Zustandsbehaftete Orchestrierung

AWS Lambda Azure-Funktionen
Keine Orchestrierung im nativen Zustand. Verwenden Sie AWS-Schrittfunktionen für Workflows. Dauerhafte Funktionen helfen bei der komplexen Zustandsverwaltung, indem dauerhafte Workflow-Orchestrierung und zustandsbehaftete Entitäten bereitgestellt werden. Es ermöglicht lang andauernde Vorgänge, automatische Prüfpunkte und zuverlässige Speicherung des Zustands. Mit diesen Features können komplexe Workflows erstellt werden, um Fehlertoleranz und Skalierbarkeit für zustandsbehaftete Anwendungen zu gewährleisten.

Weitere Unterschiede und Überlegungen

Merkmal AWS Lambda Azure-Funktionen
Gruppieren von Funktionen Jede AWS Lambda-Funktion ist eine unabhängige Entität. Eine Funktions-App dient als Container für mehrere Funktionen. Sie stellt einen freigegebenen Ausführungskontext und eine Konfiguration für die darin enthaltenen Funktionen bereit. Das Behandeln mehrerer Funktionen als einzelne Entität vereinfacht die Bereitstellung und Verwaltung. Funktionen verwenden auch eine Skalierungsstrategie pro Funktion, bei der jede Funktion unabhängig skaliert wird, mit Ausnahme von HTTP-, Blob Storage- und Durable Functions-Triggern. Diese ausgelösten Funktionen werden in ihren eigenen Gruppen skaliert.
Benutzerdefinierte Domänen Aktiviert über das API-Gateway Sie können benutzerdefinierte Domänen direkt in einer Funktions-App oder in Azure API Management konfigurieren.
Benutzerdefinierte Containerunterstützung Unterstützt benutzerdefinierte Container über Lambda-Container-Image Azure Functions unterstützt benutzerdefinierte Container, die in einer Container-Apps-Umgebung ausgeführt werden.

Erstellen eines Migrationsplans

  1. Wählen Sie wichtige Workloads für einen Machbarkeitsnachweis aus.

    Wählen Sie zunächst eine bis zwei mittelgroße, nicht kritische Workloads aus Ihrem Gesamtbestand aus. Diese Workloads dienen als Grundlage für Ihre Machbarkeitsstudie zur Migration. Sie können den Prozess testen und potenzielle Herausforderungen erkennen, ohne eine erhebliche Unterbrechung Ihres Betriebs zu riskieren.

  2. Testen Sie iterativ, und sammeln Sie Feedback.

    Verwenden Sie den Machbarkeitsnachweis, um Feedback zu sammeln, Lücken zu identifizieren und den Prozess zu optimieren, bevor Sie auf größere Workloads skalieren. Mit diesem iterativen Ansatz wird sichergestellt, dass Sie durch den Wechsel zur vollständigen Migration potenzielle Herausforderungen bewältigen und den Prozess verfeinern.

Erstellen der Migrationsressourcen

Dieser Schritt ist eine Übergangsentwicklungsphase. In dieser Phase erstellen Sie Quellcode, Infrastruktur-als-Code (IaC)-Vorlagen und Bereitstellungspipelines, um die Workload in Azure darzustellen. Sie müssen Funktionscode für Kompatibilität und bewährte Methoden anpassen, bevor Sie die Migration ausführen können.

Anpassen von Funktionscode, Konfigurationsdateien und Infrastruktur als Codedateien

So aktualisieren Sie Code für Azure Functions-Laufzeitanforderungen:

Die folgenden Codeausschnitte sind Beispiele für gängigen SDK-Code. Der AWS Lambda-Code ist den entsprechenden Triggern, Bindungen oder SDK-Codeausschnitten in Azure Functions zugeordnet.

Lesen von Amazon S3 im Vergleich zu Azure Blob Storage

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

Azure Functions-Code (Trigger)

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

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

Schreiben in Amazon Simple Queue Service (SQS) im Vergleich zum Azure Queue Storage

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

Azure Functions-Code (Trigger)

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

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

Schreiben zu DynamoDB im Vergleich zu Azure Cosmos DB

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

Azure Functions-Code (Trigger)

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

Amazon CloudWatch-Ereignisse im Vergleich zu einem Azure-Timertrigger

AWS Lambda-Code (SDK)

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

Azure Functions-Code (Trigger)

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) im Vergleich zu einem Azure Event Grid-Trigger

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

Azure Functions-Code (Trigger)

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

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

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

});

Amazon Kinesis im Vergleich zu einem Azure Event Hubs-Trigger

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

Azure Functions-Code (Trigger)

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

Sehen Sie sich die folgenden GitHub-Repositorys an, um AWS Lambda-Code und Azure Functions-Code zu vergleichen:

Anpassen von Konfigurationseinstellungen

Stellen Sie sicher, dass die Timeout- und Speichereinstellungen Ihrer Funktion mit Azure-Funktionen kompatibel sind. Weitere Informationen zu konfigurierbaren Einstellungen finden Sie unter host.json Referenz für Azure Functions.

Befolgen Sie die empfohlenen bewährten Methoden für Berechtigungen, Zugriff, Netzwerk und Bereitstellungskonfigurationen.

Konfigurieren von Berechtigungen

Befolgen Sie bewährte Methoden, wenn Sie Berechtigungen für Ihre Funktions-Apps einrichten. Weitere Informationen finden Sie unter Konfigurieren Ihrer Funktions-App und ihres Speicherkontos mit verwalteter Identität.

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

Weitere Informationen finden Sie unter rbac.bicep.

Konfigurieren des Netzwerkzugriffs

Azure Functions unterstützt die Integration virtueller Netzwerke, wodurch Ihre Funktions-App Zugriff auf Ressourcen in Ihrem virtuellen Netzwerk erhält. Nach der Integration leitet Ihre App ausgehenden Datenverkehr über das virtuelle Netzwerk weiter. Anschließend kann Ihre App auf private Endpunkte oder Ressourcen zugreifen, indem Sie Regeln verwenden, die nur Datenverkehr von bestimmten Subnetzen zulassen. Wenn es sich bei dem Ziel um eine IP-Adresse außerhalb des virtuellen Netzwerks handelt, handelt es sich bei der Quell-IP-Adresse um eine der Adressen, die in den Eigenschaften Ihrer App aufgeführt sind, es sei denn, Sie konfigurieren ein NAT-Gateway.

Wenn Sie die Integration virtueller Netzwerke für Ihre Funktions-Apps aktivieren, befolgen Sie die bewährten Methoden in TSG für die Integration virtueller Netzwerke für Web-Apps und Funktions-Apps.

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

Weitere Informationen finden Sie unter VNet.bicep und storage-PrivateEndpoint.bicep.

Konfigurieren von Bereitstellungseinstellungen

Bereitstellungen folgen einem einzigen Pfad. Nachdem Sie den Projektcode erstellt und in ein Anwendungspaket gezippt haben, stellen Sie ihn in einem Blob Storage-Container bereit. Wenn sie gestartet wird, ruft Ihre App das Paket ab und führt den Funktionscode daraus aus. Standardmäßig dient dasselbe Speicherkonto, das interne Hostmetadaten speichert, wie zum Beispiel AzureWebJobsStorage, auch als Bereitstellungscontainer. Sie können jedoch ein alternatives Speicherkonto verwenden oder Ihre bevorzugte Authentifizierungsmethode auswählen, indem Sie die Bereitstellungseinstellungen Ihrer App konfigurieren. Weitere Informationen finden Sie unter Bereitstellungstechnologiedetails und Konfigurieren von Bereitstellungseinstellungen.

Generieren von IaC-Dateien

  • Verwenden Sie Tools wie Bicep, Azure Resource Manager-Vorlagen oder Terraform, um IaC-Dateien zum Bereitstellen von Azure-Ressourcen zu erstellen.

  • Definieren Sie Ressourcen wie Azure-Funktionen, Speicherkonten und Netzwerkkomponenten in Ihren IaC-Dateien.

  • Verwenden Sie dieses IaC-Beispiel-Repository für Beispiele, die Azure Functions-Empfehlungen und bewährte Methoden verwenden.

Verwenden von Tools für das Refactoring

Verwenden Sie Tools wie GitHub Copilot in VS Code, um Hilfe bei der Codeumgestaltung, der manuellen Umgestaltung für bestimmte Änderungen oder anderen Migrationshilfen zu erhalten.

Hinweis

Verwenden Sie den Agent-Modus in GitHub Copilot in VS Code.

Die folgenden Artikel enthalten spezifische Beispiele und detaillierte Schritte zur Erleichterung des Migrationsprozesses:

Entwickeln eines schrittweisen Prozesses für die Day-0-Migration

Entwickeln Sie Failover- und Failbackstrategien für Ihre Migration, und testen Sie sie gründlich in einer Vorproduktionsumgebung. Es wird empfohlen, End-to-End-Tests durchzuführen, bevor Sie schließlich von AWS Lambda zu Azure Functions wechseln.

  • Überprüfen der Funktionalität

    • Code und lokales Testen von Azure Functions.

    • Testen Sie jede Funktion sorgfältig, um sicherzustellen, dass sie erwartungsgemäß funktioniert. Diese Tests sollten Eingabe-/Ausgabe-, Ereignistrigger- und Bindungsüberprüfungen umfassen.

    • Verwenden Sie Tools wie curl- oder REST-Clienterweiterungen in VS Code, um HTTP-Anforderungen für HTTP-ausgelöste Funktionen zu senden.

    • Stellen Sie bei anderen Triggern wie Timern oder Warteschlangen sicher, dass die Trigger ordnungsgemäß ausgelöst werden und die Funktionen wie erwartet ausgeführt werden.

  • Überprüfen der Leistung

    • Führen Sie Leistungstests durch, um die neue Azure Functions-Bereitstellung mit der vorherigen AWS Lambda-Bereitstellung zu vergleichen.

    • Überwachen Sie Metriken wie Antwortzeit, Laufzeit und Ressourcenverbrauch.

    • Verwenden Sie Application Insights zur Überwachung, Protokollanalyse und Problembehandlung während der Testphase.

  • Problembehandlung mithilfe des Features "Diagnostizieren und Beheben von Problemen"

    Verwenden Sie das Feature "Diagnostizieren und Lösen von Problemen " im Azure-Portal, um Ihre Funktions-App zu beheben. Dieses Tool bietet eine Reihe von Diagnosefeatures, mit denen Sie häufige Probleme wie Anwendungsabstürzen, Leistungsbeeinträchtigungen und Konfigurationsprobleme schnell erkennen und beheben können. Führen Sie die geführten Schritte zur Problembehandlung und Empfehlungen aus, die das Tool bereitstellt, um Probleme zu beheben, die Sie identifizieren.

Auswertung des Endzustands der migrierten Arbeitslast

Bevor Sie Ressourcen in AWS außer Betrieb setzen, müssen Sie sicher sein, dass die Plattform die aktuellen Workload-Erwartungen erfüllt und dass nichts die Workloadwartung oder weiterentwicklung blockiert.

Stellen Sie Funktionen bereit, und testen Sie sie, um ihre Leistung und Korrektheit zu überprüfen.

In Azure bereitstellen

Stellen Sie Workloads bereit, indem Sie die VS Code-Veröffentlichungsfunktion verwenden. Sie können Workloads auch über die Befehlszeile bereitstellen, indem Sie Azure Functions Core Tools oder die Azure CLI verwenden. Azure DevOps - und GitHub-Aktionen verwenden auch One Deploy.

Erkunden von Beispielmigrationsszenarien

Verwenden Sie das MigrationGetStarted-Repository als Vorlage, um den Machbarkeitsnachweis zu beginnen. Dieses Repository enthält ein sofort einsatzbereites Azure Functions-Projekt, das über die Infrastruktur- und Quellcodedateien verfügt, die Ihnen bei den ersten Schritten helfen.

Wenn Sie Terraform bevorzugen, verwenden Sie stattdessen MigrationGetStarted-Terraform .

Optimieren und Überwachen der Leistung der Anwendung in Azure

Nachdem Sie Ihre Workload migriert haben, empfiehlt es sich, weitere Features in Azure zu erkunden. Diese Features können Ihnen helfen, zukünftige Workloadanforderungen zu erfüllen und Lücken zu schließen.

Verwenden von Application Insights zur Überwachung und Problembehandlung

Aktivieren Sie Application Insights für Ihre Funktions-App, um detaillierte Telemetriedaten zur Überwachung und Problembehandlung zu sammeln. Sie können Application Insights über das Azure-Portal oder in der host.json Konfigurationsdatei der Funktions-App aktivieren. Nachdem Sie Application Insights aktiviert haben, können Sie:

  • Sammeln von Telemetriedaten. Application Insights bietet verschiedene Telemetriedaten wie Anforderungsprotokolle, Leistungsmetriken, Ausnahmen und Abhängigkeiten.

  • Analysieren Sie Protokolle und Metriken. Greifen Sie über das Azure-Portal auf das Application Insights-Dashboard zu, um Protokolle, Metriken und andere Telemetriedaten zu visualisieren und zu analysieren. Verwenden Sie die integrierten Tools, um benutzerdefinierte Abfragen zu erstellen und Daten zu visualisieren, um Einblicke in die Leistung und das Verhalten Ihrer Funktions-App zu erhalten.

  • Einrichten von Warnungen. Konfigurieren Sie Warnungen in Application Insights, um Sie über kritische Probleme, Leistungsbeeinträchtigungen oder bestimmte Ereignisse zu informieren. Diese Warnungen helfen Ihnen dabei, Probleme proaktiv zu überwachen und schnell zu reagieren.

Optimieren für Kosten und Leistung

  • Skalierungs- und Leistungsoptimierung:

    • Verwenden Sie automatische Skalierungsfeatures, um unterschiedliche Workloads effizient zu verarbeiten.

    • Optimieren Sie Funktionscode, um die Leistung zu verbessern, indem Sie die Laufzeit reduzieren, Abhängigkeiten optimieren und effiziente Codierungsmethoden verwenden.

    • Implementieren Sie Zwischenspeicherungsstrategien, um wiederholte Verarbeitung und Latenz für häufig aufgerufene Daten zu reduzieren.

  • Kostenmanagement:

    • Verwenden Sie Microsoft Cost Management-Tools , um Ihre Azure Functions-Kosten zu überwachen und zu analysieren.

    • Richten Sie Budgetierungs- und Kostenwarnungen ein, um Ausgaben effektiv zu verwalten und vorherzusagen.