Questo documento può aiutarti a pianificare, progettare e implementare la fase di valutazione di la 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: iniziare
- Migrate to Google Cloud: valuta e scopri i tuoi carichi di lavoro (questo documento)
- Eseguire la migrazione a Google Cloud: pianifica e crea le basi
- Eseguire la migrazione a Google Cloud: trasferire 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 di un ambiente di hosting, un ambiente di hosting privato, un altro cloud provider o valutare l'opportunità di migrare ed esplorare ciò che la fase di valutazione potrebbe avere il suo aspetto.
Nella fase di valutazione, stabilisci i requisiti e le dipendenze eseguire la migrazione dell'ambiente di origine in Google Cloud.
La fase di valutazione è fondamentale per la buona riuscita della migrazione. Devi conoscere a fondo i carichi di lavoro di cui vuoi eseguire la migrazione, i loro requisiti dalle loro dipendenze e dal tuo ambiente attuale. Devi comprendere il tuo punto di partenza per pianificare ed eseguire con successo un progetto Google Cloud migrazione.
La fase di valutazione è composta dalle seguenti attività:
- Crea un inventario completo dei tuoi carichi di lavoro.
- Cataloga i carichi di lavoro in base alle loro proprietà e dipendenze.
- Addestra e forma 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 carichi di lavoro.
- Scegli i tuoi strumenti di migrazione.
- Definisci il piano di migrazione e le tempistiche.
- Convalida il piano di migrazione.
Creare un inventario dei 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, nonché le 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 l'esperienza dei team responsabili della progettazione, dell'implementazione operativo di ciascun carico di lavoro nel tuo ambiente attuale, dell'ambiente circostante.
L'inventario non deve essere limitato ai soli carichi di lavoro, ma deve almeno contengono quanto segue:
- Dipendenze di ogni carico di lavoro, come database, broker di messaggi, sistemi di archiviazione della configurazione e altri componenti.
- Servizi a supporto dell'infrastruttura dei carichi di lavoro, come l'origine integrazione e deployment continui (CI/CD) di strumenti e repository di artefatti.
- 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 per il carico di lavoro in un ambiente di runtime, per ad esempio nel caso di 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.
- Modalità di autenticazione del carico di lavoro rispetto alla gestione di identità e accessi di un sistema operativo completo.
Ad esempio, per ogni appliance hardware, è necessario conoscere la quali il nome, il fornitore, le tecnologie e le dipendenze ad altri elementi del tuo 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 computing delle VM.
Questo elenco deve includere anche informazioni non tecniche, ad esempio, i termini di licenza a cui puoi utilizzare ogni singolo articolo e qualsiasi altra conformità i tuoi requisiti. 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.
Insieme all'inventario, è utile fornire strumenti per una 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 divenire rapidamente obsoleti e la migrazione risultante potrebbe non riuscire perché Non ha confermato i contenuti dei tuoi inventari.
La creazione dell'inventario non è una procedura una tantum. Se il tuo ambiente attuale è altamente dinamico, dovresti anche dedicare sforzo all'automazione dello spazio pubblicitario creazione e manutenzione, in modo da avere una visione coerente di tutti più elementi nel tuo ambiente. Per informazioni su come creare un inventario dei tuoi carichi di lavoro, consulta Centro di migrazione: avviare una ricerca di asset.
Esempio di inventario dei carichi di lavoro
Questo esempio è l'inventario di un ambiente che supporta un'app di e-commerce. La L'inventario comprende carichi di lavoro, dipendenze, carichi di lavoro di lavoro ed appliance hardware.
Carichi di lavoro
Per ogni carico di lavoro nell'ambiente, la tabella seguente evidenzia tecnologie importanti, le relative procedure di implementazione e altri requisiti.
| Nome | Posizione del codice sorgente | Tecnologie | Procedura di deployment | Altri requisiti | Dipendenze | Requisiti delle risorse di sistema |
|---|---|---|---|---|---|---|
| Sito web 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 per l'e-commerce | Carico di lavoro 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) | 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 in l'inventario. Queste dipendenze sono necessarie affinché i carichi di lavoro personalizzata.
| 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 carichi di lavoro in esecuzione.
I processi di deployment e operativi potrebbero creare gli elementi necessari per il funzionamento dei carichi di lavoro. Pertanto, dovresti raccogliere informazioni su ogni tipo di artefatto. 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. Valutare i processi seguiti dai team di sviluppo dei carichi di lavoro. Ad esempio, in che modo i team di sviluppo progettando, programmando e testando i carichi di lavoro?
- Genera gli elementi da eseguire nel tuo ambiente di origine. A dei carichi di lavoro nell'ambiente di origine, potresti generare artefatti di cui è possibile eseguire il deployment, come immagini container o immagini del sistema operativo potresti personalizzare elementi esistenti, come la gestione le immagini di sistema installando e configurando il software. La raccolta di informazioni su come stai generando questi artefatti ti aiuta a per assicurarti che gli artefatti generati siano adatti al deployment in Google Cloud.
Archivia gli elementi. Se produci artefatti che archivi in un Artifact Registry nel tuo ambiente di origine, devi rendere gli artefatti 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 i processi di compilazione degli elementi nell'ambiente Google Cloud di destinazione nell'ambito della migrazione.
Scansiona e firma il codice. Nell'ambito dei processi di build degli artefatti, potresti utilizzando la scansione del codice per proteggerti dalle vulnerabilità comuni per evitare un'esposizione accidentale della rete e la firma del codice per garantire che il codice attendibile viene eseguito nei tuoi ambienti.
Esegui il deployment degli artefatti nell'ambiente di origine. Dopo la generazione artefatti di cui è possibile eseguire il deployment, potresti eseguirne il deployment nel tuo ambiente di origine. Ti consigliamo di valutare ogni processo di deployment. La valutazione 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 i tuoi processi di deployment funzionino solo con il tuo ambiente di origine, potresti doverne eseguire il refactoring definire come target il tuo ambiente Google Cloud.
Inserisci la configurazione di runtime. Potresti inserire la configurazione di runtime per cluster, ambienti di runtime o deployment di carichi di lavoro specifici. La configurazione potrebbe inizializzare le variabili di ambiente e altri valori di configurazione come secret, credenziali e chiavi. Per garantire che i tuoi i processi di iniezione della configurazione runtime funzionano su Google Cloud, ti consigliamo di valutare le modalità di configurazione dei carichi di lavoro in esecuzione dell'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 del cluster. Valuta la tua modalità di autenticazione rispetto al tuo dell'ambiente di origine.
Esegui il provisioning e configura le risorse. Per preparare la fonte: di progettazione e implementazione di processi che e configurare le risorse. Ad esempio, potresti utilizzare Terraform oltre a strumenti di gestione della configurazione per il provisioning e la configurazione delle risorse nel tuo ambiente di origine.
Valuta la tua infrastruttura
Dopo aver valutato il deployment e i processi operativi, è consigliabile valuti l'infrastruttura che supporta i tuoi carichi di lavoro dell'ambiente di origine.
Per valutare l'infrastruttura, tieni presente quanto segue:
- Come hai organizzato le risorse nell'ambiente di origine. Ad esempio, alcune supportano una separazione logica tra le risorse tramite i costrutti che isolano i gruppi di risorse l'uno dall'altro, come organizzazioni, progetti e spazi dei nomi.
- Come hai collegato il tuo ambiente ad altri ambienti, ad esempio ambienti on-premise e altri provider cloud.
Classificare i carichi di lavoro
Dopo aver completato l'inventario, devi organizzare i carichi di lavoro in diverse categorie. Questa categorizzazione può aiutarti a dare priorità ai carichi di lavoro di migrare in base alla loro complessità e al rischio connesso al passaggio al cloud.
Una matrice catalogo deve avere una dimensione per ogni criterio di valutazione che a valutare nel tuo ambiente. Scegli un insieme di criteri che coprano tutte le i requisiti del tuo ambiente, incluse le risorse di sistema e ciascun carico di lavoro, e alle esigenze aziendali. Ad esempio, potresti essere interessato a sapere se un carico di lavoro ha dipendenze o se è stateless o stateful. Quando progetti il catalogo , tieni presente che per ogni criterio che aggiungi, ne aggiungi un altro 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. Come esempio di base, potresti esistono tre categorie: facile da migrare, difficile da migrare o non può essere eseguita. 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 che e il tuo team per valutare rapidamente le metriche di interesse. Ad esempio, disegna un grafico che evidenzia quanti componenti hanno dipendenze o evidenziano di ogni componente.
Per informazioni su come creare un inventario dei tuoi carichi di lavoro, consulta Centro di migrazione: avviare una ricerca di asset.
Esempio di catalogo dei carichi di lavoro
In questo esempio vengono utilizzati i seguenti criteri di valutazione, uno per ogni matrice asse:
- Il livello 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 inattività massimo consentito per il carico di lavoro.
- La difficoltà di migrazione di un carico di lavoro.
| Importanza per l'attività | Non ha dipendenze o dipendenti | Ha dipendenze o elementi 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 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.
Fai conoscere Google Cloud alla tua organizzazione
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. Creazione di un di test e apprendimento è fondamentale per l'esperienza di apprendimento il personale.
Sono disponibili diverse opzioni di formazione:
- Risorse pubbliche e aperte: puoi iniziare a imparare Google Cloud con lab pratici, serie di video, Webinar Cloud OnAir, e Eventi di formazione Cloud OnBoard.
- 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 ingegneri in base al loro ruolo nella tua organizzazione. Ad esempio, puoi formare i tuoi sviluppatori di carichi di lavoro o operatori dell'infrastruttura sull'utilizzo ottimale dei servizi Google Cloud.
Puoi anche certificare 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 tue 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 piattaforma certificazione API engineer, dimostrare di saper progettare e sviluppare soluzioni solide, sicure e scalabili.
- Certificazioni Google Developers: puoi dimostrare competenze di sviluppo con Associa sviluppatore Android (Questa certificazione è in fase di aggiornamento) e specialista del web mobile certificazioni.
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 mostrare il valore e l'efficacia di Google Cloud, valuta la possibilità di progettare sviluppare una o più proof of concept (PDC) per ogni categoria di carico di lavoro in del 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 PDC 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 preciso di validità, l'ambito, risultati aziendali e un impatto aziendale misurabile.
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 una riduzione del 95% del tempo di scalabilità del nuovo carico di lavoro rispetto al tuo ambiente attuale, questo esperimento può dimostrare un valore immediato per l'attività.
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 PDC ti offre l'opportunità a basso rischio di identificare soluzione di database gestita per i carichi di lavoro su più benchmark e i 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 alla generazione di report sui metriche standard delle prestazioni di picco, tra cui latenza, velocità effettiva per il completamento. Ad esempio, potresti essere interessato a sapere quanto tempo e impegno sono necessari per eseguire il provisioning di molti cluster Kubernetes. Il Benchmarker PerfKit è un una community open source che ha coinvolto oltre 500 partecipanti, come ad esempio ricercatori, istituzioni accademiche 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 del costo totale di proprietà che ti consente di confrontare i costi su Google Cloud con i costi 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 valutano 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'esecuzione del cablaggio di rete appropriato sono costi una tantum che ti consentono di utilizzare l'intera capacità della rete. In un cloud dell'ambiente, esistono molti modi in cui potresti fatturato per l'utilizzo della rete. Per i carichi di lavoro 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 inoltre un'ampia gamma di opzioni per la scalabilità intelligente di risorse e costi. Ad esempio, nel Compute Engine che puoi ridimensionare durante la migrazione Migrazione per Compute Engine. o quando le VM sono già in esecuzione, o in fase di creazione gruppi di istanze con scalabilità automatica. Queste opzioni possono avere un forte impatto sui costi di esecuzione dei servizi per calcolare il costo totale di proprietà (TCO).
Per calcolare il costo totale delle risorse Google Cloud, puoi utilizzare il metodo Calcolatore prezzi.
Scegli la strategia di migrazione per i tuoi carichi di lavoro
Per ogni carico di lavoro da migrare, valuta e seleziona la strategia di migrazione più adatta al loro caso d'uso. Ad esempio, i carichi di lavoro potrebbero avere 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 tempi di inattività pari a zero o prossimi allo zero strategie di migrazione.
- Tollerano i tempi di inattività, come i carichi di lavoro secondari o di backend. Per questi carichi di lavoro, puoi scegliere strategie di migrazione che richiedono un tempo di inattività.
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. Ecco alcuni casi d'uso:
- 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 una migrazione senza interruzioni, puoi utilizzare il deployment delle applicazioni pattern, orchestrazione dell'infrastruttura e applicazioni di migrazione personalizzate. Tuttavia, strumenti specializzati denominati servizi di migrazione gestita possono facilitare processo di spostamento di dati, worload 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.
Definire il piano di migrazione e le tempistiche
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 batch (chiamato anche sprint in alcuni contesti).
- Scegli l'ordine in cui vuoi eseguire la migrazione dei batch.
- Scegliere l'ordine in cui eseguire la migrazione dei carichi di lavoro 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
- Tempistiche (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 di cui eseguire la migrazione.
- 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 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 deployment del carico di lavoro viene eseguito o eseguito in modo univoco 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.
- Impegno di refactoring per far funzionare il carico di lavoro nel nuovo ambiente.
- Requisiti di conformità e licenza del carico di lavoro.
- 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 esperienza e conoscenza approfondita 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, la scelta di chi muove i primi passi è fondamentale per avere una migrazione eseguita con successo.
valore aziendale
La scelta di un carico di lavoro non business critical protegge la tua linea principale e riduce l’impatto sull’attività derivante da rischi non ancora scoperti commettere errori durante l'apprendimento delle tecnologie cloud. Ad esempio, se scegli il componente in cui la logica principale delle transazioni finanziarie il carico di lavoro di e-commerce viene implementato come primo passaggio, migrazione potrebbe avere un impatto sulla tua linea di business principale. Una scelta migliore è il database SQL che supporta i carichi di lavoro o, meglio ancora, la gestione temporanea per configurare un database.
Evita i carichi di lavoro utilizzati raramente. Ad esempio, se scegli un carico di lavoro viene utilizzato solo poche volte l'anno da un numero ridotto di utenti, anche se è una una migrazione dei rischi, lo slancio della migrazione non aumenta difficili da 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. Un obiettivo principale quando si seleziona il primo fare un trasloco è fare esperienza con gli schemi comuni nella 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 carichi di lavoro è progettata seguendo una sviluppo basato sui test e sono sviluppati mediante l'utilizzo Linguaggio di programmazione Python, scegliendo un carico di lavoro con una copertura di test limitata e sviluppato utilizzando Linguaggio di programmazione Java, che non ti consente di scoprire pattern che puoi applicare durante la migrazione carichi di lavoro Python.
Team
Quando scegli i primi utenti, presta attenzione ai team responsabili di ciascun carico di lavoro. Il team responsabile di chi muove i primi passi deve avere un approccio motivato e desideroso di provare Google Cloud e i suoi servizi. Inoltre, la leadership aziendale deve avere obiettivi chiari per i team dei nuovi spostamenti e lavorare attivamente per sponsorizzare e sostenerli durante il processo.
Ad esempio, un team di alto rendimento che si trova nella sede principale con una comprovata esperienza nell'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, dovresti 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 è più semplice se hai un'esperienza limitata con Google Cloud.
Se devi scegliere carichi di lavoro con dipendenze da altri componenti, scegli quelli con un accoppiamento lasco 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. Per Ad esempio, i candidati a basso accoppiamento sono carichi di lavoro che comunicano utilizzando di messaggistica di Google, che funzionano offline o che sono progettati per tollerare 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 perfetti per muovere i primi passi perché non si basano su dati stateful locali.
Impegno di refactoring
Un movimentatore innovativo dovrebbe richiedere una minima attività di refactoring, in modo che tu possa concentrarti per la migrazione stessa e su Google Cloud, invece di spendere una delle modifiche al codice e alla configurazione dei 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à perché potresti avere requisiti di single-tenancy per alcuni carichi di lavoro. Per questi motivi, come pionieri dovresti scegliere i carichi di lavoro 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à
Le buone prime persone sono quelle che possono permettersi un tempo di inattività causato da un passaggio finestra. 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 tollera tempi di inattività più lunghi rispetto al carico di lavoro dell'e-commerce rivolto ai clienti sito in cui gli utenti finalizzano le loro 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, vedi Best practice per la convalida di un piano di migrazione.
Passaggi successivi
- Scopri come pianificare la migrazione e creare le tue basi su Google Cloud.
- Scopri quando consulta l'assistenza per le migrazioni.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.
Collaboratori
Autore: Marco Ferrari | Cloud Solutions Architect