Esegui la migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro

Last reviewed 2024-08-02 UTC

Questo documento può aiutarti a pianificare, progettare e implementare la fase di valutazione della migrazione a Google Cloud. La scoperta dell'inventario dei tuoi workload e dei tuoi servizi e la mappatura delle loro dipendenze possono aiutarti a identificare cosa devi migrare e in quale ordine. Quando pianifichi e progetti una migrazione a Google Cloud, devi prima conoscere a fondo il tuo ambiente attuale e i carichi di lavoro da migrare.

Questo documento fa parte della seguente serie in più parti sulla migrazione a Google Cloud:

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

Percorso di migrazione con quattro fasi.

Questo documento è utile se stai pianificando una migrazione da un ambiente on-premise, da un ambiente di hosting privato, da un altro cloud provider o se stai valutando l'opportunità di eseguire la migrazione ed esplorando come potrebbe essere la fase di valutazione.

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.

Crea un inventario dei tuoi carichi di lavoro

Per definire l'ambito della migrazione, devi prima capire quanti elementi, come carichi di lavoro e appliance hardware, esistono nel tuo ambiente attuale, insieme alle loro dipendenze. La creazione dell'inventario è un'attività non banale che richiede un impegno significativo, soprattutto se non disponi di un sistema di catalogazione automatico. Per avere un inventario completo, devi utilizzare le competenze dei team responsabili della progettazione, del deployment e del funzionamento di ogni workload nel tuo ambiente attuale, nonché dell'ambiente stesso.

L'inventario non deve essere limitato ai soli workload, ma deve almeno contenere quanto segue:

  • Dipendenze di ogni workload, come database, broker di messaggi, sistemi di archiviazione della configurazione e altri componenti.
  • Servizi che supportano l'infrastruttura del tuo workload, come repository di origine, strumenti di integrazione continua e deployment continuo (CI/CD) e repository di artefatti.
  • Server, virtuali o fisici, e ambienti di runtime.
  • Apparecchiature fisiche, come dispositivi di rete, firewall e altro hardware dedicato.

Quando compili questo elenco, devi anche raccogliere informazioni su ogni elemento, tra cui:

  • La posizione del codice sorgente e se puoi modificarlo.
  • Metodo di deployment per il workload in un ambiente di runtime, ad esempio se utilizzi una pipeline di deployment automatizzata o manuale.
  • Restrizioni di rete o requisiti di sicurezza.
  • Requisiti per l'indirizzo IP.
  • Come esponi il workload ai client.
  • Requisiti di licenza per qualsiasi software o hardware.
  • Come il carico di lavoro esegue l'autenticazione rispetto al sistema di gestione di identità e accessi.

Ad esempio, per ogni appliance hardware, devi conoscere le specifiche dettagliate, come nome, fornitore, tecnologie e dipendenze da altri elementi dell'inventario. Ad esempio:

  • Nome: Appliance NAS
  • Fornitore e modello: Fornitore Y, Modello Z
  • Tecnologie: NFS, iSCSI
  • Dipendenze: connettività di rete con frame jumbo all'hardware di calcolo della VM.

Questo elenco deve includere anche informazioni non tecniche, ad esempio i termini di licenza in base ai quali è consentito utilizzare ogni elemento e qualsiasi altro requisito di conformità. Mentre alcune licenze ti consentono di eseguire il deployment di un workload in un ambiente cloud, altre lo vietano esplicitamente. Alcune licenze vengono assegnate in base al numero di CPU o socket in uso e questi concetti potrebbero non essere applicabili quando vengono eseguiti sulla tecnologia cloud. Alcuni dei tuoi dati potrebbero essere soggetti a limitazioni relative alla regione geografica in cui sono archiviati. Infine, alcuni carichi di lavoro sensibili possono richiedere un'unica tenancy.

Oltre all'inventario, è utile fornire ausili per un'interpretazione visiva dei dati raccolti. Ad esempio, puoi fornire un grafico delle dipendenze e grafici per evidenziare gli aspetti di interesse, ad esempio come vengono distribuite le tue risorse di lavoro in un processo di deployment automatizzato o manuale.

Come creare l'inventario

Esistono diversi modi per creare un inventario dei carichi di lavoro. Anche se il modo più rapido per iniziare è procedere manualmente, questo approccio può essere difficile per un ambiente di produzione di grandi dimensioni. Le informazioni negli inventari creati manualmente possono diventare rapidamente obsolete e la migrazione risultante potrebbe non riuscire perché non hai confermato i contenuti degli inventari.

