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

Last reviewed 2024-10-21 UTC

Google Cloud fornisce strumenti, prodotti, indicazioni e servizi professionali per facilitare la migrazione dei carichi di lavoro 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. AWS Lambda e Cloud Run condividono somiglianze come il provisioning automatico delle risorse, lo scaling da parte del provider cloud e un modello di prezzi a consumo.

Questo documento ti aiuta a progettare, implementare e convalidare un piano per la migrazione dei carichi di lavoro serverless da AWS Lambda a Cloud Run. Inoltre, offre indicazioni per chi valuta i potenziali vantaggi e la procedura di una migrazione di questo tipo.

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

Per ulteriori informazioni sulla scelta dell'ambiente di runtime serverless più adatto alla tua logica di business, consulta Selezionare un ambiente di runtime dei 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 Migrazione a Google Cloud: Guida introduttiva.

Il seguente diagramma illustra il percorso del tuo viaggio di migrazione.

Percorso di migrazione con quattro fasi.

Potresti eseguire la migrazione dall'ambiente di origine a Google Cloud in una serie di iterazioni. Ad esempio, potresti eseguire la migrazione di alcuni workload prima e di altri in un secondo momento. Per ogni iterazione di migrazione separata, 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 carichi di lavoro e dei dati a Google Cloud.
  4. Ottimizza il tuo ambiente Google Cloud .

Per maggiori informazioni sulle fasi di questo framework, consulta la pagina Eseguire la migrazione a Google Cloud: guida introduttiva.

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 piano di migrazione, consulta la pagina Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

La migrazione dei carichi di lavoro 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 interconnessa di servizi, la migrazione da AWS a Google Cloud potrebbe richiedere la sostituzione dei servizi AWS dipendenti con servizi Google Cloud . Ad esempio, considera uno scenario in cui la 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 offre anche una preziosa opportunità per esaminare a fondo l'architettura e le decisioni di progettazione della tua applicazione serverless. Durante questa revisione, potresti scoprire opportunità per:

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

Pianifica la migrazione in modo strategico. Non considerare la migrazione come un'operazione di rehosting (lift and shift). Utilizza la migrazione come 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 migrare l'ambiente di origine a Google Cloud.

La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire una conoscenza approfondita dei carichi di lavoro 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 Google Cloud migrazione.

La fase di valutazione è costituita dalle seguenti attività:

  1. Crea un inventario completo dei tuoi workload.
  2. Catalogare i carichi di lavoro 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 di migrazione e le tempistiche.
  9. Convalida il piano di migrazione.

Per saperne di più sulla fase di valutazione e su queste attività, vedi Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro. 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 tuoi carichi di lavoro AWS Lambda, ti consigliamo di implementare un meccanismo di raccolta dei dati basato su API AWS, strumenti per sviluppatori AWS e l'interfaccia a riga di comando AWS.

Dopo aver creato l'inventario, ti consigliamo di raccogliere informazioni su ogni carico di lavoro AWS Lambda nell'inventario. Per ogni carico di lavoro, concentrati sugli aspetti che ti aiutano ad anticipare potenziali problemi. Inoltre, analizza il carico di lavoro per capire come potresti doverlo modificare 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
  • L'invocazione, i trigger e gli output
  • Ambienti di runtime ed esecuzione
  • La configurazione del workload
  • Controlli dell'accesso e autorizzazioni
  • Requisiti normativi e di conformità
  • Processi di deployment e operativi

Caso d'uso e design

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

  • Ottieni informazioni dettagliate sul caso d'uso specifico a cui serve il carico di lavoro e identifica eventuali dipendenze con altri sistemi, risorse o processi.
  • Analizza la progettazione e l'architettura del carico di lavoro.
  • Valuta i requisiti di latenza del workload.

Repository codice sorgente

L'inventario del codice sorgente delle funzioni AWS Lambda è utile se devi eseguire il refactoring dei carichi di lavoro AWS Lambda per la compatibilità con Cloud Run. La creazione di questo inventario prevede 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 componente che ti aiuta a capire se potresti dover eseguire il refactoring dei tuoi workload AWS Lambda. Per identificare gli artefatti di deployment necessari per il carico di lavoro, raccogli le seguenti informazioni:

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

Richiamo, attivatori e output

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

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

