Migrazione da AWS a Google Cloud: migrazione da AWS Lambda a Cloud Run

Last reviewed 2025-12-31 UTC

Google Cloud fornisce strumenti, prodotti, indicazioni e servizi professionali per facilitare la migrazione dei workload serverless da Amazon Web Services (AWS) Lambda a Google Cloud. Sebbene Google Cloud fornisca diversi servizi su cui puoi sviluppare ed eseguire il deployment di applicazioni serverless, questo documento si concentra sulla migrazione a Cloud Run, un ambiente di runtime serverless. Sia AWS Lambda che Cloud Run condividono similitudini come il provisioning automatico delle risorse, la scalabilità da parte del cloud provider e un modello di prezzi con pagamento a consumo.

Questo documento ti aiuta a progettare, implementare e convalidare un piano per la migrazione dei workload serverless da AWS Lambda a Cloud Run. Inoltre, offre indicazioni per chi sta valutando i potenziali vantaggi e il processo di una migrazione di questo tipo.

Questo documento fa parte di una serie in più parti sulla migrazione da AWS aGoogle Cloud che include i seguenti documenti:

Per saperne di più sulla scelta dell'ambiente di runtime serverless giusto per la tua logica di business, consulta Seleziona un ambiente di runtime per container gestito. Per una mappatura completa tra i servizi AWS e Google Cloud , consulta Confronta i servizi AWS e Azure con i servizi Google Cloud .

Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto in Esegui la migrazione a Google Cloud: inizia.

Il seguente diagramma illustra il percorso di migrazione.

Percorso di migrazione con quattro fasi.

Potresti eseguire la migrazione dal tuo ambiente di origine a Google Cloud in una serie di iterazioni, ad esempio eseguendo prima la migrazione di alcuni workload e poi di altri. Per ogni singola iterazione della migrazione, segui le fasi del framework di migrazione generale:

  1. Valuta e scopri i tuoi workload e i tuoi dati.
  2. Pianifica e crea una base su Google Cloud.
  3. Esegui la migrazione dei tuoi workload e dei tuoi dati su Google Cloud.
  4. Ottimizza il tuo ambiente Google Cloud .

Per ulteriori informazioni sulle fasi di questo framework, consulta Esegui la migrazione a Google Cloud: inizia.

Per progettare un piano di migrazione efficace, ti consigliamo di convalidare ogni passaggio del piano e di assicurarti di avere una strategia di rollback. Per convalidare il tuo piano di migrazione, consulta Esegui la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

La migrazione dei workload serverless spesso va oltre il semplice spostamento delle funzioni da un cloud provider a un altro. Poiché le applicazioni basate su cloud si basano su una rete di servizi interconnessi, la migrazione da AWS a Google Cloud potrebbe richiedere la sostituzione dei servizi AWS dipendenti con i servizi Google Cloud . Ad esempio, considera uno scenario in cui la tua funzione Lambda interagisce con Amazon SQS e Amazon SNS. Per eseguire la migrazione di questa funzione, probabilmente dovrai adottare Pub/Sub e Cloud Tasks per ottenere funzionalità simili.

La migrazione rappresenta anche una preziosa opportunità per esaminare attentamente l'architettura e le decisioni di progettazione della tua applicazione serverless. Durante questa revisione, potresti scoprire opportunità per:

  • Ottimizza con le Google Cloud funzionalità integrate: scopri se i serviziGoogle Cloud offrono vantaggi unici o si allineano meglio ai requisiti della tua applicazione.
  • Semplifica l'architettura: valuta se è possibile semplificare consolidando le funzionalità o utilizzando i servizi in modo diverso all'interno diGoogle Cloud.
  • Migliora l'efficienza dei costi: valuta le potenziali differenze di costo dell'esecuzione dell'applicazione rifattorizzata sull'infrastruttura fornita su Google Cloud.
  • Migliora l'efficienza del codice: rifattorizza il codice insieme al processo di migrazione.

Pianifica la tua strategia di migrazione. Non considerare la migrazione come un esercizio di rehosting (lift and shift). Utilizza la migrazione come un'opportunità per migliorare la progettazione complessiva e la qualità del codice della tua applicazione serverless.

Valuta l'ambiente di origine

Nella fase di valutazione, determini i requisiti e le dipendenze per eseguire la migrazione dell'ambiente di origine a Google Cloud.

La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire una conoscenza approfondita dei workload di cui vuoi eseguire la migrazione, dei loro requisiti, delle loro dipendenze e del tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire correttamente una migrazione a Google Cloud.

La fase di valutazione prevede le seguenti attività:

  1. Crea un inventario completo dei tuoi workload.
  2. Cataloga i workload in base alle loro proprietà e dipendenze.
  3. Forma e istruisci i tuoi team su Google Cloud.
  4. Crea esperimenti e proof of concept su Google Cloud.
  5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
  6. Scegli la strategia di migrazione per i tuoi workload.
  7. Scegli gli strumenti di migrazione.
  8. Definisci il piano e la cronologia della migrazione.
  9. Convalida il piano di migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Esegui la migrazione a Google Cloud: valuta e scopri i tuoi workload. Le sezioni seguenti si basano sulle informazioni contenute in questo documento.

Crea un inventario dei tuoi workload AWS Lambda

Per definire l'ambito della migrazione, crea un inventario e raccogli informazioni sui tuoi workload AWS Lambda.

