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 aiutarti a eseguire 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. Sia AWS Lambda sia Cloud Run condividono somiglianze come il provisioning automatico delle risorse, il ridimensionamento da parte del provider cloud e un modello di prezzi a consumo.

Questo documento ti aiuta a progettare, implementare e convalidare un piano per eseguire 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 giusto per la tua logica di business, consulta Selezionare un ambiente di runtime dei contenitori 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 Eseguire la migrazione a Google Cloud: inizia.

Il seguente diagramma illustra il percorso del tuo 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 potresti eseguire la migrazione di alcuni carichi di lavoro prima e di altri più tardi. Per ogni iterazione di migrazione distinta, segui le fasi del framework di migrazione generale:

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

Per saperne di più sulle fasi di questo framework, consulta Eseguire 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 aiutarti a convalidare il piano di migrazione, consulta Eseguire la migrazione a Google Cloud: best practice per convalidare un piano di migrazione.

La migrazione dei carichi di lavoro serverless spesso non si limita al trasferimento delle funzioni da un provider cloud all'altro. Poiché le applicazioni basate su cloud si basano su un web 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 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 un'occasione preziosa per esaminare attentamente le decisioni di progettazione e dell'architettura della tua applicazione serverless. Grazie a questa revisione, potresti scoprire opportunità per:

  • Ottimizza con le funzionalità integrate di Google Cloud: scopri se i servizi Google Cloud offrono vantaggi unici o sono più in linea con i requisiti della tua applicazione.
  • Semplifica l'architettura: valuta se è possibile semplificare il sistema consolidando le funzionalità o utilizzando i servizi in modo diverso in Google Cloud.
  • Migliora l'efficienza dei costi: valuta le potenziali differenze di costo dell'esecuzione dell'applicazione ristrutturata 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 esercizio di rihosting (lift and shift). Utilizza la migrazione come un'opportunità per migliorare il design e la qualità del codice complessivi della tua applicazione serverless.

Valutare l'ambiente di origine

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

La fase di valutazione è fondamentale per la buona riuscita della migrazione. Devi acquisire conoscenze approfondite sui carichi di lavoro di cui vuoi eseguire la migrazione, sui relativi requisiti, sulle dipendenze e sul tuo ambiente attuale. Per pianificare ed eseguire correttamente una migrazione a Google Cloud, devi conoscere il punto di partenza.

La fase di valutazione è composta dalle seguenti attività:

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

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Eseguire la migrazione a Google Cloud: valutare e rilevare i 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 sulle API AWS, sugli strumenti per sviluppatori AWS e sull'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 se potresti dover modificare il carico di lavoro e le relative dipendenze prima di eseguire la migrazione a Cloud Run. Ti consigliamo di iniziare raccogliendo i 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, gli attivatori e le uscite
  • Gli ambienti di runtime e di esecuzione
  • La configurazione del carico di lavoro
  • I controlli e le autorizzazioni di accesso
  • I requisiti di conformità e normativi
  • I processi di deployment e operativi

Caso d'uso e design

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

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

Repository codice sorgente

L'inventario del codice sorgente delle funzioni AWS Lambda è utile se devi eseguire il refactoring dei tuoi 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 fonte è essenziale per le tue procedure DevOps, come le pipeline di integrazione e sviluppo continui (CI/CD), perché anche queste procedure dovranno essere aggiornate durante la migrazione a Cloud Run.

Artefatti di deployment

Sapere quali elementi di deployment sono necessari per il carico di lavoro è un altro componente che ti aiuta a capire se potresti dover eseguire il refactoring dei carichi di lavoro AWS Lambda. Per identificare gli elementi di deployment di cui il carico di lavoro necessita, raccogli le seguenti informazioni:

  • Il tipo di pacchetto di deployment per eseguire il deployment del carico di lavoro.
  • Qualsiasi livello AWS Lambda che contenga codice aggiuntivo, come librerie e altre dipendenze.
  • Eventuali estensioni AWS Lambda di cui dipende il carico di lavoro.
  • I qualificatori configurati 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, ad esempio gli attivatori, e diversi modelli di chiamata, ad esempio la chiamata sincrona e la chiamata asincrona. Per ogni carico di lavoro AWS Lambda, ti consigliamo di raccogliere le seguenti informazioni relative ad attivatori e invocazioni:

  • Gli attivatori e le mappature delle origini evento che invocano il carico di lavoro.
  • Indica se il carico di lavoro supporta le invocazioni sincrone e asincrone.
  • Gli URL dei carichi di lavoro 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 workload AWS Lambda e in che modo queste risorse li consumano. Queste informazioni ti aiutano a determinare se devi modificare qualcosa che potrebbe dipendere da questi output, ad esempio altri sistemi o carichi di lavoro. Per ogni carico di lavoro AWS Lambda, consigliamo di raccogliere le seguenti informazioni su altre risorse e sistemi:

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

