Questo documento può aiutarti a pianificare, progettare e implementare la fase di valutazione della migrazione a Google Cloud. Scoprire l'inventario dei carichi di lavoro e dei servizi e mapparne le dipendenze può aiutarti a identificare cosa è necessario eseguire la migrazione e in quale ordine. Quando pianifichi e progetti una migrazione in Google Cloud, devi prima avere una conoscenza approfondita del tuo ambiente attuale e dei carichi di lavoro di cui eseguire la migrazione.
Questo documento fa parte della seguente serie in più parti sulla migrazione a Google Cloud:
- Eseguire la migrazione a Google Cloud: inizia
- Esegui la migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro (questo documento)
- Esegui la migrazione a Google Cloud: pianifica e crea la tua base
- Eseguire la migrazione a Google Cloud: trasferire i set di dati di grandi dimensioni
- Eseguire la migrazione a Google Cloud: esegui il deployment dei carichi di lavoro
- Esegui la migrazione a Google Cloud: migrazione dai deployment manuali a quelli containerizzati e automatici
- Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente
- Esegui la migrazione a Google Cloud: best practice per convalidare un piano di migrazione
- Esegui la migrazione a Google Cloud: riduci al minimo i costi
Il seguente diagramma illustra il percorso del tuo percorso di migrazione.
Questo documento è utile se stai pianificando una migrazione da un ambiente on-premise, da un ambiente di hosting privato, da un altro provider cloud o se stai valutando la possibilità di eseguire la migrazione ed esaminando la fase di valutazione.
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à:
- Crea un inventario completo dei tuoi workload.
- Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
- Forma e istruisci i tuoi team su Google Cloud.
- Crea esperimenti e proof of concept su Google Cloud.
- Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
- Scegli la strategia di migrazione per i tuoi workload.
- Scegli gli strumenti di migrazione.
- Definisci il piano e le tempistiche della migrazione.
- 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 workload e appliance hardware, esistono nel tuo ambiente attuale, insieme alle relative dipendenze. La creazione dell'inventario è un'attività non banale che richiede un impegno significativo, soprattutto se non hai implementato un sistema di catalogazione automatica. Per avere un inventario completo, devi utilizzare la competenza 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 solo ai workload, ma deve almeno contenere quanto segue:
- Dipendenze di ogni carico di lavoro, 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 e deployment continui (CI/CD) e repository di elementi.
- Server, virtuali o fisici, ed ambienti di runtime.
- Appliance fisici, come dispositivi di rete, firewall e altro hardware dedicato.
Quando compili questo elenco, devi anche raccogliere informazioni su ogni articolo, tra cui:
- Posizione del codice sorgente e se puoi modificarlo.
- Metodo di deployment del workload in un ambiente di runtime, ad esempio se utilizzi una pipeline di deployment automatica o manuale.
- Restrizioni di rete o requisiti di sicurezza.
- Requisiti per gli indirizzi IP.
- Come esponi il carico di lavoro ai clienti.
- Requisiti di licenza per qualsiasi software o hardware.
- La modalità di autenticazione del carico di lavoro rispetto al sistema di gestione di identità e accessi.
Ad esempio, per ogni appliance hardware, devi conoscere le specifiche dettagliate, come il nome, il fornitore, le tecnologie e le dipendenze da altri articoli nell'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 ai sensi dei quali puoi utilizzare ogni elemento e eventuali altri requisiti di conformità. Sebbene alcune licenze ti consentano di eseguire il deployment di un carico di lavoro in un ambiente cloud, altre vietano esplicitamente il deployment sul cloud. Alcune licenze vengono assegnate in base al numero di CPU o socket in uso e questi concetti potrebbero non essere applicabili quando l'esecuzione avviene su tecnologia cloud. Alcuni dei tuoi dati potrebbero avere limitazioni relative alla regione geografica in cui sono archiviati. Infine, alcuni carichi di lavoro sensibili possono richiedere la proprietà esclusiva.
Oltre all'inventario, è utile fornire ausili per un'interpretazione visiva dei dati raccolti. Ad esempio, puoi fornire un grafico di dipendenza e grafici per evidenziare aspetti di interesse, ad esempio la modalità di distribuzione dei carichi di lavoro in un processo di implementazione automatico o manuale.
Come creare l'inventario
Esistono diversi modi per creare un inventario dei carichi di lavoro. Sebbene il modo più rapido per iniziare sia 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'operazione una tantum. Se il tuo ambiente attuale è molto dinamico, ti consigliamo di automatizzare anche 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 delle risorse.
Esempio di inventario dei carichi di lavoro
Questo esempio è un inventario di un ambiente che supporta un'app di e-commerce. L'inventario include carichi di lavoro, dipendenze, servizi che supportano più carichi di lavoro e appliance hardware.
Carichi di lavoro
Per ogni carico di lavoro nell'ambiente, la tabella seguente evidenzia le tecnologie più importanti, la procedura di implementazione 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 | Carico di lavoro proprietario | Fornitore X Modello Y Versione 1.2.0 |
Manuale | I dati dei clienti devono trovarsi all'interno dell'Unione Europea | Database SQL | 10 core CPU 32 GB di RAM |
| Enterprise Resource Planning (ERP) | Carico di lavoro proprietario | Fornitore Z, modello C, versione 7.0 | Manuale | N/D | Database SQL | 10 core CPU 32 GB di RAM |
| Microservizi senza stato | Repository aziendale | Java | Automatico | N/D | Servizio di memorizzazione nella cache | 4 core CPU 8 GB di RAM |
Dipendenze
La tabella seguente è 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 trovarsi 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 elementi 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 contiene le seguenti appliance hardware:
| Nome | Tecnologie | Altri requisiti | Dipendenze | Requisiti delle risorse di sistema |
|---|---|---|---|---|
| Firewall | Fornitore H Modello V |
N/D | N/A | N/D |
| Istanze del 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/A | N/D |
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.
Valuta la tua infrastruttura
Dopo aver valutato le procedure di deployment e operative, ti consigliamo di valutare l'infrastruttura che supporta i tuoi 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 tra loro, ad esempio organizzazioni, progetti e spazi dei nomi.
- Come hai collegato il tuo ambiente ad altri ambienti, ad esempio ambienti on-premise e altri provider cloud.
Classifica i carichi di lavoro
Dopo aver completato l'inventario, devi organizzare i carichi di lavoro in categorie diverse. Questa classificazione può aiutarti a dare la priorità ai carichi di lavoro da migrare in base alla loro complessità e al rischio di migrazione al cloud.
Una matrice di cataloghi deve avere una dimensione per ogni criterio di valutazione preso in considerazione nel tuo ambiente. Scegli un insieme di criteri che copra tutti i requisiti del tuo ambiente, incluse le risorse di sistema di cui ha bisogno ogni carico di lavoro. 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 l'utilizzo di più matrici più piccole anziché una singola matrice complessa.
Inoltre, accanto a ogni carico di lavoro devi aggiungere un indicatore della complessità della migrazione. Questo indicatore stima la valutazione della difficoltà per la migrazione di ogni carico di lavoro. La granularità di questo indicatore dipende dal tuo ambiente. Ad esempio, potresti avere tre categorie: facile da eseguire la migrazione, difficile da eseguire la migrazione o non è possibile eseguire la migrazione. Per completare questa attività, hai bisogno di esperti per ogni elemento dell'inventario per stimarne la complessità di migrazione. I fattori che determinano questa complessità di migrazione sono unici per ogni attività.
Una volta completato il catalogo, puoi anche creare immagini e grafici per aiutare te e il tuo team a valutare rapidamente le metriche di tuo interesse. Ad esempio, disegna un grafico che metta in evidenza il numero di componenti con dipendenze o la difficoltà di migrazione di ciascun componente.
Per informazioni su come creare un inventario dei tuoi carichi di lavoro, consulta Centro di migrazione: avviare il rilevamento delle risorse.
Esempio di catalogo dei carichi di lavoro
In questo esempio vengono utilizzati i seguenti criteri di valutazione, uno per ogni asse della matrice:
- Il grado di criticità di un carico di lavoro per l'azienda.
- Indica se un carico di lavoro ha dipendenze o è una dipendenza per altri carichi di lavoro.
- Tempo di riposo massimo consentito per il carico di lavoro.
- La difficoltà di migrazione di un carico di lavoro.
| Importanza per l'attività | Non ha dipendenze o elementi dipendenti | Ha dipendenze o elementi dipendenti | Tempo di inattività massimo consentito | Difficoltà |
|---|---|---|---|---|
| Mission critical | Microservizi senza stato | 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:
Nel grafico precedente, la maggior parte dei carichi di lavoro è facile da spostare, tre sono difficili da spostare e uno non è possibile spostare.
Informare 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 account di prova gratuita di Google Cloud contenenti crediti per sperimentare e imparare. La creazione di un ambiente libero per test e apprendimento è fondamentale per l'esperienza di apprendimento del personale.
Hai a disposizione diverse opzioni di addestramento:
- Risorse pubbliche e aperte: puoi iniziare a imparare su Google Cloud con laboratori pratici, serie di video, webinar Cloud OnAir e eventi di formazione Cloud OnBoard gratuiti.
- Corsi approfonditi: se vuoi comprendere meglio il funzionamento di Google Cloud, puoi seguire i corsi on demand di Google Cloud Skills Boost o le specializzazioni di formazione Google Cloud di Coursera che puoi seguire online al tuo ritmo oppure la formazione in aula dei nostri partner di formazione autorizzati in tutto il mondo. Questi corsi in genere coprono da uno a diversi giorni.
- Percorsi di apprendimento basati sui ruoli: puoi formare i tuoi tecnici in base al loro ruolo nella tua organizzazione. Ad esempio, puoi insegnare ai tuoi sviluppatori di carichi di lavoro o operatori dell'infrastruttura come utilizzare al meglio i servizi Google Cloud.
Puoi anche certify la conoscenza di Google Cloud dei tuoi ingegneri con varie certificazioni, a diversi livelli:
- Certificazioni associate: un punto di partenza per chi è alle prime armi con Google Cloud che può aprire le porte alle certificazioni professionali, come la certificazione Associate Cloud Engineer.
- Certificazioni professionali: se vuoi valutare le competenze avanzate di progettazione e implementazione per Google Cloud basate su anni di esperienza, puoi ottenere certificazioni come Professional Cloud Architect o Professional Data Engineer.
- Certificazioni Google Workspace: puoi dimostrare le tue competenze di collaborazione utilizzando gli strumenti di Google Workspace con una certificazione Google Workspace.
- Certificazioni Apigee: con la certificazione di sviluppatore API certificato di Apigee, puoi dimostrare la capacità di progettare e sviluppare API affidabili, sicure e scalabili.
- Certificazioni per sviluppatori Google: puoi dimostrare le tue competenze di sviluppo con le certificazioni Sviluppatore Android associato (questa certificazione è in fase di aggiornamento) e Specialista web mobile.
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.
Sperimenta e progetta proof of concept
Per dimostrare il valore e l'efficacia di Google Cloud, ti consigliamo di progettare e sviluppare uno o più proof of concept (PoC) per ogni categoria di carico di lavoro nel tuo catalogo dei carichi di lavoro. La sperimentazione e i test ti consentono di convalidare le ipotesi e di dimostrare il valore del cloud ai responsabili aziendali.
Il PoC deve includere almeno quanto segue:
- Un elenco completo dei casi d'uso supportati dai tuoi carichi di lavoro, inclusi quelli insoliti e i casi limite.
- Tutti i requisiti per ogni caso d'uso, ad esempio requisiti di prestazioni, scalabilità e coerenza, meccanismi di failover e requisiti di rete.
- Un potenziale elenco 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à precisi.
Ad esempio, se uno dei tuoi carichi di lavoro legati alla CPU deve essere scalato rapidamente per soddisfare i picchi di domanda, puoi eseguire un esperimento per verificare che una zona possa creare molti core della CPU virtuale e il tempo necessario per farlo. Se riscontri un valore aggiunto significativo, ad esempio la riduzione del 95% del tempo di scalabilità del nuovo carico di lavoro rispetto al tuo ambiente attuale, questo esperimento può dimostrare un valore commerciale immediato.
Se vuoi valutare il confronto delle prestazioni dei tuoi database on-premise con Cloud SQL, Spanner, Firestore o Bigtable, potresti implementare un PoC in cui la stessa logica di business utilizza database diversi. Questo PoC ti offre un'opportunità a basso rischio per identificare la soluzione di database gestita giusta per il tuo carico di lavoro in 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, come PerfKit Benchmarker, e confrontare Google Cloud con altri provider cloud. Puoi misurare il tempo end-to-end per il provisioning delle risorse nel cloud, oltre a generare report sulle metriche standard del picco di prestazioni, tra cui latenza, throughput e tempo di completamento. Ad esempio, potresti essere interessato a sapere quanto tempo e impegno sono necessari per eseguire 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 costo, devi considerare non solo i costi per hardware e software, ma anche tutti i costi operativi per la 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 risorse di Google 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 dell'infrastruttura di rete, come router e switch, e l'installazione del 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 essere fatturato per l'utilizzo della rete. Per i workload ad alta intensità di dati o quelli che generano una grande quantità 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 una vasta gamma di opzioni per il ridimensionamento 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 creare gruppi di istanze con scalabilità automatica. Queste opzioni possono avere un grande impatto sui costi di gestione dei servizi e devono essere prese in considerazione per calcolare il costo totale di proprietà (TCO).
Per calcolare il costo totale delle risorse Google Cloud, puoi utilizzare il calcolatore dei 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 riposo o perdita di dati, ad esempio i carichi di lavoro di importanza fondamentale. Per questi carichi di lavoro, puoi scegliere strategie di migrazione con tempi di riposo nulli o quasi nulli.
- Tolerano i tempi di riposo, ad esempio i carichi di lavoro secondari o di backend. Per questi workload, puoi scegliere strategie di migrazione che richiedono un tempo di riposo.
Quando scegli le strategie di migrazione, tieni presente che quelle con tempi di riposo nulli o quasi sono in genere più costose e complesse da progettare e implementare rispetto a quelle che richiedono un tempo di riposo.
Scegli gli strumenti di migrazione
Dopo aver scelto una strategia di migrazione per i tuoi carichi di lavoro, esamina e scegli gli strumenti di migrazione.
Sono disponibili molti strumenti di migrazione, ognuno ottimizzato per determinati casi d'uso. I casi d'uso possono includere:
- Strategia di migrazione
- Ambienti di origine e di destinazione
- Dimensioni dei dati e del carico di lavoro
- Frequenza delle modifiche ai dati e ai carichi di lavoro
- Disponibilità di utilizzare i servizi gestiti per la migrazione
Per garantire una migrazione e un passaggio 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 semplificare il processo di trasferimento di dati, workload o persino intere infrastrutture da un ambiente all'altro. Con queste funzionalità, incapsulano la complessa logica della migrazione e offrono funzionalità di monitoraggio della migrazione.
Definisci il piano e le tempistiche della migrazione
Ora che hai una visione completa del tuo ambiente attuale, devi completare il piano di migrazione:
- Raggruppare i carichi di lavoro e i dati di cui eseguire la migrazione in lotti (chiamati anche sprint in alcuni contesti).
- Scegli l'ordine in cui vuoi eseguire la migrazione dei batch.
- Scegli 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, acquisisci slancio con la migrazione e comprendi il tuo ambiente, puoi:
- Perfeziona il raggruppamento dei carichi di lavoro e dei dati da migrare.
- Aumentare 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 carichi di lavoro e i dati di cui eseguire la migrazione in batch e per definire l'ordine della migrazione, valuta i carichi di lavoro in base a diversi criteri, ad esempio:
- Valore aziendale del carico di lavoro.
- Se il carico di lavoro viene implementato o eseguito in modo unico rispetto al resto della tua infrastruttura.
- Team responsabili dello sviluppo, del deployment e delle operazioni del caricamento di lavoro.
- Numero, tipo e ambito delle dipendenze del carico di lavoro.
- Lo sforzo di refactoring per far funzionare il carico di lavoro nel nuovo ambiente.
- Requisiti di conformità e licenze del carico di lavoro.
- Requisiti di disponibilità e affidabilità del carico di lavoro.
I workload 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 un'esperienza più ampia del tuo team possono ridurre il rischio di complicazioni durante la fase di migrazione e semplificare e velocizzare le migrazioni successive. Per questo motivo, scegliere i primi utenti giusti è fondamentale per una migrazione di successo.
valore aziendale
La scelta di un carico di lavoro non fondamentale per l'attività protegge la tua attività principale e riduce l'impatto sugli errori e sui rischi non scoperti mentre il tuo team apprende le tecnologie cloud. Ad esempio, se scelgo come primo attore il componente in cui è implementata la logica principale delle transazioni finanziarie del tuo carico di lavoro di e-commerce, qualsiasi errore durante la migrazione potrebbe avere un impatto sulla tua attività principale. Una scelta migliore è il database SQL che supporta i tuoi carichi di lavoro o, meglio ancora, il database intermediato.
Evita 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'impulso della migrazione e può essere difficile rilevare e rispondere ai problemi.
Casi limite
Inoltre, dovresti evitare i casi limite, in modo da scoprire schemi che puoi applicare ad altri carichi di lavoro di cui eseguire la migrazione. Uno degli obiettivi principali nella scelta di un primo attore è acquisire esperienza con i pattern comuni della tua organizzazione in modo da poter creare una knowledge base. Puoi applicare ciò che hai appreso con questi early adopter quando esegui la migrazione dei carichi di lavoro futuri.
Ad esempio, se la maggior parte dei tuoi carichi di lavoro è progettata seguendo una metodologia di sviluppo guidato dai test e viene sviluppata utilizzando il linguaggio di programmazione Python, scegliere 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 primi utenti, presta attenzione ai team responsabili di ogni carico di lavoro. Il team responsabile di un early adopter 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 early adopter e lavorare attivamente per sponsorizzarli e supportarli durante la procedura.
Ad esempio, un team di alto rendimento che si trova nella sede principale con una comprovata storia di implementazione di pratiche di sviluppo moderne come DevOps e discipline come l'ingegneria di affidabilità del sito può essere un buon candidato. Se ha anche sponsor di leadership dall'alto verso il basso e obiettivi chiari per ogni migrazione dei carichi di lavoro, può essere un candidato eccezionale.
Dipendenze
Inoltre, devi concentrarti sui carichi di lavoro con il minor numero di dipendenze, da altri carichi di lavoro 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 con dipendenze da altri componenti, scegli quelli con a basso accoppiamento alle dipendenze. Se un carico di lavoro è già progettato per l'eventuale mancata disponibilità delle relative dipendenze, può ridurre le difficoltà durante la migrazione al nuovo ambiente. Ad esempio, i candidati con a basso accoppiamento sono carichi di lavoro che comunicano utilizzando un broker di messaggi, che funzionano offline o che sono progettati per tollerare l'indisponibilità del resto dell'infrastruttura.
Sebbene esistano strategie per eseguire la migrazione dei dati dei carichi di lavoro con stato, un carico di lavoro senza stato richiede raramente la migrazione dei dati. La migrazione di un workload senza stato può essere più semplice perché non devi preoccuparti di una fase transitoria in cui i dati si trovano parzialmente nell'ambiente attuale e parzialmente nell'ambiente di destinazione. Ad esempio, i microservizi stateless sono buoni candidati per i primi utenti, perché non si basano su dati stateful locali.
Impegno di refactoring
Un early adopter dovrebbe richiedere una quantità minima di refactoring, in modo da poterti concentrare sulla migrazione stessa e su Google Cloud, anziché impegnarti molto per apportare 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 sull'ottimizzazione dei carichi di lavoro, che vengono affrontate nelle fasi successive della migrazione.
Ad esempio, un carico di lavoro che richiede solo modifiche alla configurazione è un buon primo passo, perché non devi implementare alcuna modifica al codice di base e puoi utilizzare gli elementi esistenti.
Licenze e conformità
Anche le licenze svolgono un ruolo nella scelta dei primi utenti, perché alcuni dei tuoi carichi di lavoro potrebbero essere concessi in licenza a termini che influiscono sulla migrazione. Ad esempio, alcune licenze vietano esplicitamente l'esecuzione di carichi di lavoro in un ambiente cloud.
Quando esamini i termini di licenza, non dimenticare i requisiti di conformità, poiché potresti avere requisiti di proprietà esclusiva per alcuni dei tuoi carichi di lavoro. Per questi motivi, come pionieri dovresti scegliere i workload con il minor numero di limitazioni di licenza e conformità.
Ad esempio, i tuoi clienti potrebbero avere il diritto legale di scegliere in quale regione archiviare i loro dati oppure i dati dei tuoi clienti potrebbero essere limitati a una determinata regione.
Disponibilità e affidabilità
I primi utenti che si adattano a questo tipo di cambiamento sono quelli che possono permettersi un tempo di riposo causato da una finestra di transizione. Se scegli un carico di lavoro 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, distoglie i team dall'acquisire l'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 riposo più lungo rispetto al carico di lavoro rivolto ai clienti del tuo sito di e-commerce in cui gli utenti finali completano le transazioni.
Convalidare il piano di migrazione
Prima di procedere con l'avvio del piano di migrazione, ti consigliamo di verificarne la fattibilità. Per ulteriori informazioni, consulta Best practice per convalidare un piano di migrazione.
Passaggi successivi
- Scopri come pianificare la migrazione e creare le basi su Google Cloud.
- Scopri quando richiedere assistenza per le migrazioni.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.
Collaboratori
Autore: Marco Ferrari | Cloud Solutions Architect