Per creare l'inventario dei workload AWS Lambda, ti consigliamo di procedere come segue:

  1. Per rilevare gli asset AWS Lambda, utilizza Migration Center. Migration Center è la piattaforma unificata diGoogle Cloudche ti consente di accelerare il tuo Cloud Journey end-to-end dall'ambiente attuale a Google Cloud.

  2. Per perfezionare l'inventario dei workload AWS Lambda, utilizza l'interfaccia a riga di comando (CLI) di AWS. Ad esempio, puoi utilizzare l'interfaccia a riga di comando di AWS per ottenere un elenco delle funzioni AWS Lambda. Poi, per ogni funzione, recupera i dettagli di configurazione e i trigger.

  3. Per esaminare i log e le durate delle chiamate AWS Lambda recenti, le esecuzioni contemporanee e gli errori, utilizza CloudWatch. CloudWatch fornisce diversi tipi di metriche per AWS Lambda. Per ulteriori informazioni sulla visualizzazione delle metriche di AWS Lambda, consulta Visualizzazione delle metriche per le funzioni AWS Lambda.

  4. Per valutare l'inventario dei workload AWS Lambda, utilizza Gemini CLI. Ad esempio, puoi aggiungere i file di inventario che elencano i workload AWS Lambda al contesto di Gemini CLI e poi chiedere a Gemini di aiutarti a valutare questi oggetti. Per saperne di più, consulta Migrazioni a Google Cloud basate su Gemini.

Dopo aver creato l'inventario, ti consigliamo di raccogliere informazioni su ogni workload AWS Lambda nell'inventario. Per ogni workload, concentrati sugli aspetti che ti aiutano ad anticipare potenziali attriti. Inoltre, analizza il workload per capire come potrebbe essere necessario modificarlo e le sue dipendenze prima di eseguire la migrazione a Cloud Run. Ti consigliamo di iniziare raccogliendo dati sui seguenti aspetti di ogni workload AWS Lambda:

  • Il caso d'uso e il design
  • Il repository di codice sorgente
  • Gli artefatti di deployment
  • La chiamata, i trigger e gli output
  • Ambienti di runtime ed esecuzione
  • La configurazione del workload
  • I controlli degli accessi e le autorizzazioni
  • I requisiti normativi e di conformità
  • I processi di deployment e operativi

Caso d'uso e design

La raccolta di informazioni sul caso d'uso e sulla progettazione dei workload aiuta a identificare una strategia di migrazione adeguata. Queste informazioni ti aiutano anche a capire se devi modificare i workload e le relative dipendenze prima della migrazione. Per ogni workload, ti consigliamo di procedere come segue:

  • Ottieni insight sul caso d'uso specifico per cui viene utilizzato il workload e identifica eventuali dipendenze con altri sistemi, risorse o processi.
  • Analizza il design e l'architettura del workload.
  • Valuta i requisiti di latenza del workload.

Repository di codice sorgente

L'inventario del codice sorgente delle funzioni AWS Lambda è utile se devi rifattorizzare i workload AWS Lambda per renderli compatibili con Cloud Run. La creazione di questo inventario comporta il monitoraggio del codebase, che in genere viene archiviato in sistemi di controllo della versione come Git o in piattaforme di sviluppo come GitHub o GitLab. L'inventario del codice sorgente è essenziale per i processi DevOps, come le pipeline di integrazione continua e sviluppo continuo (CI/CD), perché anche questi processi dovranno essere aggiornati quando esegui la migrazione a Cloud Run.

Artefatti di deployment

Sapere quali artefatti di deployment sono necessari per il workload è un altro elemento che ti aiuta a capire se potrebbe essere necessario rifattorizzare i workload AWS Lambda. Per identificare gli artefatti di deployment necessari per il workload, raccogli le seguenti informazioni:

  • Il tipo di pacchetto di deployment per eseguire il deployment del workload.
  • Qualsiasi livello AWS Lambda che contiene codice aggiuntivo, come librerie e altre dipendenze.
  • Eventuali estensioni AWS Lambda da cui dipende il workload.
  • I qualificatori che hai configurato per specificare versioni e alias.
  • La versione del workload di cui è stato eseguito il deployment.

Chiamata, trigger e output

AWS Lambda supporta diversi meccanismi di chiamata, come i trigger, e diversi modelli di chiamata, come la chiamata sincrona e la chiamata asincrona. Per ogni workload AWS Lambda, ti consigliamo di raccogliere le seguenti informazioni relative ad attivatori e chiamate:

  • I trigger e le mappature delle origini eventi che richiamano il workload.
  • Se il workload supporta chiamate sincrone e asincrone.
  • Gli URL dei workload e gli endpoint HTTP(S).

I tuoi workload AWS Lambda possono interagire con altre risorse e sistemi. Devi sapere quali risorse utilizzano gli output dei tuoi workload AWS Lambda e in che modo. Queste informazioni ti aiutano a determinare se devi modificare qualcosa che potrebbe dipendere da questi output, ad esempio altri sistemi o workload. Per ogni workload AWS Lambda, ti consigliamo di raccogliere le seguenti informazioni su altre risorse e sistemi:

  • Le risorse di destinazione a cui il workload potrebbe inviare eventi.
  • Le destinazioni che ricevono i record di informazioni per le chiamate asincrone.
  • Il formato degli eventi elaborati dal workload.
  • Come il tuo workload AWS Lambda e le relative estensioni interagiscono con le API AWS Lambda o altre API AWS.

Per funzionare, i workload AWS Lambda potrebbero archiviare dati persistenti e interagire con altri servizi AWS. Per ogni workload AWS Lambda, ti consigliamo di raccogliere le seguenti informazioni su dati e altri servizi:

  • Se il workload accede a virtual private cloud (VPC) o ad altre reti private.
  • In che modo il workload archivia i dati persistenti, ad esempio utilizzando l'archiviazione temporanea dei dati e Amazon Elastic File System (EFS).

Ambienti di runtime ed esecuzione

AWS Lambda supporta diversi ambienti di esecuzione per i tuoi workload. Per mappare correttamente gli ambienti di esecuzione di AWS Lambda agli ambienti di esecuzione di Cloud Run, ti consigliamo di valutare quanto segue per ogni workload AWS Lambda:

  • L'ambiente di esecuzione del workload.
  • L'architettura del set di istruzioni del processore del computer su cui viene eseguito il workload.

Se i tuoi workload AWS Lambda vengono eseguiti in ambienti di runtime specifici per il linguaggio, considera quanto segue per ogni workload AWS Lambda:

  • Il tipo, la versione e l'identificatore univoco dell'ambiente di runtime specifico per il linguaggio.
  • Eventuali modifiche applicate all'ambiente di runtime.

Configurazione del workload

Per configurare i workload durante la migrazione da AWS Lambda a Cloud Run, ti consigliamo di valutare come hai configurato ogni workload AWS Lambda.

Per ogni workload AWS Lambda, raccogli informazioni sulle seguenti impostazioni di contemporaneità e scalabilità:

  • I controlli della concorrenza.
  • Le impostazioni di scalabilità.
  • La configurazione delle istanze del workload, in termini di quantità di memoria disponibile e tempo di esecuzione massimo consentito.
  • Se il workload utilizza AWS Lambda SnapStart, la contemporaneità riservata o la contemporaneità di cui è stato eseguito il provisioning per ridurre la latenza.
  • Le variabili di ambiente che hai configurato, nonché quelle configurate da AWS Lambda e da cui dipende il workload.
  • I tag e controllo dell'accesso basato sugli attributi.
  • La macchina a stati per gestire le condizioni eccezionali.
  • Le immagini di base e i file di configurazione (come il Dockerfile) per i pacchetti di deployment che utilizzano immagini container.

Controlli degli accessi e autorizzazioni

Nell'ambito della valutazione, ti consigliamo di valutare i requisiti di sicurezza dei tuoi workload AWS Lambda e la loro configurazione in termini di controlli e gestione degli accessi. Queste informazioni sono fondamentali se devi implementare controlli simili nel tuo ambiente Google Cloud . Per ogni workload, considera quanto segue:

  • Il ruolo e le autorizzazioni di esecuzione.
  • La configurazione di Identity and Access Management utilizzata dal workload e dai suoi livelli per accedere ad altre risorse.
  • La configurazione di Identity and Access Management utilizzata da altri account e servizi per accedere al workload.
  • I controlli di governance.

Requisiti normativi e di conformità

Per ogni workload AWS Lambda, assicurati di comprendere i requisiti di conformità e normativi seguendo questi passaggi:

  • Valuta i requisiti normativi e di conformità che il workload deve soddisfare.
  • Determina se il workload soddisfa questi requisiti.
  • Determina se esistono requisiti futuri che dovranno essere soddisfatti.

I requisiti di conformità e normativi potrebbero essere indipendenti dal provider cloud che utilizzi e potrebbero avere un impatto anche sulla migrazione. Ad esempio, potresti dover assicurarti che i dati e il traffico di rete rimangano entro i confini di determinate aree geografiche, come l'Unione Europea (UE).

Valuta i processi di deployment e operativi

È importante avere una chiara comprensione di come funzionano i processi di deployment e operativi. Questi processi sono una parte fondamentale delle pratiche che preparano e mantengono l'ambiente di produzione e i workload che vengono eseguiti al suo interno.

I processi di deployment e operativi potrebbero creare gli artefatti necessari per il funzionamento dei workload. Pertanto, devi raccogliere informazioni su ogni tipo di artefatto. Ad esempio, un artefatto può essere un pacchetto del sistema operativo, un pacchetto di deployment dell'applicazione, un'immagine del sistema operativo, un'immagine container o altro.