Per funzionare, i 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:

  • Indica se il carico di lavoro accede a virtual private cloud (VPC) o ad altre reti private.
  • In che modo il carico di lavoro memorizza i dati permanenti, ad esempio utilizzando l'archiviazione dei dati temporanei e Amazon Elastic File System (EFS).

Ambiente di runtime e ambienti di esecuzione

AWS Lambda supporta diversi ambienti di esecuzione per i tuoi carichi di lavoro. 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 carico di lavoro AWS Lambda:

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

Se i carichi di lavoro AWS Lambda vengono eseguiti in ambienti di runtime specifici per il linguaggio, prendi in considerazione quanto segue per ogni carico di lavoro AWS Lambda:

  • Il tipo, la versione e l'identificatore univoco dell'ambiente di runtime specifico per lingua.
  • Eventuali modifiche applicate 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 ciascun workload AWS Lambda.

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

  • I controlli della concorrenza.
  • Le impostazioni di scalabilità.
  • La configurazione delle istanze del carico di lavoro, in termini di quantità di memoria disponibile e tempo di esecuzione massimo consentito.
  • Se il workload utilizza SnapStart di AWS Lambda, la contemporaneità riservata o la contemporaneità di cui è stato eseguito il provisioning per ridurre la latenza.
  • Le variabili di ambiente che hai configurato, oltre a quelle configurate da AWS Lambda e da cui dipende il carico di lavoro.
  • I 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 (ad esempio il Dockerfile) per i pacchetti di deployment che utilizzano immagini container.

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

  • Il ruolo di esecuzione e le autorizzazioni.
  • La configurazione di Identity and Access Management utilizzata dal carico di lavoro e dai relativi livelli per accedere ad altre risorse.
  • La configurazione di gestione delle identità e degli accessi utilizzata da altri account e servizi per accedere al carico di lavoro.
  • I controlli di governance.

Requisiti di conformità e normativi

Per ogni carico di lavoro AWS Lambda, assicurati di comprendere i requisiti di conformità e normativi tenendo presente quanto segue:

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

I requisiti di conformità e normativi potrebbero essere indipendenti dal fornitore di servizi cloud che utilizzi e potrebbero avere un impatto anche sulla migrazione. Ad esempio, potresti dover assicurarti che il traffico di dati e di rete rimanga all'interno dei confini di determinate aree geografiche, come l'Unione europea (UE).

Valuta le procedure di deployment e operative

È importante avere una comprensione chiara del funzionamento delle procedure di deployment e operative. Queste procedure sono una parte fondamentale delle pratiche che preparano e gestiscono l'ambiente di produzione e i relativi carichi di lavoro.

I processi di deployment e operativi potrebbero creare gli elementi necessari per il funzionamento dei carichi di lavoro. Pertanto, devi raccogliere informazioni su ogni tipo di elemento. Ad esempio, un elemento può essere un pacchetto del sistema operativo, un pacchetto di deployment dell'applicazione, un'immagine del sistema operativo, un'immagine del contenitore o qualcos'altro.