I carichi di lavoro AWS Lambda possono interagire con altre risorse e altri sistemi. Devi sapere quali risorse consumano gli output dei tuoi workload AWS Lambda e come li consumano. Queste informazioni ti aiutano a determinare se devi modificare elementi che potrebbero dipendere da questi output, come altri sistemi o carichi di lavoro. Per ogni carico di lavoro AWS Lambda, ti consigliamo di raccogliere le seguenti informazioni su altri sistemi e risorse:

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

Per funzionare, i tuoi carichi di lavoro AWS Lambda potrebbero archiviare dati permanenti e interagire con altri servizi AWS. Per ogni carico di lavoro AWS Lambda, ti consigliamo di raccogliere le seguenti informazioni su dati e altri servizi:

  • Se il carico di lavoro accede a Virtual Private Cloud (VPC) o ad altre reti private.
  • In che modo il workload archivia i dati permanenti, ad esempio utilizzando l'archiviazione dei dati effimeri e Amazon Elastic File System (EFS).

Ambienti di runtime ed esecuzione

AWS Lambda supporta diversi ambienti di esecuzione per i tuoi carichi di lavoro. Per mappare correttamente gli ambienti di esecuzione AWS Lambda agli ambienti di esecuzione 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 carico di lavoro.

Se i tuoi carichi di lavoro AWS Lambda vengono eseguiti in ambienti di runtime specifici per la lingua, considera quanto segue per ogni carico di lavoro AWS Lambda:

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

Configurazione del workload

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

Per ogni workload AWS Lambda, raccogli informazioni sulle seguenti impostazioni di concorrenza 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.
  • Tag e controllo dell'accesso basato su attributi.
  • La macchina a stati per gestire le condizioni eccezionali.
  • Le immagini di base e i file di configurazione (come Dockerfile) per i pacchetti di deployment che utilizzano immagini container.

Controlli e autorizzazioni di accesso

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 dell'accesso. Queste informazioni sono fondamentali se devi implementare controlli simili nel tuo Google Cloud ambiente. Per ogni carico di lavoro, considera quanto segue:

  • Il ruolo di esecuzione e le autorizzazioni.
  • La configurazione di Identity and Access Management che il workload e i relativi livelli utilizzano per accedere ad altre risorse.
  • La configurazione di gestione dell'identità e dell'accesso che altri account e servizi utilizzano per accedere al workload.
  • Controlli di governance.

Requisiti normativi e di conformità

Per ogni workload AWS Lambda, assicurati di comprendere i requisiti di conformità e normativi procedendo nel seguente modo:

  • Valuta eventuali requisiti normativi e di conformità che il workload deve soddisfare.
  • Determina se il workload soddisfa attualmente questi requisiti.
  • Determina se ci sono requisiti futuri che dovranno essere soddisfatti.

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

Valuta i processi di deployment e operativi

È importante avere una chiara comprensione del funzionamento dei processi di deployment e operativi. Questi processi sono una parte fondamentale delle pratiche che preparano e mantengono il tuo 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 tuoi 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 qualcos'altro.

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

  • Sviluppa i tuoi carichi di lavoro. Valuta i processi che i team di sviluppo hanno in atto per creare i tuoi carichi di lavoro. Ad esempio, in che modo i tuoi team di sviluppo progettano, codificano e testano i tuoi carichi di lavoro?
  • Genera gli artefatti di cui esegui il deployment nell'ambiente di origine. Per eseguire il deployment dei tuoi workload nell'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. La raccolta di informazioni su come generi questi artefatti ti aiuta a assicurarti che siano adatti al deployment in Google Cloud.

  • Archivia gli artefatti. Se produci artefatti che archivi in un registro degli artefatti nell'ambiente di origine, devi renderli disponibili nell'ambiente Google Cloud . Puoi farlo utilizzando strategie come le seguenti:

    • Stabilisci un canale di comunicazione tra gli ambienti: rendi gli artefatti nell'ambiente di origine raggiungibili dall'ambienteGoogle Cloud di destinazione.
    • Esegui il refactoring del processo di creazione degli artefatti: completa un refactoring secondario dell'ambiente di origine in modo da poter archiviare gli artefatti sia nell'ambiente di origine sia 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 di destinazione. Google CloudPuoi implementare questo approccio direttamente oppure puoi basarti sull'approccio precedente di stabilire prima un canale di comunicazione.

    La disponibilità degli artefatti sia nell'ambiente di origine sia in quello di destinazione ti consente di concentrarti sulla migrazione senza dover implementare processi di compilazione degli artefatti nell'ambiente di destinazione Google Cloud nell'ambito della migrazione.

  • Scansiona e firma il codice. Nell'ambito dei processi di creazione degli artefatti, potresti utilizzare la scansione del codice per proteggerti da vulnerabilità comuni e dall'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 nell'ambiente di origine. Ti consigliamo di valutare ogni processo di deployment. L'analisi aiuta a garantire che i processi di deployment siano compatibili con Google Cloud. Ti aiuta anche a comprendere l'impegno necessario per eventualmente eseguire il refactoring dei processi. Ad esempio, se i processi di deployment funzionano solo con l'ambiente di origine, potresti doverli refactorizzare per indirizzarli all'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 contribuire a garantire che i processi di inserimento della configurazione di runtime funzionino su Google Cloud, ti consigliamo di valutare come configuri i workload eseguiti nell'ambiente di origine.

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

  • Autenticazione. Valuta l'autenticazione rispetto all'ambiente di origine.

  • Esegui il provisioning e la configurazione delle 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 della configurazione per eseguire il provisioning e configurare le risorse nell'ambiente di origine.