Oltre al tipo di artefatto, considera come completi le seguenti attività:

  • Sviluppa i tuoi workload. Valuta i processi che i team di sviluppo hanno messo in atto per creare i tuoi workload. Ad esempio, in che modo i tuoi team di sviluppo progettano, programmano e testano i workload?
  • Genera gli artefatti di cui esegui il deployment nell'ambiente di origine. Per eseguire il deployment dei workload nel tuo ambiente di origine, potresti generare artefatti di cui è possibile eseguire il deployment, come immagini container o immagini del sistema operativo, oppure potresti personalizzare artefatti esistenti, come immagini del sistema operativo di terze parti, installando e configurando il software. Raccogliere informazioni su come generi questi artefatti ti aiuta a garantire che gli artefatti generati siano adatti al deployment in Google Cloud.

  • Archivia gli artefatti. Se produci artefatti che archivi in un Artifact Registry nel tuo ambiente di origine, devi renderli disponibili nel tuo ambiente Google Cloud . Puoi farlo adottando strategie come le seguenti:

    • Stabilisci un canale di comunicazione tra gli ambienti: rendi gli artefatti nell'ambiente di origine raggiungibili dall'ambiente di destinazioneGoogle Cloud .
    • Rifattorizza il processo di creazione degli artefatti: esegui una rifattorizzazione minore dell'ambiente di origine in modo da poter archiviare gli artefatti sia nell'ambiente di origine che in quello di destinazione. Questo approccio supporta la migrazione creando un'infrastruttura come un repository di artefatti prima di dover implementare i processi di creazione degli artefatti nell'ambiente Google Cloud di destinazione. Puoi implementare questo approccio direttamente o basarti sull'approccio precedente, ovvero stabilire prima un canale di comunicazione.

    La disponibilità degli artefatti sia nell'ambiente di origine che in quello di destinazione ti consente di concentrarti sulla migrazione senza dover implementare i processi di creazione degli artefatti nell'ambiente di destinazione Google Cloud come parte della migrazione.

  • Scansiona e firma il codice. Nell'ambito dei processi di creazione degli artefatti, potresti utilizzare l'analisi del codice per proteggerti da vulnerabilità comuni ed esposizione involontaria della rete, nonché la firma del codice per assicurarti che nei tuoi ambienti venga eseguito solo codice attendibile.

  • Esegui il deployment degli artefatti nell'ambiente di origine. Dopo aver generato gli artefatti di cui è possibile eseguire il deployment, potresti eseguirne il deployment nel tuo ambiente di origine. Ti consigliamo di valutare ogni processo di deployment. La valutazione aiuta a garantire che i processi di deployment siano compatibili con Google Cloud. Inoltre, ti aiuta a comprendere l'impegno che sarà necessario per rifattorizzare i processi. Ad esempio, se i processi di deployment funzionano solo con l'ambiente di origine, potrebbe essere necessario rifattorizzarli per scegliere come target l'ambiente Google Cloud .

  • Inserisci la configurazione di runtime. Potresti inserire la configurazione di runtime per cluster, ambienti di runtime o deployment di workload specifici. La configurazione potrebbe inizializzare variabili di ambiente e altri valori di configurazione, come secret, credenziali e chiavi. Per assicurarti che i processi di inserimento della configurazione di runtime funzionino su Google Cloud, ti consigliamo di valutare come stai configurando i workload eseguiti nel tuo ambiente di origine.

  • Logging, monitoraggio e profilazione. Valuta i processi di logging, monitoraggio e profilazione che hai implementato per monitorare l'integrità dell'ambiente di origine, le metriche di interesse e il modo in cui utilizzi i dati forniti da questi processi.

  • Autenticazione. Valuta il modo in cui esegui l'autenticazione nell'ambiente di origine.

  • Esegui il provisioning e configura le risorse. Per preparare l'ambiente di origine, potresti aver progettato e implementato processi che eseguono il provisioning e la configurazione delle risorse. Ad esempio, potresti utilizzare Terraform insieme a strumenti di gestione delle configurazioni per eseguire il provisioning e configurare le risorse nel tuo ambiente di origine. Se utilizzi Terraform, puoi creare le tue basi e la tua zona di destinazione su Google Cloud utilizzando i seguenti strumenti, a seconda del punto di partenza che preferisci:

Completa la valutazione

Dopo aver creato gli inventari dal tuo ambiente AWS Lambda, completa il resto delle attività della fase di valutazione, come descritto in Migra a Google Cloud: valuta e scopri i tuoi workload.

Pianifica e crea le tue basi

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura per:

  • Supporta i tuoi workload nel tuo ambiente Google Cloud .
  • Collega l'ambiente di origine e l'ambiente Google Cloud per completare la migrazione.

La fase di pianificazione e creazione è composta dalle seguenti attività:

  1. Crea una gerarchia delle risorse.
  2. Configura Identity and Access Management (IAM) di Google Cloud.
  3. Configura la fatturazione.
  4. Configura la connettività di rete.
  5. Rafforza la sicurezza.
  6. Configura logging, monitoraggio e avvisi.

Per saperne di più su ciascuna di queste attività, consulta Esegui la migrazione a Google Cloud: pianifica e crea le tue basi.

Esegui la migrazione dei workload AWS Lambda

Per eseguire la migrazione dei workload da AWS Lambda a Cloud Run, segui questi passaggi:

  1. Progetta, esegui il provisioning e configura il tuo ambiente Cloud Run.
  2. Se necessario, rifattorizza i workload AWS Lambda per renderli compatibili con Cloud Run.
  3. Rifattorizza i processi di deployment e operativi per eseguire il deployment e l'osservazione dei tuoi workload su Cloud Run.
  4. Esegui la migrazione dei dati necessari per i workload AWS Lambda.
  5. Convalida i risultati della migrazione in termini di funzionalità, prestazioni e costi.

Per aiutarti a evitare problemi durante la migrazione e a stimare l'impegno necessario per la migrazione, ti consigliamo di valutare il confronto tra le funzionalità di AWS Lambda e quelle simili di Cloud Run. Le funzionalità di AWS Lambda e Cloud Run potrebbero sembrare simili quando le confronti. Tuttavia, le differenze nella progettazione e nell'implementazione delle funzionalità nei due provider cloud possono avere effetti significativi sulla migrazione da AWS Lambda a Cloud Run. Queste differenze possono influenzare le decisioni di progettazione e rifattorizzazione, come evidenziato nelle sezioni seguenti.

Progetta, esegui il provisioning e configura il tuo ambiente Cloud Run

Il primo passaggio della fase di migrazione consiste nel progettare l'ambiente Cloud Run in modo che possa supportare i workload di cui stai eseguendo la migrazione da AWS Lambda.

