Refactoring anbieterspezifische Grenzwerte

Behalten Sie die Geschäftslogik bei, während Sie AWS-spezifischen Integrationscode ersetzen.

Gehen Sie folgendermaßen vor, um anbieterspezifische Grenzen neu zu definieren:

  1. Extrahieren Sie Geschäftslogik in Provider-neutrale Module. Fügen Sie einen AWS-Ereignisparser nur zur Wiedergabe erfasster Quellereignisse während Vergleichstests hinzu.
  2. Erstellen Sie einen OCI-Adapter für das Zielaufrufmuster: Anforderung/Antwort, CloudEvent, Queue-Nachricht, Stream-Datensatz, Objektereignis, Benachrichtigung oder Integrationsanforderung.
  3. Ersetzen Sie direkte AWS-SDK-Aufrufe durch Schnittstellen, und implementieren Sie OCI-Serviceaufrufe hinter diesen Schnittstellen. Gleiches gilt für Konfiguration, Secret-Zugriff, Logging, Metriken und Wiederholungsverarbeitung.
  4. Geben Sie erfasste Lambda-Ereignisse wieder, und vergleichen Sie Statuscodes, Header, Antwortbody, Objektmetadaten, Downstream-Schreibvorgänge, Nebenwirkungen, Fehlermeldungen und Idempotenzverhalten.

Suchen Sie nach Geschäftslogik, die von Ereignisparsing, SDK-Aufrufen, IAM-Annahmen, Logging, Packaging und Wiederholungsverarbeitung getrennt werden soll.

Überlegungen: Vermeiden Sie das Neuschreiben der Geschäftslogik gleichzeitig mit der Providerintegration. Das Ändern von beiden macht Äquivalenztests schwieriger.

Vorteile von OCI

Identifizieren Sie, welche Migrationsschritte die Standard-OCI-Konfiguration verwenden und welche benutzerdefinierten Code erfordern.

Oracle Cloud Infrastructure bietet Services für Funktionsausführung, API-Management, Ereignisse, Queues, Planung, Identität, Networking, Beobachtbarkeit und Deployment. Für die Migration sind jedoch möglicherweise noch Workload-spezifische Änderungen erforderlich, darunter:

  • Konvertieren von AWS-Ereignis-Payloads in den von der Anwendung erwarteten Input
  • AWS-SDK-Aufrufe durch OCI-SDK-Aufrufe ersetzen
  • Trigger-, Wiederholungs-, Sortier- und Fehlerverhalten neu erstellen
  • IAM-Berechtigungen und Netzwerkzugriff übersetzen
  • Aktualisierung von CI/CD-Pipelines und Betriebsverfahren

Identifizieren Sie vor der Implementierung, welche Schritte die Standard-OCI-Konfiguration verwenden und welche benutzerdefinierten Code erfordern. Validieren Sie diese Unterscheidung mit einer repräsentativen Workload, bevor Sie die umfassendere Migration schätzen.

OCI-Funktion packen und bereitstellen

Erstellen Sie die migrierte Funktion als Containerimage, und stellen Sie sie in OCI Functions bereit.

Um eine Funktion zu verpacken und bereitzustellen, gehen Sie wie folgt vor:

  1. Erstellen oder aktualisieren Sie das Funktionsprojekt und func.yaml. Legen Sie Speicher und Timeout für das gemessene Quellverhalten fest, nicht für Standardwerte.
  2. Verschieben Sie frühere Lambda-Layerinhalte, native Abhängigkeiten, Laufzeitabhängigkeiten, Zertifikate und Systempackages nach Bedarf in das Image oder ein gemeinsames Basisimage.
  3. Verfolgen Sie Imagegröße, Abhängigkeitsversionen, Kompatibilität der nativen Bibliothek, Startverhalten, Initialisierungsarbeit und Laufzeitverhalten innerhalb des Containerimages.
  4. Erstellen, übertragen, bereitstellen und aufrufen Sie die Funktion mit repräsentativen Erfolgs- und Fehler-Payloads, bevor Sie Produktions-Trigger verbinden.

Prüfen Sie, ob das Image erfolgreich erstellt, übertragen, bereitgestellt, aufgerufen und die erwartete Ausgabe protokolliert, ohne dass Geheimnisse verloren gehen.

Überlegungen: Dependency Packaging ist oft der Ort, an dem versteckte Lambda-Annahmen auftreten, insbesondere bei Layern, nativen Bibliotheken, Erweiterungen und eingebetteten SDK-Versionen.

Wiederholbares Zustellungsmuster verwenden

Eine Produktionsmigration sollte einen versionsgesteuerten Lieferprozess verwenden.