La creazione dell'inventario non è un'attività una tantum. Se il tuo ambiente attuale è altamente dinamico, devi anche impegnarti ad automatizzare la creazione e la manutenzione dell'inventario, in modo da avere una visione coerente di tutti gli elementi del tuo ambiente in qualsiasi momento. Per informazioni su come creare un inventario dei tuoi carichi di lavoro, consulta Centro di migrazione: avviare il rilevamento degli asset.

Esempio di inventario dei carichi di lavoro

Questo esempio è un inventario di un ambiente che supporta un'app di e-commerce. L'inventario include workload, dipendenze, servizi che supportano più workload e appliance hardware.

Workload

Per ogni workload nell'ambiente, la tabella seguente evidenzia le tecnologie più importanti, la procedura di deployment e altri requisiti.

Nome Posizione del codice sorgente Tecnologie Procedura di deployment Altri requisiti Dipendenze Requisiti delle risorse di sistema
Sito web di marketing Repository aziendale Frontend Angular Automatico Il reparto legale deve convalidare i contenuti Servizio di memorizzazione nella cache 5 core CPU
8 GB di RAM
Back office Repository aziendale Backend Java, frontend Angular Automatico N/D Database SQL 4 core CPU
4 GB di RAM
Carico di lavoro e-commerce Workload proprietario Fornitore X
Modello Y
Versione 1.2.0		 Manuale I dati dei clienti devono risiedere all'interno dell'Unione Europea Database SQL 10 core CPU
32 GB di RAM
Enterprise Resource Planning (ERP) Workload proprietario Produttore Z, modello C, versione 7.0 Manuale N/D Database SQL 10 core CPU
32 GB di RAM
Microservizi stateless Repository aziendale Java Automatico N/D Servizio di memorizzazione nella cache 4 core CPU
8 GB di RAM

Dipendenze

La seguente tabella è un esempio delle dipendenze dei carichi di lavoro elencati nell'inventario. Queste dipendenze sono necessarie per il corretto funzionamento dei carichi di lavoro.

Nome Tecnologie Altri requisiti Dipendenze Requisiti delle risorse di sistema
Database SQL PostgreSQL I dati dei clienti devono risiedere all'interno dell'Unione Europea Sistema di backup e archiviazione 30 core CPU
512 GB di RAM

Servizi di supporto

Nel tuo ambiente, potresti avere servizi che supportano più carichi di lavoro. In questo esempio di e-commerce, sono presenti i seguenti servizi:

Nome Tecnologie Altri requisiti Dipendenze Requisiti delle risorse di sistema
Repository di codice sorgente Git N/D Sistema di backup e archiviazione 2 core CPU
4 GB di RAM
Sistema di backup e archiviazione Fornitore G, modello H, versione 2.3.0 Per legge, l'archiviazione a lungo termine è obbligatoria per alcuni elementi N/D 10 core CPU
8 GB di RAM
Strumento CI Jenkins N/D Repository di codice sorgente
repository di artefatti
sistema di backup e archiviazione		 32 core CPU
128 GB di RAM
Repository elementi Fornitore A
Modello N
Versione 5.0.0		 N/D Sistema di backup e archiviazione 4 core CPU
8 GB di RAM
Servizio di elaborazione batch Cron job in esecuzione all'interno dello strumento CI N/D Strumento CI 4 core CPU
8 GB di RAM
Servizio di memorizzazione nella cache Memcached
Redis		 N/D N/D 12 core CPU
50 GB di RAM

Hardware

L'ambiente di esempio ha le seguenti appliance hardware:

Nome Tecnologie Altri requisiti Dipendenze Requisiti delle risorse di sistema
Firewall Fornitore H
Modello V		 N/D N/D N/D
Istanze di Server j Fornitore K
Modello B		 Deve essere ritirato perché non è più supportato N/D N/D
Appliance NAS Fornitore Y
Modello Z
NFS
iSCSI		 N/D N/D N/D

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.

Valuta la tua infrastruttura

Dopo aver valutato i processi di deployment e operativi, ti consigliamo di valutare l'infrastruttura che supporta i carichi di lavoro nell'ambiente di origine.

Per valutare l'infrastruttura, tieni presente quanto segue:

  • Come hai organizzato le risorse nell'ambiente di origine. Ad esempio, alcuni ambienti supportano una separazione logica tra le risorse utilizzando costrutti che isolano gruppi di risorse l'uno dall'altro, come organizzazioni, progetti e spazi dei nomi.
  • Come hai connesso il tuo ambiente ad altri ambienti, ad esempio ambienti on-premise e altri cloud provider.

Categorizzare i carichi di lavoro

Dopo aver completato l'inventario, devi organizzare i tuoi workload in diverse categorie. Questa classificazione può aiutarti a dare la priorità ai carichi di lavoro da migrare in base alla loro complessità e al rischio di spostamento nel cloud.

Una matrice del catalogo deve avere una dimensione per ogni criterio di valutazione che stai prendendo in considerazione nel tuo ambiente. Scegli un insieme di criteri che copra tutti i requisiti del tuo ambiente, incluse le risorse di sistema necessarie per ogni workload. Ad esempio, potresti essere interessato a sapere se un workload ha dipendenze o se è stateless o stateful. Quando progetti la matrice del catalogo, tieni presente che per ogni criterio aggiunto, aggiungi un'altra dimensione da rappresentare. La matrice risultante potrebbe essere difficile da visualizzare. Una possibile soluzione a questo problema potrebbe essere quella di utilizzare più matrici più piccole, anziché una singola e complessa.

Inoltre, accanto a ogni carico di lavoro devi aggiungere un indicatore di complessità della migrazione. Questo indicatore stima il livello di difficoltà della migrazione di ogni workload. La granularità di questo indicatore dipende dal tuo ambiente. Per un esempio di base, potresti avere tre categorie: facile da migrare, difficile da migrare o non può essere migrato. Per completare questa attività, hai bisogno di esperti per ogni elemento dell'inventario per stimare la complessità della migrazione. I fattori che determinano questa complessità di migrazione sono unici per ogni attività.

Una volta completato il catalogo, puoi anche creare visualizzazioni e grafici per aiutare te e il tuo team a valutare rapidamente le metriche di interesse. Ad esempio, disegna un grafico che evidenzi il numero di componenti con dipendenze o la difficoltà di migrazione di ciascun componente.

Per informazioni su come creare un inventario dei tuoi workload, consulta Centro di migrazione: avviare il rilevamento degli asset.

Esempio di catalogo dei carichi di lavoro

In questo esempio vengono utilizzati i seguenti criteri di valutazione, uno per ogni asse della matrice:

  1. Quanto è critico un carico di lavoro per l'attività.
  2. Se un workload ha dipendenze o è una dipendenza per altri workload.
  3. Tempo di inattività massimo consentito per il workload.
  4. La difficoltà di migrazione di un carico di lavoro.
Importanza per l'attività Non ha dipendenze o elementi dipendenti Ha dipendenze o dipendenti Tempo di inattività massimo consentito Difficoltà
Mission critical Microservizi stateless 2 minuti Facile
ERP 24 ore Difficile
Carico di lavoro e-commerce Zero tempi di inattività Difficile
Firewall hardware Zero tempi di inattività Impossibile spostare
Database SQL 10 minuti Facile
Repository di codice sorgente 12 ore Facile
Non mission critical Sito web di marketing 2 ore Facile
Backup e archiviazione 24 ore Facile
Servizio di elaborazione batch 48 ore Facile
Servizio di memorizzazione nella cache 30 minuti Facile
Back office 48 ore Difficile
Strumento CI 24 ore Facile
Repository elementi 30 minuti Facile

Per aiutarti a visualizzare i risultati nel catalogo, puoi creare immagini e grafici. Il seguente grafico evidenzia la difficoltà della migrazione:

Grafico che visualizza la difficoltà associata allo spostamento dei carichi di lavoro in Google Cloud.

Nel grafico precedente, la maggior parte dei carichi di lavoro è facile da spostare, tre sono difficili da spostare e uno non è possibile spostarlo.

Informa la tua organizzazione su Google Cloud

Per sfruttare al meglio Google Cloud, la tua organizzazione deve iniziare a conoscere i servizi, i prodotti e le tecnologie che la tua attività può utilizzare su Google Cloud. Il tuo personale può iniziare con Google Cloud account di prova gratuiti che contengono crediti per aiutarli a sperimentare e imparare. Creare un ambiente gratuito per test e apprendimento è fondamentale per l'esperienza di apprendimento del tuo personale.

Hai a disposizione diverse opzioni di addestramento:

  1. Risorse pubbliche e aperte: puoi iniziare a imparare Google Cloud con i laboratori pratici, le serie di video, i webinar Cloud OnAir e gli eventi di formazione Cloud OnBoard.
  2. Corsi approfonditi: se vuoi comprendere meglio il funzionamento di Google Cloud , puoi seguire corsi on demand di Google Cloud Skills Boost o Google Cloud specializzazioni di formazione di Coursera che puoi seguire online al tuo ritmo oppure corsi in aula tenuti dai nostri partner di formazione autorizzati in tutto il mondo. Questi corsi in genere durano da uno a più giorni.
  3. Percorsi di apprendimento basati sui ruoli: Puoi formare i tuoi ingegneri in base al loro ruolo nell'organizzazione. Ad esempio, puoi formare gli sviluppatori di carichi di lavoro o gli operatori dell'infrastruttura su come utilizzare al meglio i servizi Google Cloud .

Puoi anche certify le competenze dei tuoi ingegneri Google Cloud con varie certificazioni, a diversi livelli:

  1. Certificazioni associate: un punto di partenza per chi non ha familiarità conGoogle Cloud che può aprire le porte alle certificazioni professionali, come la certificazione Associate Cloud Engineer.
  2. Certificazioni professionali: se vuoi valutare le competenze avanzate di progettazione e implementazione per Google Cloud maturate in anni di esperienza, puoi ottenere certificazioni come quella di Professional Cloud Architect o Professional Data Engineer.
  3. Certificazioni Google Workspace: puoi dimostrare le tue competenze di collaborazione utilizzando gli strumenti di Google Workspace con una certificazione Google Workspace.
  4. Certificazioni Apigee: con la certificazione di ingegnere API certificato Apigee, puoi dimostrare la tua capacità di progettare e sviluppare API robuste, sicure e scalabili.
  5. Certificazioni per sviluppatori Google: puoi dimostrare le tue competenze di sviluppo con le certificazioni Associate Android Developer (questa certificazione è in fase di aggiornamento) e Mobile Web Specialist.

Oltre alla formazione e alla certificazione, uno dei modi migliori per acquisire esperienza con Google Cloud è iniziare a utilizzare il prodotto per creare proof of concept aziendali.

Sperimentare e progettare proof of concept

Per dimostrare il valore e l'efficacia di Google Cloud, valuta la possibilità di progettare e sviluppare una o più prove di fattibilità per ogni categoria di carico di lavoro nel tuo catalogo dei carichi di lavoro. Gli esperimenti e i test ti consentono di convalidare le ipotesi e dimostrare il valore del cloud ai leader aziendali.

Come minimo, la prova di concetto deve includere quanto segue:

  • Un elenco completo dei casi d'uso supportati dai tuoi workload, inclusi quelli meno comuni e i casi limite.
  • Tutti i requisiti per ogni caso d'uso, come prestazioni, scalabilità e coerenza, meccanismi di failover e requisiti di rete.
  • Un elenco potenziale di tecnologie e prodotti che vuoi esaminare e testare.

Devi progettare PoC ed esperimenti per convalidare tutti i casi d'uso nell'elenco. Ogni esperimento deve avere un contesto di validità, un ambito, risultati previsti e un impatto misurabile sull'attività ben definiti.

Ad esempio, se uno dei tuoi carichi di lavoro vincolati alla CPU deve scalare rapidamente per soddisfare i picchi di domanda, puoi eseguire un esperimento per verificare che una zona possa creare molti core CPU virtuali e quanto tempo impiega per farlo. Se riscontri un valore aggiunto significativo, ad esempio la riduzione del tempo di scalabilità dei nuovi carichi di lavoro del 95% rispetto all'ambiente attuale, questo esperimento può dimostrare un valore aziendale immediato.

Se ti interessa valutare il confronto tra le prestazioni dei tuoi database on-premise e quelle di Cloud SQL, Spanner, Firestore, o Bigtable, potresti implementare una PoC in cui la stessa logica di business utilizza database diversi. Questa PoC ti offre un'opportunità a basso rischio per identificare la soluzione di database gestito più adatta al tuo workload in base a più benchmark e costi operativi.

Se vuoi valutare le prestazioni del processo di provisioning delle VM in Google Cloud, puoi utilizzare uno strumento di terze parti, ad esempio PerfKit Benchmarker, e confrontare Google Cloud con altri provider di servizi cloud. Puoi misurare il tempo end-to-end per il provisioning delle risorse nel cloud, oltre a generare report sulle metriche standard di picco delle prestazioni, tra cui latenza, velocità effettiva e tempo di completamento. Ad esempio, potresti essere interessato a quanto tempo e impegno richiede il provisioning di molti cluster Kubernetes. PerfKit Benchmarker è un progetto della community open source che coinvolge oltre 500 partecipanti, tra cui ricercatori, istituti accademici e aziende, tra cui Google.

Calcolare il costo totale di proprietà

Quando hai una visione chiara delle risorse di cui hai bisogno nel nuovo ambiente, puoi creare un modello di costo totale di proprietà che ti consenta di confrontare i costi su Google Cloud con quelli del tuo ambiente attuale.

Quando crei questo modello di costi, devi considerare non solo i costi per hardware e software, ma anche tutti i costi operativi di gestione del tuo data center, come alimentazione, raffreddamento, manutenzione e altri servizi di assistenza. Tieni presente che in genere è anche più facile ridurre i costi, grazie alla scalabilità elastica delle risorseGoogle Cloud , rispetto a un data center on-premise più rigido.

Un costo spesso trascurato quando si prendono in considerazione le migrazioni al cloud è l'utilizzo di una rete cloud. In un data center, l'acquisto di infrastrutture di rete, come router e switch, e il successivo cablaggio di rete appropriato sono costi una tantum che ti consentono di utilizzare l'intera capacità della rete. In un ambiente cloud, esistono molti modi in cui potresti ricevere la fatturazione per l'utilizzo della rete. Per i carichi di lavoro ad alta intensità di dati o quelli che generano un grande volume di traffico di rete, potresti dover prendere in considerazione nuove architetture e flussi di rete per ridurre i costi di networking nel cloud.

Google Cloud offre anche un'ampia gamma di opzioni per la scalabilità intelligente di risorse e costi. Ad esempio, in Compute Engine puoi eseguire il dimensionamento ottimale durante la migrazione con Migrate for Compute Engine, o dopo che le VM sono già in esecuzione, o durante la creazione di gruppi di istanze di scalabilità automatica. Queste opzioni possono avere un impatto significativo sui costi di esecuzione dei servizi e devono essere esaminate per calcolare il costo totale di proprietà (TCO).

Per calcolare il costo totale delle risorse Google Cloud , puoi utilizzare il Calcolatore prezzi.

Scegli la strategia di migrazione per i tuoi workload

Per ogni carico di lavoro da migrare, valuta e seleziona una strategia di migrazione più adatta al caso d'uso. Ad esempio, i tuoi carichi di lavoro potrebbero avere le seguenti condizioni:

  • Non tollerano tempi di inattività o perdita di dati, come i carichi di lavoro mission-critical. Per questi carichi di lavoro, puoi scegliere strategie di migrazione con tempi di inattività nulli o quasi nulli.
  • Tollerano i tempi di inattività, ad esempio i carichi di lavoro secondari o di backend. Per questi workload, puoi scegliere strategie di migrazione che richiedono un tempo di inattività.

Quando scegli le strategie di migrazione, tieni presente che quelle con tempi di inattività nulli o quasi nulli sono in genere più costose e complesse da progettare e implementare rispetto a quelle che richiedono un tempo di inattività.

Scegli gli strumenti di migrazione

Dopo aver scelto una strategia di migrazione per i tuoi carichi di lavoro, esamina e decidi gli strumenti di migrazione.

Sono disponibili molti strumenti di migrazione, ognuno ottimizzato per determinati casi d'uso della migrazione. I casi d'uso possono includere:

  • Strategia di migrazione
  • Ambienti di origine e di destinazione
  • Dimensioni dei dati e del workload
  • Frequenza delle modifiche ai dati e ai workload
  • Disponibilità di utilizzo di servizi gestiti per la migrazione

Per garantire una migrazione e un cutover senza problemi, puoi utilizzare pattern di deployment delle applicazioni, orchestrazione dell'infrastruttura e applicazioni di migrazione personalizzate. Tuttavia, strumenti specializzati chiamati servizi di migrazione gestita possono facilitare il processo di trasferimento di dati, workload o persino intere infrastrutture da un ambiente a un altro. Con queste funzionalità, incapsulano la complessa logica della migrazione e offrono funzionalità di monitoraggio della migrazione.

Definisci il piano di migrazione e le tempistiche

Ora che hai una visione esaustiva del tuo ambiente attuale, devi completare il piano di migrazione:

  1. Raggruppare i carichi di lavoro e i dati da migrare in batch (chiamati anche sprint in alcuni contesti).
  2. Scegliere l'ordine in cui vuoi eseguire la migrazione dei batch.
  3. Scegliere l'ordine in cui vuoi eseguire la migrazione dei workload all'interno di ogni batch.

Nell'ambito del piano di migrazione, ti consigliamo di produrre anche i seguenti documenti:

  • Documento di progettazione tecnica
  • Matrice RACI
  • Timeline (ad esempio, un piano T-Minus)

Man mano che acquisisci esperienza con Google Cloud, con la migrazione e con la comprensione del tuo ambiente, puoi:

  • Perfeziona il raggruppamento dei workload e dei dati da migrare.
  • Aumenta le dimensioni dei batch di migrazione.
  • Aggiorna l'ordine in cui esegui la migrazione dei batch e dei carichi di lavoro all'interno dei batch.
  • Aggiorna la composizione dei batch.

Per raggruppare i workload e i dati da migrare in batch e per definire l'ordine di migrazione, valuta i tuoi workload in base a diversi criteri, ad esempio:

  • Valore aziendale del workload.
  • Se il carico di lavoro viene implementato o eseguito in modo univoco rispetto al resto dell'infrastruttura.
  • Team responsabili dello sviluppo, dell'implementazione e delle operazioni del carico di lavoro.
  • Numero, tipo e ambito delle dipendenze del carico di lavoro.
  • Rimodellamento per far funzionare il workload nel nuovo ambiente.
  • Requisiti di conformità e licenza del workload.
  • Requisiti di disponibilità e affidabilità del carico di lavoro.

I carichi di lavoro di cui esegui la migrazione per primi sono quelli che consentono ai tuoi team di acquisire conoscenze ed esperienza su Google Cloud. Una maggiore esposizione al cloud e l'esperienza del tuo team possono ridurre il rischio di complicazioni durante la fase di migrazione e rendere le migrazioni successive più semplici e veloci. Per questo motivo, scegliere i primi utenti è fondamentale per una migrazione riuscita.

valore aziendale

La scelta di un carico di lavoro non fondamentale per l'attività protegge la tua attività principale e riduce l'impatto sull'attività di rischi ed errori non scoperti mentre il tuo team apprende le tecnologie cloud. Ad esempio, se scegli il componente in cui viene implementata la logica delle transazioni finanziarie principali del tuo carico di lavoro e-commerce come first mover, qualsiasi errore durante la migrazione potrebbe avere un impatto sulla tua attività principale. Una scelta migliore è il database SQL che supporta i tuoi workload o, ancora meglio, il database di staging.

Dovresti evitare i carichi di lavoro utilizzati raramente. Ad esempio, se scegli un carico di lavoro utilizzato solo poche volte all'anno da un numero ridotto di utenti, anche se si tratta di una migrazione a basso rischio, non aumenta l'avanzamento della migrazione e può essere difficile rilevare e risolvere i problemi.

Casi limite

Dovresti anche evitare i casi limite, in modo da poter scoprire pattern che puoi applicare ad altri carichi di lavoro da migrare. Un obiettivo principale quando si seleziona un primo trasferimento è acquisire esperienza con i pattern comuni nella tua organizzazione in modo da poter creare una knowledge base. Puoi applicare ciò che hai imparato con questi pionieri quando esegui la migrazione dei carichi di lavoro futuri in un secondo momento.

Ad esempio, se la maggior parte dei tuoi carichi di lavoro è progettata seguendo una metodologia di sviluppo basato sui test ed è sviluppata utilizzando il linguaggio di programmazione Python, la scelta di un carico di lavoro con una copertura dei test ridotta e sviluppato utilizzando il linguaggio di programmazione Java non ti consente di scoprire alcun pattern che puoi applicare durante la migrazione dei carichi di lavoro Python.

Team

Quando scegli i tuoi pionieri, presta attenzione ai team responsabili di ogni workload. Il team responsabile di un pioniere deve essere molto motivato e desideroso di provare Google Cloud e i suoi servizi. Inoltre, la leadership aziendale deve avere obiettivi chiari per i team pionieri e impegnarsi attivamente per sponsorizzarli e supportarli durante la procedura.

Ad esempio, un team con un rendimento elevato che lavora nella sede principale con una storia comprovata di implementazione di pratiche di sviluppo moderne come DevOps e discipline come l'ingegneria dell'affidabilità del sito può essere un buon candidato. Se hanno anche sponsor di leadership top-down e obiettivi chiari per la migrazione di ogni workload, possono essere un ottimo candidato.

Dipendenze

Inoltre, devi concentrarti sui workload con il minor numero di dipendenze, da altri workload o servizi. La migrazione di un carico di lavoro senza dipendenze è più semplice se hai poca esperienza con Google Cloud.

Se devi scegliere carichi di lavoro che hanno dipendenze da altri componenti, scegli quelli che sonoa basso accoppiamentoo alle loro dipendenze. Se un workload è già progettato per l'eventuale indisponibilità delle sue dipendenze, può ridurre le difficoltà durante la migrazione del workload all'ambiente di destinazione. Ad esempio, i candidati con a basso accoppiamento sono carichi di lavoro che comunicano utilizzando un message broker o che funzionano offline o sono progettati per tollerare l'indisponibilità del resto dell'infrastruttura.

Sebbene esistano strategie per la migrazione dei dati dei workload stateful, un workload stateless raramente richiede la migrazione dei dati. La migrazione di un carico di lavoro senza stato può essere più semplice perché non devi preoccuparti di una fase transitoria in cui i dati si trovano in parte nell'ambiente attuale e in parte in quello di destinazione. Ad esempio, i microservizi stateless sono buoni candidati per la migrazione iniziale, perché non si basano su dati stateful locali.

Impegno di refactoring

Un'app di tipo first-mover dovrebbe richiedere una quantità minima di refactoring, in modo da poterti concentrare sulla migrazione stessa e su Google Cloud, anziché dedicare un grande impegno alle modifiche al codice e alla configurazione dei tuoi carichi di lavoro. Il refactoring deve concentrarsi sulle modifiche necessarie per consentire l'esecuzione dei carichi di lavoro nell'ambiente di destinazione, anziché sulla modernizzazione e l'ottimizzazione dei carichi di lavoro, che vengono affrontate nelle fasi successive della migrazione.

Ad esempio, un workload che richiede solo modifiche alla configurazione è un buon primo passo, perché non devi implementare alcuna modifica al codebase e puoi utilizzare gli artefatti esistenti.

Licenze e conformità

Anche le licenze svolgono un ruolo nella scelta dei primi a eseguire la migrazione, perché alcuni dei tuoi carichi di lavoro potrebbero essere concessi in licenza in base a termini che influiscono sulla migrazione. Ad esempio, alcune licenze vietano esplicitamente l'esecuzione di workload in un ambiente cloud.

Quando esamini i termini di licenza, non dimenticare i requisiti di conformità perché potresti avere requisiti di tenancy esclusiva per alcuni dei tuoi carichi di lavoro. Per questi motivi, devi scegliere i workload con il minor numero di limitazioni di licenza e conformità come primi a essere spostati.

Ad esempio, i tuoi clienti potrebbero avere il diritto legale di scegliere in quale regione archiviare i propri dati oppure i dati dei tuoi clienti potrebbero essere limitati a una regione specifica.

Disponibilità e affidabilità

I primi a eseguire la migrazione sono quelli che possono permettersi un downtime causato da una finestra di cutover. Se scegli un workload con requisiti di disponibilità rigorosi, devi implementare una strategia di migrazione dei dati senza tempi di inattività, ad esempio Y (scrittura e lettura) o sviluppando un microservizio di accesso ai dati. Sebbene questo approccio sia possibile, distrae i tuoi team dall'acquisizione dell'esperienza necessaria con Google Cloud, perché devono dedicare tempo all'implementazione di queste strategie.

Ad esempio, i requisiti di disponibilità di un motore di elaborazione batch possono tollerare un tempo di inattività più lungo rispetto al workload rivolto ai clienti del tuo sito e-commerce in cui gli utenti finalizzano le transazioni.

Convalidare il piano di migrazione

Prima di intraprendere azioni per avviare il piano di migrazione, ti consigliamo di verificarne la fattibilità. Per saperne di più, consulta le Best practice per la convalida di un piano di migrazione.

Passaggi successivi

Collaboratori

Autore: Marco Ferrari | Cloud Solutions Architect