Oltre al tipo di elemento, valuta come completare le seguenti attività:

  • Sviluppa i tuoi carichi di lavoro. Valuta le procedure messe in atto dai team di sviluppo per creare i carichi di lavoro. Ad esempio, in che modo i tuoi team di sviluppo progettano, codificano e testano i carichi di lavoro?
  • Genera gli elementi da eseguire nel tuo 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 personalizzare artefatti esistenti, come immagini del sistema operativo di terze parti, installando e configurando il software. Raccogliere informazioni su come generi questi elementi ti aiuta a verificare che siano adatti per il deployment in Google Cloud.

  • Archivia gli elementi. Se produci artefatti che memorizzi in un registro di artefatti 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 accessibili gli elementi dell'ambiente di origine dall'ambiente Google Cloud di destinazione.
    • Esegui il refactoring del processo di compilazione degli elementi: completa un refactoring minore dell'ambiente di origine in modo da poter archiviare gli elementi sia nell'ambiente di origine sia nell'ambiente di destinazione. Questo approccio supporta la migrazione creando un'infrastruttura come un repository di elementi prima di dover implementare le procedure di compilazione degli elementi nell'ambiente Google Cloud di destinazione. Puoi implementare questo approccio direttamente o puoi basarti sull'approccio precedente di stabilire prima un canale di comunicazione.

    Avere gli elementi disponibili sia nell'ambiente di origine sia in quello di destinazione ti consente di concentrarti sulla migrazione senza dover implementare le procedure di compilazione degli elementi nell'ambiente Google Cloud di destinazione nell'ambito della migrazione.

  • Scansiona e firma il codice. Nell'ambito delle procedure di compilazione degli elementi, potresti utilizzare la scansione del codice per proteggerti da vulnerabilità comuni e dall'esposizione involontaria alla rete, nonché la firma del codice per assicurarti che nei tuoi ambienti venga eseguito solo codice attendibile.

  • Esegui il deployment degli elementi nell'ambiente di origine. Dopo aver generato gli elementi di deployment, potresti eseguirne il deployment nell'ambiente di origine. Ti consigliamo di valutare ogni processo di implementazione. La valutazione consente di verificare che i processi di implementazione siano compatibili con Google Cloud. Inoltre, ti aiuta a capire lo sforzo necessario per eseguire il refactoring delle procedure. Ad esempio, se le tue procedure di implementazione lavorano solo con l'ambiente di origine, potresti doverle rifare in modo che abbiano come target il tuo ambiente Google Cloud.

  • Esegui l'iniezione della configurazione di runtime. Potresti iniettare la configurazione di runtime per cluster, ambienti di runtime o deployment dei carichi di lavoro specifici. La configurazione potrebbe inizializzare le variabili di ambiente e altri valori di configurazione come secret, credenziali e chiavi. Per contribuire a garantire che le procedure di inserimento della configurazione di runtime funzionino su Google Cloud, ti consigliamo di valutare la modalità di configurazione dei carichi di lavoro eseguiti nel tuo ambiente di origine.

  • Logging, monitoraggio e profilazione. Valuta le procedure di registrazione, monitoraggio e profiling che hai implementato per monitorare lo stato di integrità del tuo ambiente di origine, le metriche di interesse e il modo in cui utilizzi i dati forniti da queste procedure.

  • Autenticazione. Valuta la modalità di autenticazione rispetto all'ambiente di origine.

  • Esegui il provisioning e configura le risorse. Per preparare l'ambiente di origine, potresti aver progettato e implementato procedure di provisioning e configurazione delle risorse. Ad esempio, potresti utilizzare Terraform insieme a strumenti di gestione della configurazione per eseguire il provisioning e configurare le risorse nel tuo ambiente di origine.

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 Eseguire la migrazione a Google Cloud: valutare e scoprire i carichi di lavoro.

Pianifica e crea le basi

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

  • Supporta i tuoi carichi di lavoro nel tuo ambiente Google Cloud.
  • Connetti l'ambiente di origine e l'ambiente Google Cloud per completare la migrazione.

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

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

Per ulteriori informazioni su ciascuna di queste attività, consulta la pagina 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, svolgi i seguenti passaggi:

  1. Progetta, esegui il provisioning e configura il tuo 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 delle procedure di deployment e operative per eseguire il deployment e osservare i tuoi carichi di lavoro su Cloud Run.
  4. Esegui la migrazione dei dati necessari per i tuoi 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 lo sforzo necessario per la migrazione, ti consigliamo di valutare il confronto tra le funzionalità di AWS Lambda e quelle di Cloud Run simili. Le funzionalità di AWS Lambda e Cloud Run possono sembrare simili se le confronti. Tuttavia, le differenze nel design e nell'implementazione delle funzionalità dei due fornitori di cloud possono avere effetti significativi sulla migrazione da AWS Lambda a Cloud Run. Queste differenze possono influire sia sulle decisioni di progettazione sia su quelle di refactoring, 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 carichi di lavoro 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 relativi a ciascun carico di lavoro AWS Lambda. Questi dati ti consentono di:

  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 la configurazione delle risorse Cloud Run.

Scegli le risorse Cloud Run giuste

Per ogni carico di lavoro AWS Lambda di cui eseguire la migrazione, scegli la risorsa Cloud Run corretta per eseguire il deployment dei carichi di lavoro. 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 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 gli attivatori.
Funzione AWS Lambda pianificata per l'esecuzione, ad esempio per le attività in background e i 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 il modello di risorse Cloud Run.

