Inventario del carico di lavoro Lambda

Creare un record di migrazione con prove sufficienti per riprodurre e confrontare il funzionamento dell'origine.

Per inventariare il carico di lavoro lambda, effettuare le operazioni riportate di seguito.

Registra la configurazione, il percorso di distribuzione, le dipendenze, i livelli, le librerie native, le variabili di ambiente, le impostazioni VPC, il ruolo IAM, i trigger, il proprietario e i contatti operativi.
Acquisisci le metriche della baseline: frequenza di richiamo, concorrenza massima, durata p95 e p99, durata massima, memoria utilizzata, dimensioni del payload, errori, timeout, limitazioni, nuovi tentativi, conteggio DLQ o errori, durata della coda o backlog, soglie di allarme e limiti di capacità a valle.
Salvare gli eventi di operazione riuscita rappresentativi, gli eventi con formato errato, gli eventi duplicati, i casi di timeout, gli errori di autorizzazione, i campioni di errore a valle e gli esempi di log di origine con valori riservati protetti.

Cerca: un record di inventario completo con collegamenti di prova, note di rischio iniziali e lacune che richiedono la conferma del proprietario.

Output: non fare affidamento solo sulle esportazioni di configurazione. I log, le metriche, gli allarmi e gli eventi rappresentativi in genere rivelano un comportamento che la sola configurazione non mostra.

Valutare ogni funzione campionata per la migrazione delle funzioni OCI

Registrare i requisiti, le modifiche necessarie e la decisione di migrazione per ogni funzione campionata.

Per valutare ciascuna funzione campionata per la migrazione delle funzioni OCI, completare un record di valutazione con i seguenti elementi per ciascuna funzione campionata:

Nome funzione e proprietario applicazione
Scopo aziendale e criticità
Runtime e versione
Formato evento trigger e in entrata
Servizi AWS e chiamate SDK utilizzate
Tempo di esecuzione, memoria, concorrenza e dimensione del payload
Riprova, ordina, duplica la consegna e il comportamento degli errori
Autorizzazioni IAM e dipendenze di rete
Log, metriche, allarmi e obiettivi a livello di servizio correnti
Configurazione e pattern trigger obbligatori delle funzioni OCI
Modifiche richieste a codice, adattatore o distribuzione
Lacune note e rischi non risolti

Utilizzare uno dei seguenti risultati della valutazione:

Migrazione delle funzioni OCI pronta: il carico di lavoro può passare alle funzioni OCI con modifiche limitate.
Migrazione delle funzioni OCI con modifiche: il carico di lavoro richiede un adattatore, modifiche mirate al codice, modifiche alla configurazione o modifiche operative.
È richiesta la revisione delle eccezioni: le funzioni OCI potrebbero non soddisfare un requisito documentato del carico di lavoro. Non procedere con un'architettura non Functions senza la revisione delle eccezioni descritta in questo playbook.

Il proprietario dell'applicazione e il proprietario della migrazione devono rivedere la valutazione prima dell'inizio dell'implementazione.

Valutare i requisiti di migrazione delle funzioni OCI

Determinare l'approccio di migrazione alle funzioni OCI per un carico di lavoro.

Per valutare i requisiti di migrazione delle funzioni OCI, effettuare le operazioni riportate di seguito.

Esaminare i requisiti di trigger, runtime, dipendenze, durata dell'esecuzione, memoria, concorrenza, payload, IAM, networking e operativi del carico di lavoro per determinare l'approccio alla migrazione delle funzioni OCI.
Separa la business logic portatile dall'analisi degli eventi specifica di AWS, dalle chiamate SDK, dalle ipotesi IAM, dal log e dai nuovi tentativi di gestione.

Ciò rende visibili le modifiche alla migrazione necessarie prima dell'inizio dell'implementazione.

Utilizzare i seguenti pattern di migrazione delle funzioni OCI come punto di partenza.

Pattern del carico di lavoro	Pattern di migrazione delle funzioni OCI	Convalida
Carico di lavoro senza conservazione dello stato, basato sugli eventi e con esecuzione breve	Funzioni OCI	Payload, memoria, timeout, concorrenza, dipendenze e accesso a valle richiesto
Carico di lavoro API HTTP	Gateway API OCI più Funzioni OCI	Autenticazione, metodi, instradamenti, intestazioni, dimensione del payload, risposte agli errori, latenza e timeout
Processore di oggetti, notifiche, code, flussi o eventi di log	Funzioni OCI con gli eventi OCI, Oracle Cloud Infrastructure Queue, Notifiche OCI, OCI Streaming o il servizio OCI Connector Hub applicabili	Formato dell'evento, comportamento di consegna, nuovi tentativi, ordinazione, gestione dei duplicati, destinazione degli errori e backpressure

OCI Functions è l'obiettivo predefinito per le iniziative di migrazione Lambda quando soddisfa i requisiti funzionali, di performance, di sicurezza e operativi del carico di lavoro.

Progettare l'architettura OCI di destinazione

Definisci pattern di richiamo, identità, segreto, rete, dipendenza, osservabilità e cutover.

Per progettare l'architettura OCI di destinazione, effettuare le operazioni riportate di seguito.

Selezionare il percorso di richiamo e l'autenticazione prevista del documento, la forma del payload, le intestazioni o i metadati, la latenza, i nuovi tentativi, l'ordinazione, il funzionamento in batch, la consegna duplicata, il filtro e la destinazione degli errori.
Definire l'applicazione OCI Functions, il compartimento, il repository di immagini, la VCN, le subnet, le tabelle di instradamento, le regole di sicurezza, il gateway di servizio o il gateway NAT, l'accesso privato, i requisiti di uscita e gli endpoint a valle.
Identificare ogni servizio OCI o endpoint esterno che la funzione chiama in fase di esecuzione, tra cui OCI Object Storage, OCI Queue, OCI Streaming, OCI Vault, database e API di terze parti.
Definire i segnali operativi quali i campi di log, l'ID correlazione, il conteggio dei richiami, la durata, gli errori, i timeout, i sintomi di capacità, gli errori a valle, le viste dashboard, gli allarmi e i passi del runbook.

Cercare un riepilogo dell'architettura di destinazione con l'elenco dei componenti, il percorso di integrazione, la progettazione della sicurezza, la progettazione operativa e la guida alla ridisposizione del diagramma.

Considerazioni: la progettazione dell'architettura è completa solo quando vengono descritti il flusso normale, il flusso di nuovi tentativi, il flusso di errori, il flusso con accesso negato e il flusso di rollback.

Considerazioni sulla progettazione e selezione della destinazione

Utilizzare queste considerazioni durante la revisione della progettazione.

Sono intenzionalmente orientati all'azione in modo che i revisori possano chiedere prove piuttosto che accettare dichiarazioni generali di prontezza.

Adattamento target: utilizzare le funzioni OCI per un lavoro senza conservazione dello stato, basato su eventi, con tempi di esecuzione brevi e containerizzabile che si adatta ai limiti di destinazione e al modello di richiamo. Utilizza un altro target per carichi di lavoro a lungo termine, con conservazione dello stato, simili a daemon, impegnativi per l'orchestrazione, simili a lavoratori o abbinati a servizi AWS.
Payload e timeout: registra le dimensioni effettive delle richieste e delle risposte, la durata massima, il conteggio dei timeout e la semantica delle risposte del chiamante. Consente di passare dati di grandi dimensioni per riferimento tramite OCI Object Storage, OCI Queue, OCI Streaming o un'altra area di memorizzazione anziché tramite il payload della funzione.
Dipendenze: converte le ipotesi dei livelli ZIP e Lambda in dipendenze immagine o immagine di base condivisa. Testare le librerie native, le dimensioni delle immagini, le versioni delle dipendenze, il comportamento di avvio, le ipotesi SDK incorporate e il comportamento runtime.
Valuta e scalabilità: spiega perché è stata utilizzata la concorrenza riservata o di cui è stato eseguito il provisioning di AWS: capacità riservata, limite di traffico, riduzione dell'avvio a freddo, limitazione dell'origine degli eventi o protezione a valle. Progetta il comportamento OCI con la pianificazione della capacità, il provisioning della concorrenza, se necessario, attiva controlli, pressione arretrata e limiti a valle.
Trigger: convalida la forma dell'evento, nuovi tentativi, ordinamento, funzionamento del batch, consegna duplicata, filtro, destinazione degli errori e idempotenza. Il comportamento del trigger è in genere l'area di migrazione a rischio più elevato.
Operazioni: tratta log, metriche, allarmi, dashboard, trace, runbook, trigger di rollback e proprietario del rollback come adempimenti alla migrazione, non dopo il cleanup del cutover.

Guida alla selezione target

Caratteristica del carico di lavoro	Destinazione OCI consigliata	Perché
Funzione stateless, event-driven, short-running, containerizzabile	Funzioni OCI	Si adatta meglio quando vengono soddisfatti i vincoli di payload, timeout, memoria, trigger, dipendenza, networking e concorrenza.
Funzione API HTTP con funzionamento semplice di richiesta/risposta	Gateway API OCI più Funzioni OCI	Adatta quando vengono convalidate l'autenticazione, le intestazioni, la dimensione del payload, il timeout, la latenza, il codice di stato e la semantica della risposta.
Processore di oggetti, notifiche, code, flussi o eventi di log	Funzioni OCI con Eventi OCI, Notifiche OCI, Hub connettore OCI, Streaming OCI tramite Hub connettore o flusso di messaggistica riprogettato	Eventuale adattamento, ma consegna, nuovo tentativo, ordine, batch, duplicato, messaggio di veleno e comportamento di errore devono essere riprogettati e testati.
Processo a lungo termine o simile a un lavoratore	Istanze contenitore OCI, OKE, OCI Compute o workflow scomposto	Evita i vincoli di richiamo delle funzioni e runtime, preservando al contempo un percorso di distribuzione basato su container o servizi.
Orchestrazione pesante per l'integrazione	Oracle Integration, servizio del flusso di lavoro o riprogettazione	Si adatta meglio quando il carico di lavoro coordina i sistemi, attende lo stato esterno o gestisce i passi di compensazione anziché eseguire una piccola unità di computazione.
Processo con conservazione dello stato, stato permanente locale o daemon	OCI Compute, OKE o riprogettazione	OCI Functions non è un modello permanente di esecuzione dello stato locale o del daemon.

Preparare le risorse OCI e l'accesso alla distribuzione

Prepara l'ambiente di destinazione minimo necessario per creare, distribuire e sottoporre a test antifumo.

Per preparare le risorse OCI e l'accesso alla distribuzione, effettuare le operazioni riportate di seguito.

Creare o identificare il compartimento, l'applicazione Funzioni OCI, le subnet VCN, il repository del registro dei container OCI, le posizioni segrete del Vault OCI, le risorse di log e gli allarmi di monitoraggio.
Configura l'accesso per sviluppatori e CI/CD per la creazione di immagini, il push di immagini, l'implementazione di funzioni, il richiamo di test di fumo e la lettura dei log.
Creare regole dei gruppi dinamici e istruzioni dei criteri per l'accesso runtime. Ambito per compartimento e risorsa, se possibile, in particolare per bucket, flussi, code, segreti di OCI Vault e database.
Smoke-test image push, function deploy, richiamo diretto, emissione di log, lettura segreta, lettura segreta negata e una chiamata di servizio a valle rappresentativa.

Cercare un ambiente di destinazione pronto con percorsi di accesso documentati e un test di fumo superato.

Considerazioni: assicurarsi che l'identità di distribuzione e l'identità runtime siano separate quando il processo richiede autorizzazioni diverse.