So verwenden Sie ein wiederholbares Zustellungsmuster:

  1. Speichern Sie Funktionscode, Konfiguration, Tests und Infrastrukturdefinitionen zusammen.
  2. Erstellen und testen Sie ein versioniertes Funktionsartefakt.
  3. Scannen Sie das Artefakt und seine Abhängigkeiten.
  4. Fördern Sie dasselbe getestete Artefakt über Umgebungen hinweg.
  5. Stellen Sie OCI-Ressourcen über Infrastructure as Code bereit, oder aktualisieren Sie sie.
  6. Führen Sie Rauch- und Integrationstests nach dem Deployment aus.
  7. Behalten Sie das vorherige Produktionsartefakt und die Konfiguration für das Rollback bei.

Nutzen Sie die vorhandene CI/CD-Plattform, wo es praktisch ist. Fordern Sie keine Änderung des Tools an, es sei denn, dies ist für die OCI Functions-Architektur erforderlich.

Trigger und Integrationen migrieren

Erstellen Sie das erforderliche Aufrufverhalten in OCI neu.

So migrieren Sie Trigger und Integrationen:

  1. Bei HTTP-Workloads vergleichen Sie Authentifizierung, Methode, Pfad, Header, Abfragezeichenfolgen, Bodyschema, Statuscodes, Fehlerbody, Payload-Größe, Timeout, Latenz und das Wiederholungsverhalten des Aufrufers.
  2. Vergleichen Sie für Objektereignisse das Ereignisschema, die Objektmetadaten, den Namespace, den Bucket und die Präfixfilterung, das Erstellen/Aktualisieren/Löschen-Verhalten, das Wiederholungsverhalten, doppelte Ereignisse, die Idempotenz und die Schleifenverhinderung zwischen Eingabe- und Ausgabepfaden.
  3. Entwerfen Sie für Queues und Streams eine explizite Behandlung für Batchgröße, Bestellung, Teilfehler, Sichtbarkeit oder Wiederholungsverhalten, DLQ- oder Fehlerziel, Giftnachrichten, Backpressure, Duplikate, Durchsatz und Wiedergabe.
  4. Prüfen Sie bei Zeitplänen, Benachrichtigungen, Logs und Integrationsflüssen den Aufruftyp, die Latenz, die Anzahl der Wiederholungen, das Fehlerrouting, das Fanoutverhalten, die Filterung und die Beobachtbarkeit.

Stellen Sie sicher, dass jeder Trigger ein dokumentiertes OCI-Zielmuster aufweist und Tests für Normal-, Fehler-, Wiederholungs- und Duplikatbereitstellungsszenarios bestehen.

Überlegungen: Gehen Sie nicht davon aus, dass eine AWS-Ereignisquellenzuordnung einen direkten OCI-Ersatz aufweist. Behalten Sie das erforderliche Verhalten bei, nicht den AWS-Kontrollnamen.

Häufige Lambda-Triggermuster

Die folgenden Zuordnungen starten Muster für eine OCI Functions-Migration.

Vor der Implementierung das erforderliche Verhalten validieren:

AWS-Muster OCI Functions-Startmuster Zu validierende Elemente
API-Gateway zu Lambda OCI API Gateway zu OCI Functions Routen, Methoden, Authentifizierungs-, Anforderungs- und Antwortformate, Payload-Limits, Timeouts, Statuscodes und synchrones Fehlerverhalten
EventBridge nach Lambda OCI-Ereignisse zu OCI Functions für OCI-Serviceereignisse. Verwenden Sie den anwendbaren OCI-Eventrouting-Service für breitere Routinganforderungen Ereignisabdeckung, Filter, Schemas, Zustellungsverhalten, Wiederholungen und Wiedergabeanforderungen
Servicemengen nach Lambda Oracle Cloud Infrastructure Queue über OCI Connector Hub zu OCI Functions Batchgröße, Sichtbarkeitstimeout, sofortige Lieferung, Bestellung, doppelte Verarbeitung, Giftnachrichten und Fehlerwiederherstellung
S3 Veranstaltungen zu Lambda OCI Object Storage-Ereignisse über OCI-Ereignisse in OCI Functions Ereignisschema, Filter, doppelte Zustellung, Objektberechtigungen, Wiederholungsverhalten und nachgelagerte Nebenwirkungen
Geplante Veranstaltungen nach Lambda OCI Resource Scheduler zu OCI Functions Ausdruck, Zeitzone, Eingabe-Payload, Timeout, sich überschneidende Ausführungen sowie Erfolgs- oder Fehlerziele planen

Gehen Sie nicht davon aus, dass AWS- und OCI-Services dasselbe Verhalten aufweisen. Validieren Sie das für jede Workload erforderliche Verhalten vor der Implementierung.

Trigger- und Fehlerverhalten beibehalten

Dokumentieren und testen Sie das für jeden migrierten Trigger erforderliche Verhalten.

Um das Trigger- und Fehlerverhalten beizubehalten, gehen Sie wie folgt vor:

  1. Dokumentieren und testen Sie für jeden migrierten Trigger Folgendes:
    • Gibt an, ob die Zustellung synchron oder asynchron ist
    • Eigentümer, Wiederholungsintervall und maximale Anzahl von Versuchen wiederholen
    • Liefergarantien und mögliche doppelte Ereignisse
    • Bestellanforderungen
    • Idempotenzverhalten
    • Batch- und Teilfehlerverhalten
    • Sichtbarkeitstimeout oder Bestätigungsverhalten
    • Behandlung von Giftnotizen
    • Ziel für Fehler oder Dead-Letter
    • Wiedergabe- und Wiederherstellungsverfahren
  2. Gehen Sie nicht davon aus, dass ähnliche AWS- und OCI-Services dasselbe Bereitstellungs- oder Fehlerverhalten aufweisen.
  3. Wenn eine doppelte Zustellung möglich ist, entwerfen Sie die Funktion, um wiederholte Ereignisse sicher zu verarbeiten.

Für getrennte OCI Functions-Aufrufe können Erfolgs- und Fehlerdatensätze an OCI-Queue-, OCI Streaming- oder OCI-Benachrichtigungsziele gesendet werden. Dieses Verhalten ist spezifisch für getrennte Aufrufe und sollte nicht als universeller Ersatz für jedes AWS Dead-Brief-Queue-Muster beschrieben werden.

IAM, Secrets und Networking konfigurieren

Übersetzen Sie Laufzeitverhalten in OCI-Zugriff mit den geringsten Berechtigungen und genehmigte Netzwerkerreichbarkeit.

Um OCI Identity and Access Management (IAM), Secrets und Networking zu konfigurieren, gehen Sie wie folgt vor:

  1. Ordnen Sie jede Quellaktion einer OCI-Aktion, -Ressource und -Compartment zu. Vermeiden Sie allgemeine Richtlinien, es sei denn, die Workload erfordert sie wirklich, und Prüfer genehmigen sie.
  2. Verwenden Sie dynamische Gruppen und Resource Principals für den Laufzeitzugriff auf OCI-Ressourcen. Testen Sie sowohl zulässige als auch abgelehnte Pfade, einschließlich falschem Compartment, falschem Bucket, falschem Secret und fehlenden Policy-Fällen.
  3. Secrets in OCI Vault oder ein genehmigtes Muster verschieben. Vergewissern Sie sich, dass keine Secret-Werte in Quellcode, Bildern, Logs, Umgebungsdumps, CI-Ausgabe, Stacktraces oder Fehlermeldungen angezeigt werden.
  4. Validieren Sie Routingregeln, Sicherheitsregeln, Servicegateway- oder NAT-Verhalten, private Endpunkte, DNS, TLS-Vertrauen, externe Ausnahmelisten und Downstream-Verbindungslimits.

Stellen Sie sicher, dass zulässige Serviceaufrufe erfolgreich, abgelehnte Pfade sicher und erforderliche Netzwerkpfade erreichbar sind, ohne nicht autorisierte Pfade verfügbar zu machen.

Überlegungen: Die IAM-Übersetzung sollte vom beobachteten Laufzeitverhalten ausgehen, nicht von AWS-Richtliniennamen oder umfassenden verwalteten Richtlinien.

Beobachtbarkeit und Vorgänge neu erstellen

Stellen Sie sicher, dass Produktionseigentümer Fehler erkennen, diagnostizieren und beheben können.

Um Beobachtbarkeit und Vorgänge neu zu erstellen, gehen Sie wie folgt vor:

  1. Ausgeben von Logs mit Korrelations-ID, Anforderungs-ID, Trigger-ID, Objekt- oder Nachrichten-ID, Status, Dauer, Anzahl Wiederholungen, bereinigten Fehlerdetails und Downstream-Abhängigkeitsergebnissen.
  2. Bestätigen Sie Metriken und Alarme für Aufrufanzahl, Dauer, Fehlerrate, Timeoutanzahl, Throttling- oder Kapazitätssymptome, DLQ- oder Fehleranzahl, Warteschlangenalter oder -rückstand, getrennte Zustellungsergebnisse und Downstreamfehler.
  3. Erstellen Sie Dashboards oder genehmigte Ansichten für Zustand, Latenz, Fehler, Kapazität, Trigger-Backlog und Abhängigkeitsstatus.
  4. Aktualisieren Sie Runbooks mit Aufruftests, Logabfragen, Alarmantwort, Eskalationskontakten, Rollback-Triggern, Rollback-Schritten und der erwarteten Recovery-Zeit.

Stellen Sie sicher, dass Produktionsoperatoren die migrierte Funktion beobachten und Fehler beheben können, bevor der Traffic verschoben wird.

Überlegungen: Eine Migration ist nicht produktionsreif, wenn nur die Funktion funktioniert. Operatoren müssen in der Lage sein, einen ausgefallenen Trigger, ein ausgefallenes Secret, einen Netzwerkpfad oder eine nachgelagerte Abhängigkeit zu erkennen und wiederherzustellen.