Progettare 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 di 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 gli attivatori 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 del servizio Cloud Run ed esecuzione dei job

Gli attivatori dei servizi e l'esecuzione dei job sono le principali decisioni di progettazione che devi prendere 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 in streaming e i job pianificati.

Quando esegui la migrazione dei tuoi carichi di lavoro, 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 potrebbero essere utilizzate per il refactoring di questi carichi di lavoro.

Per scoprire di più sugli attivatori di servizio forniti da Cloud Run, consulta 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 invocazione o esecuzione di Cloud Run sono paragonabili ai meccanismi di invocazione 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 esecuzione corretto.

Funzionalità AWS Lambda Funzionalità Cloud Run
Trigger HTTPS (URL funzione) Chiamata HTTPS
Attivazione HTTP/2 (supportata parzialmente tramite un gateway API esterno) Chiamata HTTP/2 (supportata in modo nativo)
WebSocket (supportati tramite gateway API esterno) WebSocket (supportati nativamente)
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 proprietario Invocazione basata su eventi in formato CloudEvents
Integrazione di Amazon SQS e Amazon SNS Integrazione Pub/Sub
Funzioni a gradino AWS Lambda Integrazione Workflows
Configurazione delle risorse Cloud Run

Per integrare le decisioni di progettazione che hai preso per attivare ed eseguire i carichi di lavoro sottoposti a 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 di 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 conoscenza ti aiuta quindi a confrontare le funzionalità di AWS Lambda con funzionalità Cloud Run simili 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 scoprire 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 tabella seguente. Per ogni risorsa Cloud Run di cui hai bisogno per eseguire il provisioning, assicurati di scegliere le opzioni di configurazione corrette.

Funzionalità AWS Lambda Funzionalità Cloud Run
Concorrenza pianificata 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 mappa a una 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
Parallismo 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 job
SnapStart di AWS Lambda Boosting della CPU all'avvio
Variabili di ambiente Variabili di ambiente
Archiviazione dei dati temporanea Punti di montaggio dei volumi in memoria
Connessioni Amazon Elastic File System Montaggi dei volumi NFS
I mount dei volumi S3 non sono supportati Montaggi dei volumi Cloud Storage
AWS Secrets Manager nei carichi di lavoro AWS Lambda Secret
URL del carico di lavoro ed endpoint HTTP(S) URL assegnati automaticamente
Integrazioni di Cloud Run con i prodotti Google Cloud
Sessioni fisse (utilizzando un bilanciatore del carico esterno) Affinità sessione
Qualificatori 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 ogni richiesta in parallelo. Tuttavia, Cloud Run ti consente di impostare il numero di richieste in parallelo che un'istanza può gestire. In altre parole, il comportamento di provisioning di AWS Lambda è equivalente all'impostazione del numero massimo di richieste simultanee per istanza su 1 in Cloud Run. Impostare il numero massimo di richieste in parallelo su più di 1 può farti risparmiare notevolmente sui 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 di cui hai bisogno per i carichi di lavoro 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 tuoi workload Cloud Run.

Questa sezione mette in evidenza i controlli di sicurezza e di accesso disponibili in Cloud Run. Queste informazioni ti aiutano a capire come funzioneranno i carichi di lavoro sottoposti a 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 offerte da Cloud Run, utilizza le seguenti risorse:

Per aiutarti a capire quali controlli di sicurezza e di accesso di Cloud Run sono paragonabili a quelli disponibili in AWS Lambda, utilizza la tabella seguente. Per ogni risorsa Cloud Run che devi eseguire il provisioning, assicurati di scegliere i controlli di accesso e le funzionalità di sicurezza giusti.

Funzionalità AWS Lambda Funzionalità Cloud Run
Controllo dell'accesso con l'accesso e la gestione delle identità AWS Controllo dell'accesso con IAM di Google Cloud
Ruolo di esecuzione Ruolo IAM di Google Cloud
Limiti di autorizzazione Autorizzazioni IAM e segmenti di pubblico personalizzati di Google Cloud
Controlli di governance Servizio Criteri dell'organizzazione
Firma del codice Autorizzazione binaria
Accesso completo alla VPC Controlli granulari dell'accesso in uscita della VPC

Provisioning e configurazione delle risorse Cloud Run

Dopo aver scelto le risorse Cloud Run per eseguire 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:

Esegui il refactoring dei carichi di lavoro AWS Lambda

Per eseguire la migrazione dei carichi di lavoro AWS Lambda a Cloud Run, potresti doverli eseguire il refactoring. Ad esempio, se un carico di lavoro basato su eventi accetta trigger che contengono eventi Amazon CloudWatch, potrebbe essere necessario eseguire il refactoring del carico di lavoro per farlo accettare gli eventi nel formato CloudEvents.

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

  • Architettura. Valuta come è progettato il carico di lavoro in termini di architettura. Ad esempio, i carichi di lavoro AWS Lambda che hanno distinto chiaramente la logica di business dalla logica per accedere alle API specifiche di AWS potrebbero richiedere meno refactoring rispetto ai carichi di lavoro in cui le due logiche sono miste.
  • Idempotenza. Valuta se il carico di lavoro è idempotente in relazione ai suoi input. Un carico di lavoro idempotente per gli input potrebbe richiedere meno refactoring rispetto ai carichi di lavoro che devono mantenere lo stato degli input già elaborati.
  • 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 ulteriori informazioni sui servizi supportati da Cloud Run per archiviare i dati, consulta Opzioni di archiviazione di Cloud Run.
  • Ambiente di runtime. Valuta se il carico di lavoro fa alcune supposizioni sul proprio ambiente di runtime. Per questi tipi di carichi di lavoro, potrebbe essere necessario soddisfare le stesse ipotesi nell'ambiente di runtime Cloud Run o eseguire il refactoring del carico di lavoro se non puoi fare lo stesso per l'ambiente di runtime Cloud Run. Ad esempio, se un carico di lavoro richiede la disponibilità di determinati pacchetti o librerie, devi installarli nell'ambiente di runtime Cloud Run che lo ospiterà.
  • Iniezione di configurazione. Valuta se il carico di lavoro supporta l'utilizzo di variabili di ambiente e secret per iniettare (impostare) la relativa configurazione. Un workload che supporta questo tipo di inserimento potrebbe richiedere meno refactoring rispetto ai workload che supportano altri meccanismi di inserimento di configurazione.
  • API. Valuta se il carico di lavoro interagisce con le API AWS Lambda. Un carico di lavoro 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 l'output standard e gli stream di errori. Un carico di lavoro che genera questo tipo di segnalazione di errori potrebbe richiedere meno refactoring rispetto ai carichi di lavoro che segnalano gli errori utilizzando altri meccanismi.

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

Ristrutturare i processi di deployment e operativi

Dopo aver sottoposto a refactoring i carichi di lavoro, esegui il refactoring delle procedure di deployment e operative per:

  • Esegui il provisioning e la configurazione delle risorse nel tuo ambiente Google Cloud instead of provisioning resources in your source environment.
  • Crea e configura i carichi di lavoro ed esegui il loro deployment in Google Cloud instead of in the source environment.

Hai raccolto informazioni su queste procedure durante la fase di valutazione in precedenza in questa procedura.

Il tipo di refactoring da prendere in considerazione per queste procedure dipende da come le hai progettate e implementate. Il refactoring dipende anche da quale stato finale vuoi per ogni processo. Ad esempio, prendi in considerazione quanto indicato di seguito:

  • Potresti aver implementato queste procedure nel tuo ambiente di origine e intendi progettare e implementare procedure simili in Google Cloud. Ad esempio, puoi eseguire il refactoring di queste procedure per utilizzare Cloud Build, Cloud Deploy e Infrastructure Manager.
  • Potresti aver implementato queste procedure in un altro ambiente di terze parti al di fuori dell'ambiente di origine. In questo caso, devi eseguire il refactoring di queste procedure in modo che abbiano 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 un impegno significativo. Se provi a eseguire queste attività nell'ambito della migrazione del workload, la migrazione del workload può diventare più complessa e può esporre a rischi. Dopo aver valutato i processi di implementazione e operativi, probabilmente hai compreso il loro design e la loro complessità. Se ritieni di dover impiegare molto impegno per eseguire il refactoring delle procedure di implementazione e operative, ti consigliamo di valutare la possibilità di eseguire il refactoring di queste procedure nell'ambito di un progetto dedicato e separato.

Per ulteriori informazioni su come progettare e implementare i processi di deployment su Google Cloud, consulta:

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

  1. Esegui il provisioning dei repository di elementi su Google Cloud. Ad esempio, puoi utilizzare Artifact Registry per archiviare gli artefatti e creare dipendenze.
  2. Esegui il refactoring delle procedure di compilazione per archiviare gli artefatti sia nell'ambiente di origine sia in Artifact Registry.
  3. Esegui il refactoring delle procedure di deployment per distribuire i carichi di lavoro nell'ambiente Google Cloud di destinazione. Ad esempio, puoi iniziare a eseguire il deployment di un piccolo sottoinsieme dei tuoi workload in Google Cloud utilizzando gli elementi archiviati in Artifact Registry. Poi, aumenta gradualmente il numero di workload di cui viene eseguito il deployment in Google Cloud, fino a quando tutti i workload di cui vuoi eseguire la migrazione non vengono eseguiti su Google Cloud.
  4. Esegui il refactoring delle procedure di compilazione per archiviare gli artefatti solo in Artifact Registry.
  5. Se necessario, esegui la migrazione delle versioni precedenti degli elementi da eseguire il deployment dai repository nell'ambiente di origine ad Artifact Registry. Ad esempio, puoi copiare le immagini container in Artifact Registry.
  6. Esegui la disattivazione dei repository nell'ambiente di origine quando non li necessiti più.

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

Sebbene potrebbe non essere fondamentale per la riuscita di una migrazione, potresti dover eseguire la migrazione delle versioni precedenti degli elementi dall'ambiente di origine ai repository di elementi su Google Cloud. Ad esempio, per supportare il rollback dei workload a punti in tempo arbitrari, potresti dover eseguire la migrazione delle versioni precedenti degli elementi in Artifact Registry. Per ulteriori informazioni, consulta Eseguire la migrazione delle immagini da un registry di terze parti.

Se utilizzi Artifact Registry per archiviare gli elementi, ti consigliamo di configurare i controlli per proteggere i repository degli elementi, ad esempio il controllo dell'accesso dell'accesso, la prevenzione dell'esfiltrazione di dati, analisi delle vulnerabilità e l'Autorizzazione binaria. Per ulteriori informazioni, consulta Controllare l'accesso e proteggere gli elementi.

Ristrutturare i processi operativi

Nell'ambito della migrazione a Cloud Run, ti consigliamo di eseguire il refactoring delle tue procedure operative 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 di questo processo dovrebbe averti aiutato a determinare se i workload AWS Lambda di cui stai eseguendo la migrazione dipendono da o producono dati che si trovano 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 ulteriori informazioni sulla migrazione dei dati da AWS a Google Cloud, consulta Eseguire la migrazione da AWS a Google Cloud: iniziare.

Come per il refactoring delle procedure di implementazione e operative, la migrazione dei dati da AWS a Google Cloud può essere complessa e richiedere uno sforzo significativo. Se provi a eseguire queste attività di migrazione dei dati nell'ambito della migrazione dei carichi di lavoro AWS Lambda, la migrazione può diventare complessa e può esporre a rischi. Dopo aver analizzato i dati di cui eseguire la migrazione, probabilmente avrai compreso le dimensioni e la complessità dei dati. Se ritieni di dover impiegare molto impegno per eseguire la migrazione di questi dati, ti consigliamo di valutare la possibilità di eseguire la migrazione dei dati nell'ambito di un progetto dedicato e distinto.

Convalida i risultati della migrazione

La convalida della migrazione del carico di lavoro non è un evento una tantum, ma un processo continuo. Devi mantenere l'attenzione su test e convalida prima, durante e dopo la migrazione da AWS Lambda a Cloud Run.

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

  • Prima di iniziare la fase di migrazione, esegui il refactoring dei casi di test esistenti in modo da tenere conto dell'ambiente Google Cloud di destinazione.
  • Durante la migrazione, convalida i risultati dei test a ogni traguardo della migrazione e esegui test di integrazione approfonditi.
  • Dopo le migrazioni, esegui i seguenti test:
    • Test di riferimento: stabilisci benchmark sul rendimento del workload originale su AWS Lambda, ad esempio tempo di esecuzione, utilizzo delle risorse e tassi di errore in condizioni di carico diverse. Riproduci questi test su Cloud Run per identificare discrepanze che potrebbero indicare problemi di migrazione o configurazione.
    • Test di funzionalità: assicurati che la logica di base dei carichi di lavoro rimanga coerente creando ed eseguendo casi 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 il tuo 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 il tuo ambiente, i tuoi team e il tuo ciclo di ottimizzazione attuale.
  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 raggiungi i tuoi obiettivi di ottimizzazione.

Per ulteriori informazioni sull'ottimizzazione dell'ambiente Google Cloud, consulta Esegui la migrazione a Google Cloud: ottimizza l'ambiente e Procedura di ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: