Informationen zur Migration von AWS Lambda-Workloads zu OCI Functions

AWS Lambda-Funktionen sind häufig in größere Anwendungs- und Integrationsworkflows eingebettet.

Eine erfolgreiche Migration erfordert mehr als das Verschieben von Code zwischen Plattformen. OCI Functions ist das Standardziel für AWS Lambda-Migrationsinitiativen. Bevor Sie OCI Functions als Ziel auswählen, geben Sie an, wie jede Funktion aufgerufen wird, mit welchen Services sie interagiert, auf welche betrieblichen Verhaltensweisen sie angewiesen ist und welche Verhaltensweisen beibehalten werden müssen.

Diese Bestandsaufnahme umfasst das Erfassen von Triggertyp, maximaler Dauer, Arbeitsspeicherauslastung, Payload-Größen, Nebenläufigkeits-, Wiederholungs- und Fehlerverhalten, Abhängigkeiten, IAM-Berechtigungen, Netzwerkpfaden, Logging, Monitoring und Recovery-Erwartungen. Diese Merkmale bestimmen, ob OCI Functions oder ein anderer OCI-Service das bessere Ziel ist.

Stellen Sie während der Bewertung sicher, dass die Aufruf-, Payload-, Timeout-, Speicher-, Nebenläufigkeits-, Netzwerk-, Abhängigkeits- und Integrationsanforderungen der Workload von OCI Functions unterstützt werden können.

Wenn OCI Functions eine dokumentierte Anforderung nicht erfüllen kann, unterbrechen Sie die Migration, und schließen Sie die Ausnahmeprüfung ab, bevor Sie eine Nicht-Functions-Architektur vorschlagen. Die Ausnahme muss die technische Einschränkung, das überarbeitete Gesamtkostenmodell, den Migrationsaufwand, die betrieblichen Auswirkungen und die ausdrückliche Genehmigung des überarbeiteten Ansatzes umfassen.

Was Sie tun werden

  • Erstellen Sie ein evidenzbasiertes Inventar der Lambda-Konfiguration, Auslöser, Abhängigkeiten, Berechtigungen, Datenverkehr, Ausfälle und Betriebssignale.
  • Vergleichen Sie das Quellverhalten mit OCI Functions-Limits, Aufrufmodi, Triggermustern, Sicherheit, Abhängigkeits-Packaging, Networking und Beobachtbarkeit.
  • Trennen Sie portierbare Geschäftslogik von anbieterspezifischem Ereignisparsing, Identity, SDK-Aufrufen, Deployment Packaging, Logging, Secrets, Wiederholungen und Betriebscode.
  • Stellen Sie die Funktion als OCI Functions-Containerimage bereit, und validieren Sie Ausgaben, Fehler, Nebenwirkungen, Latenz, Kapazität, Wiederholungen, Sicherheit, Beobachtbarkeit und Rollbackbereitschaft vor dem Cutover.

Wie man dieses Playbook verwendet

Dieses Playbook ist ein Leitfaden zur Bewertung und Implementierung.

Bei einem großen Lambda-Anwesen beginnen Sie nicht, jede Funktion manuell zu bewerten. Beginnen Sie mit einem repräsentativen Beispiel, das die primären Laufzeiten, Trigger, Abhängigkeiten, Verkehrsprofile und geschäftskritischen Ebenen abdeckt.

Verwenden Sie das Beispiel für:

  1. Bestätigen Sie den OCI Functions-Migrationsansatz für repräsentative Workloads.
  2. Identifizieren Sie erforderliche Adapter und gezielte Codeänderungen.
  3. Ermitteln Sie die erforderlichen Sicherheits-, Netzwerk-, Deployment- und Betriebsänderungen.
  4. Schätzen Sie den Migrationsaufwand, das Risiko und wiederverwendbare Muster.
  5. Wählen Sie repräsentative Workloads für ein funktionierendes Migrationspilot aus.

Es konvertiert nicht automatisch Lambda-Code oder generiert nicht alle erforderlichen Integrationen.

Architektur

Dieses wiederverwendbare Muster trennt die Quellbewertung von der Zielimplementierung.

Untersuchen Sie zuerst die Lambda-Funktion, ihre Auslöser und ihr Betriebsverhalten. Isolieren Sie anschließend portierbare Geschäftslogik von anbieterspezifischen Adaptern. Die Zielimplementierung wird in einer OCI Functions-Anwendung ausgeführt, aus einem Containerimage bereitgestellt, das in Container Registry gespeichert ist, verwendet OCI IAM und Resource Principals für den Laufzeitzugriff, ruft Secrets aus einem genehmigten Secret Store wie OCI Vault ab und gibt Betriebssignale bei Bedarf über OCI Logging, Monitoring, Alarme und APM aus.

Beziehungszuordnung von AWS Lambda zu OCI Functions

Dies ist eine gruppierte Ansicht des Workload-Envelope, der um OCI Functions neu erstellt werden soll


Beschreibung von migr-lambda-functions-arch.png folgt
Beschreibung der Abbildung "migration-lambda-functions-arch.png"

migr-lambda-funktionen-arch-oracle.zip#GUID-B6E215FE-1619-4CDD-B055-0194D46ADBF8

Architekturprinzipien

  • Zuerst bewerten, dann migrieren. Trigger, Payloads, Wiederholungen, Layer, Berechtigungen, Netzwerke und Betriebsverhalten können unterschiedlich sein.
  • Triggermigration als Verhaltensmigration behandeln. Vergleichen Sie Ereignisform, Authentifizierung, Wiederholungen, Bestellung, Batching, doppelte Zustellung, Filterung, Dead-Letter- oder Fehlerziele und Giftnachrichtenverarbeitung.
  • Messen Sie die Quell-Workload. Erfassen Sie Aufrufrate, Peak-Nebenläufigkeit, Perzentile der Dauer, maximale Dauer, Speicherbelegung, kaltstartempfindliche Pfade, Payload-Größen, Fehlerrate, Throttle-Rate, DLQ- oder Fehleranzahl, Backlog und Downstream-Grenzwerte.
  • Halten Sie die Geschäftslogik portabel. Isolieren Sie Adapter für Ereignisparsing, Identity, SDK-Aufrufe, Objekt- oder Nachrichtenzugriff, Logging, Konfiguration, Secrets und Wiederholungsverhalten.
  • Machen Sie Vorgänge Teil der Migration. Vor dem Cutover müssen Logs, Metriken, Alarme, Dashboards, Traces, Runbooks, Rollback-Trigger und Fehlertests vorhanden sein.

Kernkomponenten

Die Architektur umfasst in der Regel die Lambda-Quell-Workload, einen Migrationsdatensatz, eine OCI-Aufrufschicht, die OCI Functions-Anwendung und das Image sowie die unterstützenden Sicherheits-, Netzwerk- und Betriebsservices. Behandeln Sie die Quelle als Beweis, nicht als direkten Blueprint. Wählen Sie OCI-Komponenten aus den erforderlichen Verhaltens- und Validierungsergebnissen.

Gleichwertige AWS Lambda- und OCI-Konzepte

Verwenden Sie diesen Schlüssel während der Bewertung.

Dieser Schlüssel ist als Übersetzungsleitfaden gedacht, kein Versprechen von Eins-zu-Eins-Äquivalenz. Vergleichen Sie für jede Zeile das Quellverhalten mit dem OCI-Zielverhalten und halten Sie Beweise im Migrationsdatensatz.

AWS Lambda-Konzept OCI-Konzept oder -Muster Vergleich oder Validierung
Funktion und Handler OCI Functions mit Fn FDK-Handler Laufzeit, Architektur, Handler-Einstiegspunkt, Ereignisparser, Antwortobjekt, Fehlerverhalten, lokaler Testpfad und laufzeitspezifische Library-Unterstützung.
ZIP-Paket, Ebenen, Erweiterungen Containerimage oder gemeinsam verwendetes Basisimage Abhängigkeitsversionen, native Librarys, Bildgröße, Startverhalten, Erweiterungsverhalten, eingebettete SDK-Annahmen und ob Abhängigkeiten funktionsübergreifend gemeinsam verwendet werden sollen.
Ausführungsrollen- und Ressourcen-Policys OCI Identity and Access Management-(IAM-)Policys, dynamische Gruppen und Resource Principals Laufzeitaktionen, Compartment- und Ressourcengeltungsbereich, Cross-Account- oder Cross-Compartment-Zugriff, Secret-Lesevorgänge, Objekt- oder Queuezugriff und Prüfungen auf abgelehnten Pfad.
API-Gateway plus Lambda OCI API Gateway plus OCI Functions Authentifizierung, Route und Methode, Header, Abfragezeichenfolgen, Bodyschema, Statuscodes, Antwortheader, Timeout, Payload-Größe, Latenz und Fehlerbody.
S3-Objektereignisse OCI Object Storage-Ereignisse über OCI-Ereignisse Ereignisschema, Objektmetadaten, Namespace, Bucket- und Präfixfilter, Verhalten beim Erstellen/Aktualisieren/Löschen, Wiederholungen, Duplikate, Idempotenz und Verhinderung von Eingabe-/Ausgabeschleifen.
SQS, Streams, SNS, EventBridge, Logabonnements OCI Queue, OCI Streaming, OCI-Benachrichtigungen, OCI-Ereignisse, OCI Connector Hub oder neu gestalteter Ablauf Batchgröße, Bestellung, Wiederholung, Teilfehler, Dead-Letter- oder Fehlerziel, Sichtbarkeit oder Wiederholungsfenster, Gegendruck, Giftnachrichten, Fanout, Filter und doppelte Zustellung.
Synchroner oder asynchroner Aufruf Aufruf synchronisieren oder getrennt Caller-Antwort-Semantik, Ergebnisbehandlung, Aufruf-Timeout, Ausführungstimeout, getrennte Abschlussbehandlung, Ziel für Erfolg/Fehler und Wiederholungspfad.
Speicher, Timeout, Payload, ephemere Annahmen Speicher-, Timeout-, Anforderungs-, Antwort-, Image- und Laufzeiteinstellungen in OCI Functions p95/p99 und maximale Dauer, Timeoutanzahl, Speicher-Headroom, Payload-Größen für Anforderungen/Antworten, Annahmen für temporären Speicher, Design für Auslagerung großer Nutzlasten und Ladezeit für Abhängigkeiten.
Reservierte/bereitgestellte Nebenläufigkeit und Skalierung von Ereignisquellen OCI-Servicelimits, Nebenläufigkeit der Anwendung, bereitgestellte Nebenläufigkeit, Triggerkontrollen und Downstream-Schutz Nebenläufigkeit bei aktuellem und Spitzenwert, Cold-Start-Empfindlichkeit, Throttles oder 429s, Warteschlangenalter oder -rückstand, Wiederholungsstürme, nachgelagerte Kapazitätsgrenzen und ob die Quelleinstellung Kapazität reserviert, den Datenverkehr begrenzt oder die Latenz verringert.
CloudWatch-Protokolle, Metriken, Alarme, Röntgen OCI Logging, OCI Monitoring, Alarme, Dashboards und Oracle Application Performance Monitoring (APM) bei Bedarf Erforderliche Logfelder, Korrelations-IDs, Aufrufanzahl, Dauer, Fehlerrate, Timeoutanzahl, Alarmschwellenwerte, Traces, Dashboards, Runbooks und Verantwortlichkeit für Vorfallsreaktionen.
Secrets Manager, Parameter Store, KMS, VPC-Netzwerke OCI Vault, Schlüssel, VCN, Subnetze, Gateways, private Endpunkte, DNS und Sicherheitsregeln Secret-Rotation, Leckprüfungen, Routingregeln, Egress, DNS, Ausnahmelisten, privater Zugriff, Blockierung nicht autorisierter Pfade und Limits für Downstream-Verbindungen.