Limiti specifici fornitore fattore di riferimento

Mantieni la business logic sostituendo il codice di integrazione specifico di AWS.

Per definire i limiti specifici del provider, effettuare le operazioni riportate di seguito.

1. Estrai la business logic in moduli indipendenti dal fornitore. Aggiungi un parser di eventi AWS solo per la ripetizione di eventi di origine acquisiti durante i test di confronto.
2. Creare un adattatore OCI per il pattern di richiamo della destinazione: richiesta/risposta, CloudEvent, messaggio di coda, record di flusso, evento oggetto, notifica o richiesta di integrazione.
3. Sostituisci le chiamate dirette all'SDK AWS con le interfacce e implementa le chiamate dei servizi OCI dietro tali interfacce. Effettuare le stesse operazioni per configurazione, accesso segreto, log, metriche e riprovare a eseguire la gestione.
4. Ripeti gli eventi Lambda acquisiti e confronta codici di stato, intestazioni, corpi delle risposte, metadati degli oggetti, scritture a valle, effetti collaterali, messaggi di errore e comportamento di idempotenza.

Cerca la business logic da separare dall'analisi degli eventi, dalle chiamate SDK, dalle ipotesi IAM, dalla registrazione, dall'imballaggio e dai nuovi tentativi di gestione.

Considerazioni: evita di riscrivere la logica aziendale contemporaneamente all'integrazione del provider. Cambiare entrambi rende più difficile il test di equivalenza.

Comprendere cosa offre OCI

Identificare i passi di migrazione che utilizzano la configurazione OCI standard e che richiedono codice personalizzato.

Oracle Cloud Infrastructure fornisce servizi per l'esecuzione delle funzioni, la gestione delle API, eventi, code, pianificazione, identità, networking, osservabilità e distribuzione. Tuttavia, la migrazione potrebbe comunque richiedere modifiche specifiche del carico di lavoro, tra cui:

• Conversione dei payload degli eventi AWS nell'input previsto dall'applicazione
• Sostituzione delle chiamate SDK AWS con chiamate SDK OCI
• Ricreazione del comportamento di trigger, nuovi tentativi, ordinamento e errore
• Conversione delle autorizzazioni IAM e dell'accesso di rete
• Aggiornamento delle pipeline CI/CD e delle procedure operative

Prima dell'implementazione, identificare i passi che utilizzano la configurazione OCI standard e che richiedono codice personalizzato. Convalidare tale distinzione utilizzando un carico di lavoro rappresentativo prima di stimare la migrazione più ampia.

Crea package e distribuisci la funzione OCI

Creare la funzione migrata come immagine contenitore e distribuirla in Funzioni OCI.

Per creare un package e distribuire una funzione, effettuare le operazioni riportate di seguito.

1. Creare o aggiornare il progetto di funzione e func.yaml. Impostare memoria e timeout dal funzionamento dell'origine misurato, non dai valori predefiniti.
2. Spostare i contenuti dei livelli Lambda precedenti, le dipendenze native, le dipendenze runtime, i certificati e i pacchetti di sistema nell'immagine o in un'immagine di base condivisa, a seconda dei casi.
3. Traccia le dimensioni dell'immagine, le versioni delle dipendenze, la compatibilità nativa della libreria, il comportamento di avvio, il lavoro di inizializzazione e il comportamento runtime all'interno dell'immagine del contenitore.
4. Crea, esegui il push, distribuisci e richiama la funzione con payload rappresentativi di successo e errore prima di connettere i trigger di produzione.

Verifica che l'immagine crei, esegua il push, distribuisca, richiami e registri l'output previsto senza rivelare segreti.

Considerazioni: il packaging delle dipendenze è spesso il luogo in cui vengono visualizzate le ipotesi Lambda nascoste, in particolare con livelli, librerie native, estensioni e versioni SDK incorporate.

Usa schema di consegna ripetibile

Una migrazione di produzione deve utilizzare un processo di consegna controllato a livello di versione.

Per utilizzare un modello di consegna ripetibile, effettuare le operazioni riportate di seguito.

1. Memorizza insieme codice funzione, configurazione, test e definizioni dell'infrastruttura.
2. Creare ed eseguire il test di un artifact di funzione con controllo delle versioni.
3. Eseguire la scansione dell'artifact e delle relative dipendenze.
4. Promuovere lo stesso artifact testato negli ambienti.
5. Esegui il provisioning o aggiorna le risorse OCI tramite Infrastructure as Code.
6. Eseguire test di fumo e integrazione dopo la distribuzione.
7. Conserva l'artifact di produzione e la configurazione precedenti per il rollback.

Utilizza la piattaforma CI/CD esistente dove possibile. Non richiedere una modifica agli strumenti a meno che non sia necessaria per l'architettura delle funzioni OCI.

Esegui migrazione trigger e integrazioni

Ricreare il comportamento di richiamo richiesto in OCI.

Per eseguire la migrazione di trigger e integrazioni, effettuare le operazioni riportate di seguito.

1. Per i carichi di lavoro HTTP, confrontare autenticazione, metodo, percorso, intestazioni, stringhe di query, schema del corpo, codici di stato, corpo dell'errore, dimensione del payload, timeout, latenza e funzionamento dei nuovi tentativi del chiamante.
2. Per gli eventi oggetto, confrontare lo schema degli eventi, i metadati degli oggetti, lo spazio di nomi, il filtro del bucket e dei prefissi, il funzionamento di creazione/aggiornamento/eliminazione, il funzionamento dei nuovi tentativi, gli eventi duplicati, l'idempotenza e la prevenzione dei loop tra i percorsi di input e di output.
3. Per code e flussi, progettare una gestione esplicita per dimensioni batch, ordini, errori parziali, visibilità o comportamento dei nuovi tentativi, DLQ o destinazione degli errori, messaggi avvelenati, backpressure, duplicati, throughput e ripetizione.
4. Per pianificazioni, notifiche, log e flussi di integrazione, verificare il tipo di richiamo, la latenza, il conteggio dei nuovi tentativi, l'instradamento degli errori, il comportamento della ventola, il filtro e l'osservabilità.

Verificare che ogni trigger disponga di un pattern di destinazione OCI documentato e superare test per scenari normali, non riusciti, di nuovo tentativo e di consegna duplicata.

Considerazioni: non assumere che un mapping di origine evento AWS abbia un sostituto OCI diretto. Conserva il comportamento richiesto, non il nome del controllo AWS.

Modelli di trigger lambda comuni

I seguenti mapping stanno avviando pattern per una migrazione delle funzioni OCI.

Convalidare il comportamento richiesto prima dell'implementazione:

Pattern AWS	Pattern iniziale delle funzioni OCI	Articoli da convalidare
Gateway API per Lambda	Gateway API OCI alle funzioni OCI	Instradamenti, metodi, autenticazione, formati di richiesta e risposta, limiti di payload, timeout, codici di stato e comportamento di errore sincrono
EventBridge per Lambda	Eventi OCI alle funzioni OCI per gli eventi di servizio OCI; utilizzare il servizio di instradamento eventi OCI applicabile per requisiti di instradamento più ampi	Copertura degli eventi, filtri, schemi, comportamento di consegna, nuovi tentativi e requisiti di replica
SQS a Lambda	Oracle Cloud Infrastructure Queue tramite OCI Connector Hub alle funzioni OCI	Dimensione del batch, timeout di visibilità, consegna almeno una volta, ordinazione, gestione dei duplicati, messaggi avvelenati e recupero degli errori
Eventi S3 per Lambda	Eventi di Storage degli oggetti OCI tramite Eventi OCI e Funzioni OCI	Schema evento, filtri, consegna duplicata, autorizzazioni oggetto, comportamento dei nuovi tentativi ed effetti collaterali a valle
Eventi programmati a Lambda	Da OCI Resource Scheduler a funzioni OCI	Espressione di pianificazione, fuso orario, payload di input, timeout, esecuzioni sovrapposte e destinazioni riuscite o non riuscite

Non presumere che i servizi AWS e OCI abbiano lo stesso comportamento. Convalidare il comportamento richiesto da ciascun carico di lavoro prima dell'implementazione.

Conserva comportamento trigger e errore

Documentare ed eseguire il test del funzionamento richiesto per ogni trigger migrato.

Per preservare il comportamento di trigger e errore, effettuare le operazioni riportate di seguito.

1. Documentare ed eseguire il test di quanto riportato di seguito per ogni trigger migrato.
   • Indica se la consegna è sincrona o asincrona
   • Riprova proprietario, intervallo nuovi tentativi e numero massimo tentativi
   • Garanzie di consegna e possibili eventi duplicati
   • Requisiti per l'ordine
   • Comportamento idempotenza
   • Comportamento batch e errori parziali
   • Timeout visibilità o comportamento di conferma
   • Gestione dei messaggi avvelenati
   • Destinazione errore o lettera morta
   • Procedura di ripetizione e recupero
2. Non presumere che servizi AWS e OCI simili abbiano un comportamento di consegna o errore identico.
3. Quando è possibile effettuare consegne duplicate, progettare la funzione per elaborare eventi ripetuti in modo sicuro.

Per i richiami delle funzioni OCI scollegati, è possibile inviare record di operazioni riuscite e non riuscite alle destinazioni OCI Queue, OCI Streaming o OCI Notifications. Questo comportamento è specifico per i richiami scollegati e non deve essere descritto come un sostituto universale per ogni pattern di coda di lettere morte AWS.

Configurare IAM, segreti e networking

Traduci il comportamento runtime in accesso OCI con meno privilegi e raggiungibilità di rete approvata.

Per configurare OCI Identity and Access Management (IAM), segreti e networking, effettuare le operazioni riportate di seguito.

1. Eseguire il mapping di ogni azione di origine a un'azione, a una risorsa e a un compartimento OCI. Evita politiche estese a meno che il carico di lavoro non lo richieda e i revisori non approvino.
2. Utilizza gruppi dinamici e principal risorsa per l'accesso runtime alle risorse OCI. Eseguire il test dei percorsi consentiti e rifiutati, inclusi il compartimento errato, il bucket errato, il segreto errato e i casi criteri mancanti.
3. Sposta i segreti in OCI Vault o in un pattern approvato. Confermare che non vengano visualizzati valori segreti in codice sorgente, immagini, log, dump di ambiente, output CI, stack trace o messaggi di errore.
4. Convalidare le regole di instradamento, le regole di sicurezza, il comportamento del gateway di servizio o NAT, gli endpoint privati, il DNS, l'affidabilità TLS, le liste di inclusione esterne e i limiti di connessione a valle.

Verifica che le chiamate di servizio consentite abbiano esito positivo, i percorsi negati non riescano e che i percorsi di rete necessari siano raggiungibili senza esporre percorsi non autorizzati.

Considerazioni: la traduzione di IAM dovrebbe iniziare dal comportamento runtime osservato, non dai nomi dei criteri AWS o dai criteri gestiti a livello generale.

Ricrea osservabilità e operazioni

Assicurati che i proprietari della produzione possano rilevare, diagnosticare e recuperare dagli errori.

Per ricreare osservabilità e operazioni, effettuare le operazioni riportate di seguito.

1. Emettere i log con l'ID correlazione, l'ID richiesta, l'ID trigger, l'identificativo oggetto o messaggio, lo stato, la durata, il conteggio dei nuovi tentativi, i dettagli degli errori sanificati e i risultati delle dipendenze a valle.
2. Confermare le metriche e gli allarmi per il conteggio dei richiami, la durata, la frequenza degli errori, il conteggio dei timeout, i sintomi di limitazione o capacità, il conteggio DLQ o degli errori, la durata o il backlog della coda, i risultati di consegna scollegati e gli errori a valle.
3. Crea dashboard o viste approvate per integrità, latenza, errori, capacità, trigger di backlog e stato di dipendenza.
4. Aggiorna i runbook con i test di richiamo, le query di log, la risposta all'allarme, i contatti di escalation, il trigger di rollback, i passi di rollback e il tempo di recupero previsto.

Verificare che gli operatori di produzione possano osservare e risolvere i problemi della funzione migrata prima dello spostamento del traffico.

Considerazioni: una migrazione non è pronta per la produzione se solo la funzione funziona. Gli operatori devono essere in grado di rilevare e recuperare da un trigger, un segreto, un percorso di rete o una dipendenza a valle non riuscita.