Per progettare correttamente l'ambiente Cloud Run, utilizza i dati raccolti durante la fase di valutazione su ogni workload AWS Lambda. Questi dati ti aiutano a:

  1. Scegli le risorse Cloud Run giuste per eseguire il deployment del tuo workload.
  2. Progetta la configurazione delle risorse Cloud Run.
  3. Esegui il provisioning e configura le risorse Cloud Run.

Scegli le risorse Cloud Run giuste

Per ogni workload AWS Lambda di cui eseguire la migrazione, scegli la risorsa Cloud Run corretta per il deployment dei workload. Cloud Run supporta le seguenti risorse principali:

  • Servizi Cloud Run: una risorsa che ospita un ambiente di runtime containerizzato, espone un endpoint univoco e scala automaticamente l'infrastruttura sottostante in base alla domanda.
  • Job Cloud Run: una risorsa che esegue uno o più container fino al completamento.

La tabella seguente riassume la mappatura delle risorse AWS Lambda alle seguenti risorse Cloud Run principali:

Risorsa AWS Lambda Risorsa Cloud Run
Funzione AWS Lambda attivata da un evento, come quelli utilizzati per siti web e applicazioni web, API e microservizi, trattamento dati in streaming e architetture basate su eventi. un servizio Cloud Run che puoi richiamare con i trigger.
Funzione AWS Lambda pianificata per l'esecuzione, ad esempio per attività in background e job batch. Job Cloud Run che viene eseguito fino al completamento.

Oltre ai servizi e ai job, Cloud Run fornisce risorse aggiuntive che estendono queste risorse principali. Per saperne di più su tutte le risorse Cloud Run disponibili, consulta Modello di risorse di Cloud Run.

Progetta la configurazione delle risorse Cloud Run

Prima di eseguire il provisioning e la configurazione delle risorse Cloud Run, devi progettarne la configurazione. Alcune opzioni di configurazione di AWS Lambda, come i limiti delle risorse e i timeout delle richieste, sono paragonabili a opzioni di configurazione di Cloud Run simili. Le sezioni seguenti descrivono le opzioni di configurazione disponibili in Cloud Run per i trigger dei servizi e l'esecuzione dei job, la configurazione delle risorse e la sicurezza. Queste sezioni evidenziano anche le opzioni di configurazione di AWS Lambda paragonabili a quelle di Cloud Run.

Trigger dei servizi Cloud Run ed esecuzione dei job

I trigger dei servizi e l'esecuzione dei job sono le principali decisioni di progettazione che devi considerare quando esegui la migrazione dei workload AWS Lambda. Cloud Run offre una varietà di opzioni per attivare ed eseguire i workload basati su eventi utilizzati in AWS Lambda. Inoltre, Cloud Run offre opzioni che puoi utilizzare per i workload di flussi di dati e i job pianificati.

Quando esegui la migrazione dei workload, spesso è utile comprendere prima quali trigger e meccanismi sono disponibili in Cloud Run. Queste informazioni ti aiutano a capire come funziona Cloud Run. In seguito, puoi utilizzare queste informazioni per determinare quali funzionalità di Cloud Run sono paragonabili a quelle di AWS Lambda e quali funzionalità di Cloud Run possono essere utilizzate durante il refactoring di questi workload.

Per scoprire di più sui trigger di servizio forniti da Cloud Run, utilizza le seguenti risorse:

Per scoprire di più sui meccanismi di esecuzione dei job forniti da Cloud Run, utilizza le seguenti risorse:

Per capire quali meccanismi di chiamata o esecuzione di Cloud Run sono paragonabili ai meccanismi di chiamata di AWS Lambda, utilizza la tabella seguente. Per ogni risorsa Cloud Run di cui devi eseguire il provisioning, assicurati di scegliere il meccanismo di chiamata o esecuzione corretto.

Funzionalità AWS Lambda Funzionalità di Cloud Run
Trigger HTTPS (URL delle funzioni) Chiamata HTTPS
Trigger HTTP/2 (parzialmente supportato utilizzando un gateway API esterno) Chiamata HTTP/2 (supportata in modo nativo)
WebSockets (supportati tramite gateway API esterno) WebSocket (supportati in modo nativo)
N/A (connessioni gRPC non supportate) Connessioni gRPC
Chiamata asincrona Integrazione di Cloud Tasks
Chiamata pianificata Integrazione di Cloud Scheduler
Trigger basato su eventi in un formato di evento proprietario Chiamata basata su eventi in formato CloudEvents
Integrazione con Amazon SQS e Amazon SNS Integrazione di Pub/Sub
AWS Lambda Step Functions Integrazione di Workflows
Configurazione delle risorse Cloud Run

Per integrare le decisioni di progettazione che hai preso per l'attivazione e l'esecuzione dei workload di cui è stata eseguita la migrazione, Cloud Run supporta diverse opzioni di configurazione che ti consentono di ottimizzare diversi aspetti dell'ambiente di runtime. Queste opzioni di configurazione sono costituite da servizi e job delle risorse.

Come accennato in precedenza, puoi comprendere meglio il funzionamento di Cloud Run sviluppando innanzitutto una comprensione di tutte le opzioni di configurazione disponibili in Cloud Run. Questa comprensione ti aiuta poi a confrontare le funzionalità di AWS Lambda con funzionalità simili di Cloud Run e a determinare come rifattorizzare i tuoi workload.

Per scoprire di più sulle configurazioni fornite dai servizi Cloud Run, utilizza le seguenti risorse:

Per scoprire di più sui job forniti da Cloud Run, utilizza le seguenti risorse:

Per capire quali opzioni di configurazione di Cloud Run sono paragonabili alle opzioni di configurazione di AWS Lambda, utilizza la tabella seguente. Per ogni risorsa Cloud Run di cui devi eseguire il provisioning, assicurati di scegliere le opzioni di configurazione corrette.

Funzionalità AWS Lambda Funzionalità di Cloud Run
Concorrenza con provisioning Numero minimo di istanze
Contemporaneità riservata per istanza
(Il pool di contemporaneità è condiviso tra le funzioni AWS Lambda nel tuo account AWS.)		 Numero massimo di istanze per servizio
N/A (non supportato, una richiesta viene mappata a un'istanza) Richieste in parallelo per istanza
N/A (dipende dall'allocazione della memoria) Allocazione della CPU
Impostazioni di scalabilità Scalabilità automatica delle istanze per i servizi
Parallelismo per i job
Configurazione dell'istanza (CPU, memoria) Limiti di CPU e memoria
Tempo massimo di esecuzione Timeout della richiesta per i servizi
Timeout delle attività per i job
AWS Lambda SnapStart Boosting della CPU all'avvio
Variabili di ambiente Variabili di ambiente
Archiviazione temporanea dei dati Montaggi di volumi in memoria
Connessioni Amazon Elastic File System Montaggi di volumi NFS
I montaggi di volumi S3 non sono supportati Montaggi dei volumi Cloud Storage
AWS Secrets Manager nei workload AWS Lambda Secret
URL dei workload ed endpoint HTTP(S) URL assegnati automaticamente
Integrazioni di Cloud Run con i prodotti Google Cloud
Sessioni persistenti (utilizzando un bilanciatore del carico esterno) Affinità di sessione
Qualificazioni Revisions

Oltre alle funzionalità elencate nella tabella precedente, devi considerare anche le differenze tra il modo in cui AWS Lambda e Cloud Run eseguono il provisioning delle istanze dell'ambiente di esecuzione. AWS Lambda esegue il provisioning di una singola istanza per ogni richiesta in parallelo. Tuttavia, Cloud Run consente di impostare il numero di richieste in parallelo che un'istanza può gestire. In altre parole, il comportamento di provisioning di AWS Lambda equivale a impostare su 1 il numero massimo di richieste in parallelo per istanza in Cloud Run. L'impostazione del numero massimo di richieste in parallelo su un valore superiore a 1 può ridurre notevolmente i costi, perché la CPU e la memoria dell'istanza sono condivise dalle richieste in parallelo, ma vengono fatturate una sola volta. La maggior parte dei framework HTTP è progettata per gestire le richieste in parallelo.

Sicurezza e controllo dell'accesso di Cloud Run

Quando progetti le risorse Cloud Run, devi anche decidere i controlli di sicurezza e di accesso necessari per i workload di cui è stata eseguita la migrazione. Cloud Run supporta diverse opzioni di configurazione per aiutarti a proteggere il tuo ambiente e a impostare ruoli e autorizzazioni per i workload di Cloud Run.

Questa sezione evidenzia i controlli di sicurezza e accesso disponibili in Cloud Run. Queste informazioni ti aiutano a capire come funzioneranno i workload di cui è stata eseguita la migrazione in Cloud Run e a identificare le opzioni di Cloud Run di cui potresti aver bisogno se esegui il refactoring di questi workload.

Per scoprire di più sui meccanismi di autenticazione forniti da Cloud Run, utilizza le seguenti risorse:

Per scoprire di più sulle funzionalità di sicurezza fornite da Cloud Run, utilizza le seguenti risorse:

Per capire quali controlli di sicurezza e controllo degli accessi di Cloud Run sono paragonabili a quelli disponibili in AWS Lambda, utilizza la tabella seguente. Per ogni risorsa Cloud Run di cui devi eseguire il provisioning, assicurati di scegliere i controlli degli accessi e le funzionalità di sicurezza corretti.

Funzionalità AWS Lambda Funzionalità di Cloud Run
Controllo degli accessi con AWS Identity and Access Management Controllo degli accessi con IAM di Google Cloud
Ruolo di esecuzione Ruolo IAM diGoogle Cloud
Limiti delle autorizzazioni Autorizzazioni IAM e segmenti di pubblico personalizzati diGoogle Cloud
Controlli di governance Servizio policy dell'organizzazione
Firma del codice Autorizzazione binaria
Accesso VPC completo Controlli di accesso granulari per il traffico in uscita VPC

Esegui il provisioning e configura le risorse Cloud Run

Dopo aver scelto le risorse Cloud Run per il deployment dei tuoi workload, esegui il provisioning e la configurazione di queste risorse. Per saperne di più sul provisioning delle risorse Cloud Run, consulta quanto segue:

Rifattorizza i workload AWS Lambda

Per eseguire la migrazione dei workload AWS Lambda a Cloud Run, potrebbe essere necessario rifattorizzarli. Ad esempio, se un workload basato su eventi accetta trigger che contengono eventi Amazon CloudWatch, potresti dover rifattorizzare il workload per fare in modo che accetti eventi nel formato CloudEvents.

Per aiutarti con il refactoring dei tuoi workload AWS Lambda, ti consigliamo di utilizzare Gemini Code Assist e Gemini CLI. Per saperne di più, consulta Migrazioni a Google Cloud basate su Gemini.

Esistono diversi fattori che possono influenzare la quantità di rifattorizzazione necessaria per ogni workload AWS Lambda, ad esempio:

  • Architettura. Considera come è progettato il workload in termini di architettura. Ad esempio, i workload AWS Lambda che hanno separato chiaramente la logica di business dalla logica per accedere alle API specifiche di AWS potrebbero richiedere meno refactoring rispetto ai workload in cui le due logiche sono combinate.
  • Idempotenza. Valuta se il workload è idempotente rispetto ai suoi input. Un workload idempotente rispetto agli input potrebbe richiedere meno refactoring rispetto ai workload che devono mantenere lo stato degli input già elaborati.
  • Stato. Valuta se il workload è stateless. Un workload stateless potrebbe richiedere meno refactoring rispetto ai workload che mantengono lo stato. Per saperne di più sui servizi supportati da Cloud Run per l'archiviazione dei dati, consulta Opzioni di archiviazione di Cloud Run.
  • Ambiente di runtime. Valuta se il workload fa delle ipotesi sul suo ambiente di runtime. Per questi tipi di workload, potresti dover soddisfare le stesse ipotesi nell'ambiente di runtime di Cloud Run o rifattorizzare il workload se non puoi fare le stesse ipotesi per l'ambiente di runtime di Cloud Run. Ad esempio, se un workload richiede la disponibilità di determinati pacchetti o librerie, devi installarli nell'ambiente di runtime di Cloud Run che ospiterà il workload.
  • Inserimento della configurazione. Valuta se il workload supporta l'utilizzo di variabili di ambiente e secret per inserire (impostare) la sua configurazione. Un workload che supporta questo tipo di inserimento potrebbe richiedere meno refactoring rispetto ai workload che supportano altri meccanismi di inserimento della configurazione.
  • API. Valuta se il workload interagisce con le API AWS Lambda. Un workload che interagisce con queste API potrebbe dover essere rifattorizzato per utilizzare le API Cloud e le API Cloud Run.
  • Error Reporting. Valuta se il workload segnala errori utilizzando flussi di output standard ed errori standard. Un workload che esegue questo tipo di segnalazione degli errori potrebbe richiedere meno refactoring rispetto ai workload che segnalano gli errori utilizzando altri meccanismi.

Per saperne di più sullo sviluppo e sull'ottimizzazione dei workload di Cloud Run, consulta le seguenti risorse:

Rifattorizza i processi di deployment e operativi

Dopo aver rifattorizzato i workload, rifattorizza i processi di deployment e operativi per:

  • Esegui il provisioning e configura le risorse nel tuo ambiente Google Cloud anziché eseguire il provisioning delle risorse nel tuo ambiente di origine.
  • Crea e configura i workload ed eseguine il deployment in Google Cloud anziché nell'ambiente di origine.

Hai raccolto informazioni su questi processi durante la fase di valutazione precedente di questo processo.

Il tipo di refactoring che devi considerare per questi processi dipende da come li hai progettati e implementati. Il refactoring dipende anche dallo stato finale che vuoi per ogni processo. Ad esempio, prendi in considerazione quanto segue:

  • Potresti aver implementato questi processi nel tuo ambiente di origine e avere intenzione di progettare e implementare processi simili in Google Cloud. Ad esempio, puoi rifattorizzare questi processi per utilizzare Cloud Build, Cloud Deploy e Infrastructure Manager.
  • Potresti aver implementato questi processi in un altro ambiente di terze parti al di fuori del tuo ambiente di origine. In questo caso, devi rifattorizzare questi processi in modo che abbiano come target l'ambiente Google Cloud anziché l'ambiente di origine.
  • Una combinazione degli approcci precedenti.

Il refactoring dei processi operativi e di deployment può essere complesso e richiedere un impegno significativo. Se provi a eseguire queste attività nell'ambito della migrazione del workload, quest'ultima può diventare più complessa ed esporti a rischi. Dopo aver valutato i processi di deployment e operativi, probabilmente ne comprenderai la progettazione e la complessità. Se stimi che il refactoring dei processi di deployment e operativi richieda un impegno significativo, ti consigliamo di considerare il refactoring di questi processi come parte di un progetto separato e dedicato.

Per saperne di più su come progettare e implementare i processi di deployment su Google Cloud, consulta:

Questo documento si concentra sui processi di deployment che producono gli artefatti di cui eseguire il deployment e li distribuiscono nell'ambiente di runtime di destinazione. La strategia di refactoring dipende in larga misura dalla complessità di questi processi. Il seguente elenco descrive una possibile strategia generale di refactoring:

  1. Esegui il provisioning dei repository di artefatti su Google Cloud. Ad esempio, puoi utilizzare Artifact Registry per archiviare gli artefatti e creare dipendenze.
  2. Rifattorizza i processi di build per archiviare gli artefatti sia nell'ambiente di origine sia in Artifact Registry.
  3. Rifattorizza i processi di deployment per eseguire il deployment dei workload nell'ambiente di destinazioneGoogle Cloud . Ad esempio, puoi iniziare eseguendo il deployment di un piccolo sottoinsieme dei tuoi workload in Google Cloud, utilizzando gli artefatti archiviati in Artifact Registry. Quindi, aumenti gradualmente il numero di workload di cui è stato eseguito il deployment in Google Cloud, finché tutti i workload di cui eseguire la migrazione non vengono eseguiti suGoogle Cloud.
  4. Rifattorizza i processi di build per archiviare gli artefatti solo in Artifact Registry.
  5. Se necessario, esegui la migrazione delle versioni precedenti degli artefatti di cui eseguire il deployment dai repository nell'ambiente di origine ad Artifact Registry. Ad esempio, per eseguire la migrazione delle immagini container ad Artifact Registry, puoi utilizzare strumenti come gcrane o Rackware SWIFT.
  6. Dismetti i repository nell'ambiente di origine quando non sono più necessari.

Per facilitare eventuali rollback dovuti a problemi imprevisti durante la migrazione, puoi archiviare le immagini container sia nei repository di artefatti attuali in Google Cloud sia durante la migrazione a Google Cloud . Infine, nell'ambito della dismissione dell'ambiente di origine, puoi rifattorizzare i processi di creazione delle immagini container per archiviare gli artefatti solo inGoogle Cloud .

Anche se potrebbe non essere fondamentale per il successo di una migrazione, potresti dover eseguire la migrazione delle versioni precedenti degli artefatti dall'ambiente di origine ai repository di artefatti su Google Cloud. Ad esempio, per supportare il rollback dei workload a momenti arbitrari, potresti dover eseguire la migrazione delle versioni precedenti degli artefatti ad Artifact Registry. Per saperne di più, consulta Esegui la migrazione delle immagini da un registry di terze parti.

Se utilizzi Artifact Registry per archiviare gli artefatti, ti consigliamo di configurare controlli per proteggere i repository di artefatti, come controllo dell'accesso, la prevenzione dell'esfiltrazione di dati, l'analisi delle vulnerabilità e l'autorizzazione binaria. Per saperne di più, consulta Controlla l'accesso e proteggi gli artefatti.

Rifattorizza i processi operativi

Nell'ambito della migrazione a Cloud Run, ti consigliamo di rifattorizzare i processi operativi per monitorare costantemente ed efficacemente l'ambiente Cloud Run.

Cloud Run si integra con i seguenti servizi operativi:

Migrazione dei dati

La fase di valutazione precedente di questo processo dovrebbe averti aiutato a determinare se i workload AWS Lambda di cui stai eseguendo la migrazione dipendono o producono dati che risiedono nel tuo ambiente AWS. Ad esempio, potresti aver stabilito che devi eseguire la migrazione dei dati da AWS S3 a Cloud Storage o da Amazon RDS e Aurora a Cloud SQL e AlloyDB per PostgreSQL. Per saperne di più sulla migrazione dei dati da AWS aGoogle Cloud, consulta Esegui la migrazione da AWS a Google Cloud: inizia.

Come per il refactoring dei processi di deployment e operativi, la migrazione dei dati da AWS a Google Cloud può essere complessa e richiedere un impegno significativo. Se provi a eseguire queste attività di migrazione dei dati nell'ambito della migrazione dei workload AWS Lambda, la migrazione può diventare complessa ed esporti a rischi. Dopo aver analizzato i dati di cui eseguire la migrazione, probabilmente avrai un'idea delle dimensioni e della complessità dei dati. Se ritieni che la migrazione di questi dati richieda un impegno significativo, ti consigliamo di considerare la migrazione dei dati come parte di un progetto separato e dedicato.

Convalida i risultati della migrazione

La convalida della migrazione del workload non è un evento una tantum, ma un processo continuo. Devi concentrarti su test e convalida prima, durante e dopo la migrazione da AWS Lambda a Cloud Run.

Per garantire una migrazione di successo con prestazioni ottimali e interruzioni minime, ti consigliamo di utilizzare la seguente procedura per convalidare i workload di cui stai eseguendo la migrazione da AWS Lambda a Cloud Run:

  • Prima di iniziare la fase di migrazione, rifattorizza gli scenari di test esistenti per tenere conto dell'ambiente Google Cloud di destinazione.
  • Durante la migrazione, convalida i risultati dei test in ogni fase della migrazione ed esegui test di integrazione approfonditi.
  • Dopo le migrazioni, esegui i seguenti test:
    • Test di riferimento: stabilisci i benchmark delle prestazioni del workload originale su AWS Lambda, ad esempio il tempo di esecuzione, l'utilizzo delle risorse e i tassi di errore con carichi diversi. Replica questi test su Cloud Run per identificare discrepanze che potrebbero indicare problemi di migrazione o configurazione.
    • Test funzionale: assicurati che la logica di base dei tuoi workload rimanga coerente creando ed eseguendo scenari di test che coprono vari scenari di input e output previsti in entrambi gli ambienti.
    • Test di carico: aumenta gradualmente il traffico per valutare le prestazioni e la scalabilità di Cloud Run in condizioni reali. Per garantire una migrazione senza problemi, risolvi le discrepanze, come errori e limitazioni delle risorse.

Ottimizza l'ambiente Google Cloud

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, esegui l'iterazione delle attività di ottimizzazione finché l'ambiente di destinazione non soddisfa i requisiti di ottimizzazione. I passaggi di ogni iterazione sono i seguenti:

  1. Valuta l'ambiente, i team e il ciclo di ottimizzazione attuali.
  2. Stabilisci i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizza l'ambiente e i team.
  4. Ottimizza il ciclo di ottimizzazione.

Ripeti questa sequenza fino a raggiungere i tuoi obiettivi di ottimizzazione.

Per saperne di più sull'ottimizzazione dell'ambiente Google Cloud , consulta Esegui la migrazione a Google Cloud: ottimizza l'ambiente e Well-Architected Framework diGoogle Cloud : ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: