Informazioni sulla migrazione dei carichi di lavoro AWS Lambda alle funzioni OCI
Una migrazione di successo richiede molto di più dello spostamento del codice tra piattaforme. OCI Functions è l'obiettivo predefinito per le iniziative di migrazione AWS Lambda. Prima di selezionare le funzioni OCI come destinazione, identificare la modalità di richiamo di ogni funzione, i servizi con cui interagisce, i comportamenti operativi su cui si basa e i comportamenti da preservare.
Questo inventario include la raccolta del tipo di trigger, la durata massima, l'uso della memoria, le dimensioni del payload, la concorrenza, il comportamento di nuovi tentativi e errori, le dipendenze, le autorizzazioni IAM, i percorsi di rete, la registrazione, il monitoraggio e le aspettative di recupero. Queste caratteristiche determinano se le funzioni OCI o un altro servizio OCI sono la destinazione migliore.
Durante la valutazione, verificare che i requisiti di richiamo, payload, timeout, memoria, concorrenza, networking, dipendenza e integrazione del carico di lavoro possano essere supportati dalle funzioni OCI.
Se le funzioni OCI non soddisfano un requisito documentato, sospendere la migrazione e completare la revisione delle eccezioni prima di proporre un'architettura non funzionante. L'eccezione deve includere il vincolo tecnico, il modello di costo totale rivisto, lo sforzo di migrazione, l'impatto operativo e l'approvazione esplicita dell'approccio rivisto.
Cosa farai
- Crea un inventario basato su prove di configurazione Lambda, trigger, dipendenze, autorizzazioni, traffico, errori e segnali operativi.
- Confronta il funzionamento dell'origine con i limiti delle funzioni OCI, le modalità di richiamo, i pattern di trigger, la sicurezza, il packaging delle dipendenze, il networking e l'osservabilità.
- Separa la business logic portatile dall'analisi degli eventi, dall'identità, dalle chiamate SDK, dal package di distribuzione, dalla registrazione, dai segreti, dai nuovi tentativi e dal codice operativo specifici del provider.
- Distribuire la funzione come immagine del contenitore delle funzioni OCI e convalidare output, errori, effetti collaterali, latenza, capacità, nuovi tentativi, sicurezza, osservabilità e disponibilità del rollback prima del cutover.
Come utilizzare questo Playbook
Per una grande tenuta Lambda, non iniziare valutando manualmente ogni funzione. Inizia con un esempio rappresentativo che copre i runtime principali, i trigger, le dipendenze, i profili di traffico e i livelli di business-criticality.
Utilizzare il campione per:
- Confermare l'approccio alla migrazione di OCI Functions per carichi di lavoro rappresentativi.
- Identifica gli adattatori necessari e le modifiche di codice mirate.
- Identifica le modifiche necessarie a livello di sicurezza, rete, implementazione e operativo.
- Stima lo sforzo di migrazione, il rischio e i pattern riutilizzabili.
- Selezionare i carichi di lavoro rappresentativi per un progetto pilota di migrazione di lavoro.
Non converte automaticamente il codice Lambda né genera tutte le integrazioni necessarie.
Architettura
Inventa prima la funzione Lambda, i suoi trigger e il suo comportamento operativo. Quindi isola la business logic portatile dagli adattatori specifici del provider. L'implementazione di destinazione viene eseguita in un'applicazione OCI Functions, viene distribuita da un'immagine contenitore memorizzata in Container Registry, utilizza IAM OCI e principal risorsa per l'accesso in runtime, recupera i segreti da un'area di memorizzazione segreta approvata, ad esempio OCI Vault, ed emette segnali operativi tramite OCI Logging, monitoraggio, allarmi e APM, ove necessario.
Mappa delle relazioni tra AWS Lambda e OCI Functions
Vista raggruppata dell'envelope del carico di lavoro per ricreare le funzioni OCI

Descrizione dell'illustrazione migrate-lambda-functions-arch.png
migrare-lambda-funzioni-arch-oracle.zip#GUID-B6E215FE-1619-4CDD-B055-0194D46ADBF8
Principi di architettura
- Valuta prima, quindi migra. I trigger, i payload, i nuovi tentativi, i livelli, le autorizzazioni, il networking e il comportamento operativo possono essere diversi.
- Considera migrazione trigger come migrazione del comportamento. Confronta la forma dell'evento, l'autenticazione, i nuovi tentativi, l'ordinazione, l'assemblaggio in batch, la consegna duplicata, i filtri, le destinazioni senza lettere o errori e la gestione dei messaggi avvelenati.
- Misurare il carico di lavoro di origine. Acquisisci la frequenza di richiamo, il picco di concorrenza, i percentili di durata, la durata massima, l'uso della memoria, i percorsi sensibili all'avvio a freddo, le dimensioni del payload, la velocità di errore, la frequenza di limitazione, il DLQ o il conteggio degli errori, il backlog e i limiti a valle.
- Mantieni portatile la business logic. Isolare gli adattatori per l'analisi degli eventi, l'identità, le chiamate SDK, l'accesso agli oggetti o ai messaggi, il log, la configurazione, i segreti e il funzionamento dei nuovi tentativi.
- Rendi le operazioni parte della migrazione. Prima del cutover devono esistere log, metriche, allarmi, dashboard, trace, runbook, trigger di rollback e test degli errori.
Componenti di base
L'architettura in genere include il carico di lavoro Lambda di origine, un record di migrazione, un livello di richiamo OCI, l'applicazione e l'immagine OCI Functions e i servizi di sicurezza, networking e operations di supporto. Considera l'origine come prova, non come un progetto diretto; scegli i componenti OCI dal comportamento richiesto e dai risultati della convalida.
Concetti equivalenti AWS Lambda e OCI
Questa chiave è intesa come una guida alla traduzione, non come una promessa di equivalenza uno-a-uno. Per ogni riga, confronta il comportamento di origine con il comportamento OCI di destinazione e conserva le prove nel record di migrazione.
| Concetto AWS Lambda | Concetto o pattern OCI | Cosa confrontare o convalidare |
|---|---|---|
| Funzione e gestore | Funzioni OCI con handler Fn FDK | Runtime, architettura, punto di ingresso handler, parser eventi, oggetto di risposta, comportamento degli errori, percorso di test locale e supporto libreria specifico del runtime. |
| Pacchetto ZIP, livelli, estensioni | Immagine contenitore o immagine base condivisa | Versioni delle dipendenze, librerie native, dimensione dell'immagine, comportamento di avvio, comportamento delle estensioni, ipotesi SDK incorporate e se le dipendenze devono essere condivise tra le funzioni. |
| Criteri relativi a ruoli e risorse di esecuzione | Criteri di OCI Identity and Access Management (IAM), gruppi dinamici e principal risorse | Azioni di runtime, ambito del compartimento e delle risorse, accesso tra account o compartimenti, letture dei segreti, accesso agli oggetti o alle code e test del percorso negato. |
| Gateway API e Lambda | Gateway API OCI più Funzioni OCI | Autenticazione, instradamento e metodo, intestazioni, stringhe di query, schema del corpo, codici di stato, intestazioni di risposta, timeout, dimensione del payload, latenza e corpo dell'errore. |
| Eventi oggetto S3 | Eventi di storage degli oggetti OCI attraverso gli eventi OCI | Schema evento, metadati oggetto, spazio di nomi, filtri bucket e prefissi, funzionamento di creazione/aggiornamento/eliminazione, nuovi tentativi, duplicati, idempotenza e prevenzione del loop di input/output. |
| SQS, stream, SNS, EventBridge, sottoscrizioni ai log | OCI Queue, OCI Streaming, Notifiche OCI, Eventi OCI, OCI Connector Hub o flusso riprogettato | Dimensione batch, ordinazione, nuovo tentativo, errore parziale, destinazione lettera morta o errore, visibilità o nuovi tentativi di finestre, backpressure, messaggi avvelenati, fanout, filtri e consegna duplicata. |
| Richiamo sincrono o asincrono | Sincronizza o scollega richiamo | Semantica di risposta del chiamante, gestione dei risultati, timeout di richiamo, timeout di esecuzione, gestione del completamento scollegato, destinazione di operazione riuscita/non riuscita e percorso di nuovo tentativo. |
| Memoria, timeout, payload, ipotesi effimere | Impostazioni di memoria, timeout, richiesta, risposta, immagine e runtime delle funzioni OCI | p95/p99 e durata massima, conteggio timeout, headroom di memoria, dimensioni payload richieste/risposte, ipotesi di storage temporaneo, progettazione di riduzione del carico a pagamento di grandi dimensioni e tempo di caricamento delle dipendenze. |
| Concorrenza riservata/provisioning e ridimensionamento dell'origine evento | Limiti del servizio OCI, concorrenza delle applicazioni, concorrenza con provisioning eseguito, controlli dei trigger e protezione a valle | Concorrenza corrente e di picco, sensibilità all'avvio a freddo, limitazioni o 429, durata della coda o backlog, tempeste di nuovo tentativo, limiti di capacità a valle e se l'impostazione dell'origine riserva capacità, limita il traffico o riduce la latenza. |
| CloudWatch: log, metriche, allarmi, raggi X | Log OCI, Monitoraggio OCI, allarmi, dashboard e Oracle Application Performance Monitoring (APM) dove necessario | Campi di log obbligatori, ID correlazione, conteggio richiami, durata, tasso di errore, conteggio timeout, soglie di allarme, trace, dashboard, runbook e proprietà delle risposte agli incidenti. |
| Gestione segreti, archivio parametri, KMS, rete VPC | Vault OCI, chiavi, VCN, subnet, gateway, endpoint privati, DNS e regole di sicurezza | Rotazione segreta, controlli delle perdite, regole di instradamento, uscita, DNS, liste di inclusione, accesso privato, blocco del percorso non autorizzato e limiti di connessione a valle. |