Completa la valutazione

Dopo aver creato gli inventari dall'ambiente AWS Lambda, completa le altre attività della fase di valutazione come descritto in Migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro.

Pianificare e creare le basi

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

  • Supporta i tuoi carichi di lavoro 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 tua sicurezza.
  6. Configura logging, monitoraggio e avvisi.

Per maggiori informazioni su ciascuna di queste attività, consulta la sezione Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

Esegui la migrazione dei carichi di lavoro AWS Lambda

Per eseguire la migrazione dei carichi di lavoro da AWS Lambda a Cloud Run, procedi nel seguente modo:

  1. Progetta, esegui il provisioning e configura l'ambiente Cloud Run.
  2. Se necessario, esegui il refactoring dei carichi di lavoro AWS Lambda per renderli compatibili con Cloud Run.
  3. Esegui il refactoring dei processi di deployment e operativi per eseguire il deployment e osservare i tuoi carichi di lavoro su Cloud Run.
  4. Esegui la migrazione dei dati necessari per i carichi di lavoro 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 di servizi cloud possono avere effetti significativi sulla migrazione da AWS Lambda a Cloud Run. Queste differenze possono influenzare sia le decisioni di progettazione che di refactoring, come evidenziato nelle sezioni seguenti.

Progettare, eseguire il provisioning e configurare l'ambiente Cloud Run

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

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

  1. Scegliere le risorse Cloud Run giuste per eseguire il deployment del tuo carico di lavoro.
  2. Progetta la configurazione delle risorse Cloud Run.
  3. Esegui il provisioning e configura le risorse Cloud Run.

Scegliere 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 seguente tabella riassume la mappatura delle risorse AWS Lambda a queste 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, elaborazione di dati in streaming e architetture basate su eventi. Servizio Cloud Run che puoi richiamare con trigger.
Funzione AWS Lambda pianificata per l'esecuzione, ad esempio quelle per attività in background e job batch. Job Cloud Run che viene eseguito fino al completamento.

Oltre a servizi e job, Cloud Run fornisce risorse aggiuntive che estendono queste risorse principali. Per ulteriori informazioni 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, progetta la loro configurazione. Alcune opzioni di configurazione di AWS Lambda, come i limiti delle risorse e i timeout delle richieste, sono paragonabili a opzioni di configurazione simili di Cloud Run. Le sezioni seguenti descrivono le opzioni di configurazione disponibili in Cloud Run per trigger di servizio ed esecuzione dei job, configurazione delle risorse e sicurezza. Queste sezioni evidenziano anche le opzioni di configurazione di AWS Lambda comparabili a quelle di Cloud Run.

Trigger del servizio Cloud Run ed esecuzione dei job

I trigger di servizio e l'esecuzione dei job sono le principali decisioni di progettazione da prendere in considerazione quando esegui la migrazione dei carichi di lavoro AWS Lambda. Cloud Run offre una serie di opzioni per attivare ed eseguire i carichi di lavoro basati su eventi utilizzati in AWS Lambda. Inoltre, Cloud Run offre opzioni che puoi utilizzare per i carichi di lavoro di streaming e i job pianificati.

Quando esegui la migrazione dei tuoi carichi di lavoro, spesso è utile capire prima quali trigger e meccanismi sono disponibili in Cloud Run. Queste informazioni ti aiutano a capire come funziona Cloud Run. Poi, puoi utilizzare questa comprensione per determinare quali funzionalità di Cloud Run sono paragonabili a quelle di AWS Lambda e quali funzionalità di Cloud Run potrebbero essere utilizzate durante il refactoring di questi carichi di lavoro.

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 aiutarti a capire quali meccanismi di chiamata o esecuzione di Cloud Run sono paragonabili ai meccanismi di chiamata di AWS Lambda, utilizza la seguente tabella. Per ogni risorsa Cloud Run che devi eseguire il provisioning, assicurati di scegliere il meccanismo di invocazione o di esecuzione corretto.

Funzionalità AWS Lambda Funzionalità Cloud Run
Trigger HTTPS (URL funzione) Chiamata HTTPS
Trigger HTTP/2 (supportato parzialmente utilizzando un gateway API esterno) Chiamata HTTP/2 (supportata in modo nativo)
WebSocket (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 Richiamo basato su eventi in formato CloudEvents
Integrazione di Amazon SQS e Amazon SNS Integrazione Pub/Sub
Funzioni di step AWS Lambda Integrazione di Workflows
Configurazione delle risorse Cloud Run

Per integrare le decisioni di progettazione che hai preso per l'attivazione e l'esecuzione dei carichi di lavoro migrati, 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 acquisendo prima una conoscenza di tutte le opzioni di configurazione disponibili in Cloud Run. Questa comprensione ti aiuta poi a confrontare le funzionalità di AWS Lambda con quelle simili di Cloud Run e a determinare come eseguire il refactoring dei carichi di lavoro.

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

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

Per aiutarti a capire quali opzioni di configurazione di Cloud Run sono paragonabili alle opzioni di configurazione di AWS Lambda, utilizza la seguente tabella. Per ogni risorsa Cloud Run che devi provisionare, assicurati di scegliere le opzioni di configurazione corrette.

Funzionalità AWS Lambda Funzionalità Cloud Run
Contemporaneità assegnata 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 corrisponde a un'istanza) Richieste simultanee 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 richiesta per i servizi
Timeout attività per i lavori
AWS Lambda SnapStart Boosting della CPU all'avvio
Variabili di ambiente Variabili di ambiente
Spazio di archiviazione temporanea Montaggi volumi in memoria
Connessioni Amazon Elastic File System Montaggi dei volumi NFS
I montaggi dei volumi S3 non sono supportati Montaggi dei volumi Cloud Storage
AWS Secrets Manager nei carichi di lavoro AWS Lambda Secret
URL dei workload ed endpoint HTTP(S) URL assegnati automaticamente
Integrazioni di Cloud Run con i prodotti Google Cloud
Sessioni permanenti (utilizzando un bilanciatore del carico esterno) Affinità sessione
Qualificazioni Revisioni

Oltre alle funzionalità elencate nella tabella precedente, devi anche considerare 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 ognirichiesta in paralleloa. Tuttavia, Cloud Run ti consente di impostare il numero di richieste simultanee che un'istanza può gestire. ovvero il comportamento di provisioning di AWS Lambda equivale a impostare il numero massimo di richieste simultanee per istanza su 1 in Cloud Run. L'impostazione del numero massimo di richieste simultanee su un valore superiore a 1 può farti risparmiare notevolmente sui costi, perché la CPU e la memoria dell'istanza vengono condivise dalle richieste simultanee, 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 carichi di lavoro di cui è stata eseguita la migrazione. Cloud Run supporta diverse opzioni di configurazione per proteggere l'ambiente e per impostare ruoli e autorizzazioni per i carichi di lavoro Cloud Run.

Questa sezione evidenzia i controlli di sicurezza e accesso disponibili in Cloud Run. Queste informazioni ti aiutano a capire come funzioneranno i carichi di lavoro 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 carichi di lavoro.

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 aiutarti a capire quali controlli di sicurezza e accesso di Cloud Run sono paragonabili a quelli disponibili in AWS Lambda, utilizza la seguente tabella. Per ogni risorsa Cloud Run di cui devi eseguire il provisioning, assicurati di scegliere i controlli dell'accesso e le funzionalità di sicurezza giusti.

Funzionalità AWS Lambda Funzionalità Cloud Run
Controllo dell'accesso con AWS Identity Access and Management Controllo dell'accesso con IAM di Google Cloud
Ruolo di esecuzione Google Cloud's IAM role
Confini delle autorizzazioni Google Cloud's autorizzazioni IAM e segmenti di pubblico personalizzati
Controlli di governance Servizio Criteri dell'organizzazione
Firma del codice Autorizzazione binaria
Accesso VPC completo Controlli granulari dell'accesso in uscita VPC

Esegui il provisioning e configura le risorse Cloud Run

Dopo aver scelto le risorse Cloud Run per il deployment dei carichi di lavoro, esegui il provisioning e la configurazione di queste risorse. Per ulteriori informazioni sul provisioning delle risorse Cloud Run, consulta quanto segue:

Eseguire il refactoring dei carichi di lavoro AWS Lambda

Per eseguire la migrazione dei carichi di lavoro AWS Lambda a Cloud Run, potresti dover eseguire il refactoring. Ad esempio, se un carico di lavoro basato su eventi accetta trigger che contengono eventi Amazon CloudWatch, potresti dover eseguire il refactoring di questo carico di lavoro per fare in modo che accetti eventi nel formato CloudEvents.

Esistono diversi fattori che possono influenzare la quantità di refactoring necessaria per ogni carico di lavoro AWS Lambda, ad esempio:

  • Architettura. Considera come è progettato il carico di lavoro in termini di architettura. Ad esempio, i carichi di lavoro AWS Lambda che hanno separato chiaramente la logica di business dalla logica di accesso alle API specifiche di AWS potrebbero richiedere un refactoring minore rispetto ai carichi di lavoro 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 che hanno già elaborato.
  • Stato. Valuta se il carico di lavoro è stateless. Un carico di lavoro stateless potrebbe richiedere meno refactoring rispetto ai carichi di lavoro che mantengono lo stato. Per saperne di più sui servizi supportati da Cloud Run per archiviare i dati, consulta Opzioni di archiviazione di Cloud Run.
  • Ambiente di runtime. Valuta se il workload fa ipotesi sull'ambiente di runtime. Per questi tipi di carichi di lavoro, potresti dover soddisfare le stesse ipotesi nell'ambiente di runtime di Cloud Run o eseguire il refactoring del carico di lavoro se non puoi fare le stesse ipotesi per l'ambiente di runtime di Cloud Run. Ad esempio, se un carico di lavoro richiede determinati pacchetti o librerie, devi installarli nell'ambiente di runtime Cloud Run che ospiterà il carico di lavoro.
  • 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 sottoposto a refactoring per utilizzare le API Cloud e le API Cloud Run.
  • Segnalazione degli errori. Valuta se il workload segnala errori utilizzando i flussi di output ed errori standard. Un workload che esegue questo tipo di segnalazione degli errori potrebbe richiedere un refactoring minore rispetto ai workload che segnalano gli errori utilizzando altri meccanismi.

Per ulteriori informazioni sullo sviluppo e l'ottimizzazione dei workload Cloud Run, consulta le seguenti risorse:

Riorganizzare i processi di deployment e operativi

Dopo aver eseguito il refactoring dei carichi di lavoro, esegui il refactoring dei processi di deployment e operativi per:

  • Esegui il provisioning e la configurazione delle risorse nel tuo Google Cloud ambiente anziché eseguire il provisioning delle risorse nell'ambiente di origine.
  • Crea e configura i carichi di lavoro e implementali in Google Cloud anziché nell'ambiente di origine.

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

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

  • Potresti aver implementato questi processi nell'ambiente di origine e intendi progettare e implementare processi simili in Google Cloud. Ad esempio, puoi eseguire il refactoring di 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 dell'ambiente di origine. In questo caso, devi eseguire il refactoring di questi processi per scegliere come target l'ambiente Google Cloud anziché l'ambiente di origine.
  • Una combinazione degli approcci precedenti.

Il refactoring dei processi di deployment e operativi può essere complesso e richiedere uno sforzo 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 hai una comprensione della loro progettazione e complessità. Se stimi che sia necessario un impegno notevole per eseguire il refactoring dei processi di deployment e operativi, ti consigliamo di prendere in considerazione il refactoring di questi processi nell'ambito di un progetto separato e dedicato.

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

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

  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. Esegui il refactoring dei processi di build per archiviare gli artefatti sia nell'ambiente di origine sia in Artifact Registry.
  3. Esegui il refactoring dei processi di deployment per eseguire il deployment dei carichi di lavoro nell'ambiente di destinazione.Google Cloud Ad esempio, puoi iniziare eseguendo il deployment di un piccolo sottoinsieme dei tuoi carichi di lavoro in Google Cloud, utilizzando gli artefatti archiviati in Artifact Registry. Poi, aumenti gradualmente il numero di carichi di lavoro di cui è stato eseguito il deployment in Google Cloud, finché tutti i carichi di lavoro da migrare non vengono eseguiti su Google Cloud.
  4. Esegui il refactoring dei processi di build per archiviare gli artefatti solo in Artifact Registry.
  5. Se necessario, esegui la migrazione delle versioni precedenti degli artefatti da distribuire dai repository nell'ambiente di origine ad Artifact Registry. Ad esempio, puoi copiare le immagini container in Artifact Registry.
  6. Ritira i repository nell'ambiente di origine quando non ti servono più.

Per facilitare i rollback dovuti a problemi imprevisti durante la migrazione, puoi archiviare le immagini container sia nei repository di artefatti attuali in Google Cloud mentre la migrazione a Google Cloud è in corso. Infine, nell'ambito del ritiro dell'ambiente di origine, puoi eseguire il refactoring dei processi di creazione delle immagini container per archiviare gli artefatti solo in Google Cloud .

Sebbene non sia 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 punti temporali arbitrari, potrebbe essere necessario migrare le versioni precedenti degli artefatti in Artifact Registry. Per maggiori informazioni, vedi Eseguire la migrazione delle immagini da un registro di terze parti.

Se utilizzi Artifact Registry per archiviare gli artefatti, ti consigliamo di configurare i controlli per proteggere i repository di artefatti, come icontrollo dell'accessolo dell'accesso, la prevenzione dell&#3esfiltrazione di datiti,analisi delle vulnerabilitàtà e l'autorizzazione binaria. Per saperne di più, consulta Controllare l'accesso e proteggere gli artefatti.

Refactoring dei processi operativi

Nell'ambito della migrazione a Cloud Run, ti consigliamo di refactoring dei processi operativi per monitorare costantemente ed efficacemente il tuo ambiente Cloud Run.

Cloud Run si integra con i seguenti servizi operativi:

Migrazione dei dati

La fase di valutazione precedente in questo processo dovrebbe averti aiutato a determinare se i workload AWS Lambda di cui stai eseguendo la migrazione dipendono da dati che risiedono nel tuo ambiente AWS o li producono. Ad esempio, potresti aver stabilito di dover 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 a Google Cloud, consulta Eseguire la migrazione da AWS a Google Cloud: Guida introduttiva.

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 tenti di eseguire queste attività di migrazione dei dati nell'ambito della migrazione dei tuoi carichi di lavoro AWS Lambda, la migrazione può diventare complessa ed esporti a rischi. Dopo aver analizzato i dati da migrare, probabilmente avrai un'idea delle dimensioni e della complessità dei dati. Se ritieni che la migrazione di questi dati richieda un impegno notevole, ti consigliamo di prendere in considerazione la migrazione dei dati nell'ambito di un progetto separato e dedicato.

Convalidare i risultati della migrazione

La convalida della migrazione del carico di lavoro 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 riuscita con prestazioni ottimali e interruzioni minime, ti consigliamo di utilizzare la seguente procedura per convalidare i carichi di lavoro che stai migrando da AWS Lambda a Cloud Run:

  • Prima di iniziare la fase di migrazione, esegui il refactoring dei casi di test esistenti per tenere conto dell'ambiente di destinazione. Google Cloud
  • Durante la migrazione, convalida i risultati dei test in ogni traguardo della migrazione ed esegui test di integrazione approfonditi.
  • Dopo le migrazioni, esegui i seguenti test:
    • Test di base: stabilisci i benchmark di rendimento del workload originale su AWS Lambda, ad esempio tempo di esecuzione, utilizzo delle risorse e tassi di errore con carichi diversi. Replica questi test su Cloud Run per identificare le discrepanze che potrebbero indicare problemi di migrazione o configurazione.
    • Test funzionali: assicurati che la logica di base dei tuoi carichi di lavoro rimanga coerente creando ed eseguendo scenari di test che coprano 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.

Ottimizzare l' Google Cloud ambiente

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 il tuo ambiente e i tuoi team.
  4. Ottimizza il ciclo di ottimizzazione.

Ripeti questa sequenza finché non hai raggiunto gli obiettivi di ottimizzazione.

Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud , vedi Migrazione a Google Cloud: ottimizza il tuo ambiente e Google Cloud Well-Architected Framework: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: