Questo documento può aiutarti a pianificare, progettare e implementare la fase di valutazione della migrazione a Google Cloud. Scoprire il tuo inventario di app e servizi e mappare le loro dipendenze può aiutarti a identificare gli elementi di cui devi eseguire la migrazione e in quale ordine. Quando pianifichi e progetti una migrazione a Google Cloud, devi prima avere una conoscenza approfondita del tuo ambiente attuale e delle app e dei carichi di lavoro di cui eseguire la migrazione.
Questo documento fa parte di una serie in più parti sulla migrazione a Google Cloud:
- Migrazione a Google Cloud: inizia
- Migrazione a Google Cloud: valutazione e scoperta dei carichi di lavoro (questo documento)
- Migrazione a Google Cloud: crea le tue basi
- Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni
- Migrazione a Google Cloud: esegui il deployment dei tuoi carichi di lavoro
- Migrazione a Google Cloud: esegui la migrazione dai deployment manuali a quelli automatizzati e containerizzati
- Esegui la migrazione a Google Cloud: ottimizza il tuo ambiente
- Migrazione a Google Cloud: best practice per la convalida di un piano di migrazione
- Migrazione a Google Cloud: riduci al minimo i costi
Il seguente diagramma illustra il percorso del tuo percorso di migrazione.
La fase di valutazione è la prima fase della migrazione a Google Cloud, in cui determini i requisiti e le dipendenze per eseguire la migrazione delle tue app a Google Cloud.
Questo documento è utile se stai pianificando una migrazione da un ambiente on-premise, da un ambiente di hosting privato, da un altro cloud provider oppure se stai valutando l'opportunità di eseguire la migrazione ed esplorando la possibile fase di valutazione.
La fase di valutazione è fondamentale per il successo della migrazione. Devi conoscere a fondo le app di cui vuoi eseguire la migrazione, i loro requisiti, le loro dipendenze e il tuo ambiente attuale. Devi comprendere il punto di partenza per pianificare ed eseguire correttamente una migrazione Google Cloud.
In questa fase, esegui queste operazioni:
- Crea un inventario completo delle tue app.
- Cataloga le app in base alle loro proprietà e dipendenze.
- Addestra e istruisci i tuoi team su Google Cloud.
- Crea un esperimento e un proof of concept su Google Cloud.
- Calcolare il costo totale di proprietà (TCO) dell'ambiente di destinazione.
- Scegli i carichi di lavoro di cui vuoi eseguire prima la migrazione.
Creazione di un inventario delle app
Per definire l'ambito della migrazione, devi prima comprendere quanti elementi, come app ed appliance hardware, sono presenti nel tuo ambiente attuale, oltre alle relative dipendenze. La creazione dell'inventario è un'attività non banale che richiede uno sforzo significativo, soprattutto quando non disponi di un sistema di catalogazione automatico. Per disporre di un inventario completo, devi sfruttare le competenze dei team responsabili della progettazione, del deployment e del funzionamento di ogni carico di lavoro nel tuo ambiente attuale, oltre che dell'ambiente stesso.
L'inventario non deve essere limitato solo alle app, ma deve contenere almeno quanto segue:
- Dipendenze di ogni app, ad esempio database, broker di messaggi, sistemi di archiviazione della configurazione e altri componenti.
- Servizi che supportano l'infrastruttura dell'app, ad esempio repository di codice sorgente, strumenti di integrazione continua (CI) e repository di artefatti.
- Server, virtuali o fisici, e ambienti di runtime.
- Appliance fisiche, come dispositivi di rete, firewall e altro hardware dedicato.
Quando compili questo elenco, dovresti anche raccogliere informazioni su ogni elemento, tra cui:
- Posizione del codice sorgente e se sei in grado di modificare questo codice sorgente.
- Metodo di deployment del carico di lavoro in un ambiente di runtime, ad esempio se utilizzi una pipeline di deployment automatica o manuale.
- Limitazioni di rete o requisiti di sicurezza.
- Requisiti degli 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 al sistema di gestione di identità e accessi.
Ad esempio, è necessario conoscere le specifiche dettagliate di ogni appliance hardware, come il nome, il fornitore, le tecnologie e le 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 delle VM.
Questo elenco deve includere anche informazioni non tecniche, ad esempio in base ai termini di licenza che puoi utilizzare per ogni elemento e a qualsiasi altro requisito di conformità. Mentre alcune licenze consentono di eseguire il deployment di un'app in un ambiente cloud, altre ne vietano esplicitamente il deployment. Alcune licenze vengono assegnate in base al numero di CPU o socket in uso e questi concetti potrebbero non essere applicabili quando viene eseguita su tecnologia cloud. Alcuni dati potrebbero avere limitazioni relative alla regione in cui sono archiviati. Infine, alcuni carichi di lavoro sensibili possono richiedere un single-tenancy.
Oltre all'inventario, è utile fornire indicazioni per un'interpretazione visiva dei dati raccolti. Ad esempio, puoi fornire un grafico delle dipendenze e grafici per evidenziare aspetti di interesse, come la distribuzione delle app in un processo di deployment automatico o manuale.
Come creare l'inventario
Esistono diversi modi per creare un inventario per app. 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é si basava su ipotesi errate.
La creazione dell'inventario non è un esercizio una tantum. Se il tuo ambiente attuale è molto dinamico, dovresti anche impegnarti ad automatizzare la creazione e la manutenzione dell'inventario, in modo da avere una visione coerente di tutti gli elementi nel tuo ambiente in qualsiasi momento. Per informazioni su come creare un inventario delle app, consulta Centro di migrazione: avviare il rilevamento degli asset.
Google collabora anche con più aziende per assisterti nel tuo percorso di migrazione. Per maggiori informazioni, vedi Trovare assistenza.
Esempio di inventario per app
Questo esempio è un inventario di un ambiente che supporta un'app di e-commerce. L'inventario include app, dipendenze, servizi che supportano più app e appliance hardware.
App
Per ogni app nell'ambiente, la seguente tabella evidenzia le tecnologie più importanti, la relativa procedura di deployment e altri requisiti.
| Nome | Posizione codice sorgente | Tecnologie | Procedura di deployment | Altri requisiti | Dipendenze | Requisiti delle risorse di sistema |
|---|---|---|---|---|---|---|
| Sito web di marketing | Repository aziendale | Frontend angolare | Automatizzata | L'ufficio legale deve convalidare i contenuti | Servizio di memorizzazione nella cache | 5 core della CPU 8 GB di RAM |
| Back office | Repository aziendale | Backend Java, frontend Angular | Automatizzata | N/A | Database SQL | 4 core CPU 4 GB di RAM |
| App di e-commerce | App proprietaria | Fornitore X Modello Y Versione 1.2.0 |
Manuale | I dati del cliente devono risiedere all'interno dell'Unione Europea | Database SQL | 10 core della CPU 32 GB di RAM |
| Pianificazione delle risorse aziendali (ERP) | App proprietaria | Fornitore Z, Modello C, versione 7.0 | Manuale | N/A | Database SQL | 10 core della CPU 32 GB di RAM |
| Microservizi stateless | Repository aziendale | Java | Automatizzata | N/A | Servizio di memorizzazione nella cache | 4 core CPU 8 GB di RAM |
Dipendenze
La tabella seguente è un esempio delle dipendenze delle app elencate nell'inventario. Queste dipendenze sono necessarie per il corretto funzionamento delle app.
| Nome | Tecnologie | Altri requisiti | Dipendenze | Requisiti delle risorse di sistema |
|---|---|---|---|---|
| Database SQL | PostgreSQL | I dati del cliente devono risiedere all'interno dell'Unione Europea | Sistema di backup e archiviazione | 30 core della CPU 512 GB di RAM |
Servizi di supporto
Nel tuo ambiente potrebbero esserci servizi che supportano più app. In questo esempio di e-commerce, sono disponibili i seguenti servizi:
| Nome | Tecnologie | Altri requisiti | Dipendenze | Requisiti delle risorse di sistema |
|---|---|---|---|---|
| Repository di codice sorgente | Git | N/A | Sistema di backup e archiviazione | 2 core della CPU 4 GB di RAM |
| Sistema di backup e archiviazione | Fornitore G, Modello H, versione 2.3.0 | Per legge, per alcuni elementi è richiesto lo spazio di archiviazione a lungo termine | N/A | 10 core della CPU 8 GB di RAM |
| strumento CI | Jenkins | N/A | Repository di codice sorgente repository di artefatti sistema di backup e archiviazione |
32 core della CPU 128 GB di RAM |
| Repository elementi | Fornitore A Modello N Versione 5.0.0 |
N/A | Sistema di backup e archiviazione | 4 core della CPU 8 GB di RAM |
| Servizio di elaborazione batch | Cron job in esecuzione nello strumento di CI | N/A | strumento CI | 4 core della CPU 8 GB di RAM |
| Servizio di memorizzazione nella cache | Memcached Redis |
N/A | N/A | 12 core della CPU 50 GB di RAM |
Hardware
L'ambiente di esempio include le seguenti appliance hardware:
| Nome | Tecnologie | Altri requisiti | Dipendenze | Requisiti delle risorse di sistema |
|---|---|---|---|---|
| Firewall | Fornitore H Modello V |
N/A | N/D | N/A |
| Istanze di Server J | Fornitore K Modello B |
Deve essere dismesso perché non più supportato | N/A | N/A |
| Appliance NAS | Fornitore Y Modello Z NFS iSCSI |
N/A | N/D | N/A |
Valutare i processi operativi e di deployment
Dopo aver creato gli inventari dei carichi di lavoro, ti consigliamo di valutare i processi operativi e di deployment. I processi operativi e di deployment sono una parte fondamentale delle pratiche che preparano e gestiscono l'ambiente di produzione e i carichi di lavoro che vengono eseguiti al suo interno.
Questi processi possono eseguire il provisioning dell'infrastruttura necessaria e creare gli artefatti necessari ai carichi di lavoro, ad esempio pacchetti di sistemi operativi, pacchetti di deployment dei carichi di lavoro, immagini dei sistemi operativi e immagini dei container. Per ogni carico di lavoro, raccogli informazioni su quanti artefatti sono necessari, il tipo di ciascun artefatto, la modalità di creazione, le modalità e la posizione in cui vengono archiviati e il modo in cui inserisci la configurazione di runtime in modo che questi artefatti siano riutilizzabili in più ambienti.
Dopo aver valutato i processi operativi e di deployment, ti consigliamo anche di valutare in che modo questi processi possono facilitare la migrazione a Google Cloud e come possono aiutarti a ridurre l'ambito e il rischio della migrazione. Ad esempio, potresti eseguire il refactoring dei processi di creazione degli artefatti per archiviare gli artefatti sia nell'ambiente di origine che in Google Cloud durante la migrazione. La presenza di artefatti in entrambi gli ambienti ti consente di concentrarti sulla migrazione dei carichi di lavoro e dei dati dall'ambiente di origine a Google Cloud senza dover implementare processi di creazione degli artefatti nell'ambiente Google Cloud di destinazione fin dall'inizio del processo di migrazione.
Valuta la tua infrastruttura
Dopo aver valutato i processi operativi e di deployment, ti consigliamo di valutare l'infrastruttura che attualmente supporta i tuoi carichi di lavoro nell'ambiente di origine.
Per valutare l'infrastruttura, considera quanto segue:
- I processi adottati per eseguire il provisioning delle risorse necessarie al carico di lavoro, ad esempio Infrastructure as Code.
- 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, ad esempio organizzazioni e progetti.
- Modalità di connessione dell'ambiente ad altri ambienti, ad esempio ambienti on-premise e altri cloud provider.
Classificazione delle app
Dopo aver completato l'inventario, devi organizzare le app in diverse categorie. Questa categorizzazione può aiutarti a dare la priorità alle app di cui eseguire la migrazione in base alla loro complessità e al rischio che comportano il passaggio al cloud.
Una matrice del catalogo deve avere una dimensione per ogni criterio di valutazione che stai considerando nel tuo ambiente. Scegli un insieme di criteri che soddisfi tutti i requisiti del tuo ambiente, comprese le risorse di sistema di cui ogni app ha bisogno. Ad esempio, potrebbe interessarti sapere se un'app ha dipendenze o se è stateless o stateful. Quando progetti la matrice del catalogo, considera che per ogni criterio aggiunto viene aggiunta un'altra dimensione da rappresentare. La matrice risultante potrebbe essere difficile da visualizzare. Una possibile soluzione a questo problema potrebbe essere utilizzare più matrici più piccole, invece di una singola matrice complessa.
Inoltre, accanto a ogni app devi aggiungere un indicatore della complessità della migrazione. Questo indicatore stima la valutazione della difficoltà per eseguire la migrazione di ogni app. La granularità di questo indicatore dipende dall'ambiente. Come 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 che ne stimino la complessità della migrazione. I fattori che influiscono su questa complessità di migrazione sono specifici di ciascuna azienda.
Quando il catalogo è completo, puoi anche creare immagini e grafici per aiutare te e il tuo team a valutare rapidamente le metriche di interesse. Ad esempio, traccia un grafico che evidenzi quanti componenti hanno dipendenze o la difficoltà di migrazione di ogni componente.
Per informazioni su come creare un inventario delle app, consulta Centro di migrazione: avviare il rilevamento degli asset.
Esempio di catalogo di app
In questo esempio vengono utilizzati i seguenti criteri di valutazione, uno per ogni asse della matrice:
- Il grado di importanza di un'app per l'attività.
- Indica se un'app ha dipendenze o è una dipendenza per altre app.
- Tempo di inattività massimo consentito per l'app.
- Livello di difficoltà della migrazione di un'app.
| Importanza per l'attività | Non ha dipendenze o dipendenti | Ha dipendenze o dipendenti | Tempo di inattività massimo consentito | Difficoltà |
|---|---|---|---|---|
| Mission critical | Microservizi stateless | 2 minuti | Facile | |
| ERP | 24 ore | Difficile | ||
| App di 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 grafico seguente evidenzia la difficoltà della migrazione:
Nel grafico precedente, la maggior parte delle app è facile da spostare, mentre solo tre di esse sono difficili da spostare e una non può essere spostata.
Educare l'organizzazione a 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 azienda può utilizzare su Google Cloud. Il personale può iniziare con account di prova gratuiti di Google Cloud che contengono crediti per sperimentare e apprendere in modo pratico. Creare un ambiente gratuito per i test e l'apprendimento è fondamentale per l'esperienza di apprendimento del personale.
Hai a disposizione diverse opzioni di formazione:
- Risorse pubbliche e aperte: puoi iniziare a imparare Google Cloud con lab pratici, serie di video, webinar Cloud OnAir ed eventi di formazione Cloud OnBoard.
- Corsi di approfondimento: se vuoi conoscere più a fondo come funziona Google Cloud, puoi partecipare ai corsi on demand di Google Cloud Skills Boost o alle specializzazioni di formazione Google Cloud di Coursera, che puoi seguire online secondo i tuoi tempi oppure formazione in aula dei nostri partner di formazione autorizzati in tutto il mondo. In genere questi corsi hanno una durata 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 app o gli operatori di infrastruttura su come utilizzare al meglio i servizi Google Cloud.
Puoi anche certificare la conoscenza di Google Cloud da parte dei tuoi ingegneri con varie certificazioni, a diversi livelli:
- Certificazioni associate: un punto di partenza per coloro che non conoscono Google Cloud e possono aprire le porte a certificazioni professionali, come la certificazione Cloud Engineer associata.
- Certificazioni professionali: se vuoi valutare competenze avanzate di progettazione e implementazione per Google Cloud dopo anni di esperienza, puoi ottenere certificazioni come Cloud Architect professionale o data engineer professionale.
- Certificazioni Google Workspace: puoi dimostrare le competenze in materia di collaborazione utilizzando gli strumenti di Google Workspace con una certificazione Google Workspace.
- Certificazioni Apigee: con la certificazione API Engineer di Apigee, puoi dimostrare la capacità di progettare e sviluppare API solide, sicure e scalabili.
- Certificazioni Google Developers: puoi dimostrare competenze di sviluppo con le certificazioni Sviluppatore Android associato (questa certificazione è in fase di aggiornamento) e specialisti di web mobile.
Oltre a formazione e certificazione, uno dei modi migliori per acquisire esperienza con Google Cloud è iniziare a utilizzare il prodotto per creare una proof of concept di business.
Sperimentare e progettare proof of concept
Per mostrare il valore e l'efficacia di Google Cloud, valuta la possibilità di progettare e sviluppare una o più proof of concept (PDC) per ogni categoria di app nel tuo catalogo di app. Sperimentazione e test permettono di convalidare ipotesi e dimostrare il valore del cloud ai leader aziendali.
Il PDC deve includere come minimo quanto segue:
- Un elenco completo dei casi d'uso supportati dalle tue app, inclusi quelli insoliti e quelli angolari.
- Tutti i requisiti per ogni caso d'uso, come requisiti di prestazioni e scalabilità, garanzie di coerenza prevista, meccanismi di failover e requisiti di rete.
- Un potenziale elenco di tecnologie e prodotti che vuoi analizzare e testare.
Dovresti progettare PDC ed esperimenti per convalidare tutti i casi d'uso nell'elenco. Ogni esperimento deve avere un contesto di validità preciso, un ambito, un risultato previsto e un impatto aziendale misurabile.
Ad esempio, se una delle tue app legate 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 occorre per farlo. Se riscontri un valore aggiunto significativo, ad esempio la riduzione del nuovo tempo di scale up delle nuove app del 95% rispetto all'ambiente attuale, questo può dimostrare un valore aziendale immediato.
Se vuoi valutare il confronto tra le prestazioni dei tuoi database on-premise e quelle di Cloud SQL, Spanner, Firestore o Bigtable, potresti implementare un PoC in cui la stessa logica di business utilizza database diversi. Questo PDC ti offre un'opportunità a basso rischio di identificare la soluzione di database gestito giusta per il tuo carico di lavoro 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, come PerfKit Benchmarker, e confrontare Google Cloud con altri cloud provider. 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 occorrono per il provisioning di molti cluster Kubernetes. PerfKit Benchmarker è un'iniziativa open source per la community che coinvolge oltre 500 partecipanti, tra cui ricercatori, istituzioni accademiche e aziende, tra cui Google.
Calcolo del costo totale di proprietà
Quando hai una chiara visione delle risorse necessarie nel nuovo ambiente, puoi creare un modello di costo totale di proprietà che ti consente di confrontare i tuoi costi su Google Cloud con quelli del tuo ambiente attuale.
Quando crei questo modello di costo, devi tenere conto non solo dei costi hardware e del software, ma anche di tutti i costi operativi dell'esecuzione del tuo data center, come alimentazione, raffreddamento, manutenzione e altri servizi di assistenza. Considera che in genere è anche più semplice ridurre i costi, grazie alla scalabilità elastica delle risorse Google Cloud, rispetto a un data center on-premise più rigido.
Un costo comunemente trascurato quando si considerano le migrazioni al cloud è l'uso di una rete cloud. In un data center, acquistare un'infrastruttura di rete, come router e switch, e quindi utilizzare i cavi di rete appropriati, sono costi una tantum che ti consentono di utilizzare l'intera capacità della rete. In un ambiente cloud, esistono molti modi in cui potrebbero esserti fatturati l'utilizzo della rete. Per le app che richiedono un uso intensivo dei dati o quelle 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 rete nel cloud.
Google Cloud offre inoltre un'ampia gamma di opzioni per la scalabilità intelligente di risorse e costi. Ad esempio, in Compute Engine puoi ridimensionare durante la migrazione con Migrate for Compute Engine o dopo che le VM sono già in esecuzione o creando gruppi di istanze con scalabilità automatica. Queste opzioni possono avere un impatto significativo sui costi dell'esecuzione dei servizi e dovrebbero essere analizzate per calcolare il costo totale di proprietà (TCO).
Per calcolare il costo totale delle risorse Google Cloud, puoi utilizzare il Calcolatore prezzi.
Scegliere le app di cui eseguire la migrazione per prime
Ora che hai una visione completa dell'ambiente attuale, devi completare il piano di migrazione scegliendo l'ordine iniziale in cui eseguire la migrazione delle tue app. Puoi perfezionare questo ordine durante la migrazione quando acquisisci esperienza con Google Cloud e comprendi l'ambiente e le app.
Le app di cui esegui per prime la migrazione sono quelle che consentono ai tuoi team di sviluppare conoscenze ed esperienze su Google Cloud. Una maggiore esposizione e maggiore esperienza al cloud da parte del tuo team può ridurre il rischio di complicazioni durante la fase di migrazione e rendere più semplici e rapide le migrazioni successive. Per questo motivo, scegliere i primi passi giusti è fondamentale per una migrazione di successo. Puoi scegliere un'app o inserire molte app della matrice delle app nel tuo elenco dei primi passi.
L'identificazione dei primi passi è complessa, ma ecco alcuni criteri per guidarti:
- Valore aziendale dell'app.
- Se il deployment dell'app viene eseguito o viene eseguita in modo univoco rispetto al resto dell'infrastruttura.
- Team responsabili dello sviluppo, del deployment e delle operazioni dell'app.
- Numero, tipo e ambito delle dipendenze dell'app.
- Eseguire il refactoring dell'app per far funzionare l'app nel nuovo ambiente.
- Requisiti di conformità e di licenza dell'app.
- Requisiti di disponibilità e affidabilità dell'app.
Valore aziendale
La scelta di un'app non business critical protegge il tuo settore di attività principale e riduce l'impatto sull'attività da rischi e errori non rilevati mentre il tuo team sta imparando le tecnologie cloud. Ad esempio, se scegli il componente in cui viene implementata la logica principale delle transazioni finanziarie della tua app di e-commerce come prima mossa, qualsiasi errore durante la migrazione potrebbe causare un impatto sulla tua linea di business principale. Una scelta migliore è il database SQL che supporta le tue app o, meglio ancora, il database di gestione temporanea.
Dovresti evitare le app usate raramente. Ad esempio, se scegli un'app che viene utilizzata solo poche volte all'anno da un numero ridotto di utenti, pur essendo a basso rischio, la migrazione non aumenta lo slancio della migrazione e può essere difficile rilevare e rispondere ai problemi.
Casi limite
Dovresti anche evitare i casi limite, in modo da poter scoprire pattern da applicare ad altre app di cui eseguire la migrazione. Uno degli obiettivi principali della scelta di un primo trasloco è acquisire esperienza con i modelli comuni nella tua organizzazione, in modo da poter creare una knowledge base. Puoi riapplicare ciò che hai imparato con queste persone in anteprima al momento della migrazione delle app future.
Ad esempio, se la maggior parte delle tue app è stata progettata secondo una metodologia di sviluppo basata su test e sviluppate utilizzando il linguaggio di programmazione Python, la scelta di un'app con poca copertura di test e sviluppata utilizzando il linguaggio di programmazione Java non ti consente di scoprire alcun pattern da applicare durante la migrazione delle app Python.
Team
Quando scegli i tuoi primi spostamenti, presta attenzione ai team responsabili di ogni app. Il team responsabile di una prima mossa deve essere altamente motivato e pronto a provare Google Cloud e i suoi servizi. Inoltre, i dirigenti aziendali dovrebbero avere obiettivi chiari per i team di primo passaggio e lavorare attivamente per sponsorizzare e supportarli durante il processo.
Ad esempio, un team ad alte prestazioni nella sede principale con una comprovata esperienza nell'implementazione di pratiche di sviluppo moderne come DevOps e discipline come il site Reliability Engineering può essere un buon candidato. Se hanno anche sponsor della leadership dall'alto verso il basso e obiettivi chiari per ogni migrazione delle app, possono essere un candidato eccellente.
Dipendenze
Inoltre, dovresti concentrarti sulle app che hanno il minor numero di dipendenze, da altre app o servizi. La migrazione di un'app senza dipendenze è più semplice se hai un'esperienza limitata con Google Cloud.
Se devi scegliere app che hanno dipendenze da altri componenti, scegli quelle a basso accoppiamento con le rispettive dipendenze. Se un'app è già progettata per l'eventuale indisponibilità delle sue dipendenze, può ridurre l'attrito durante la migrazione dell'app nell'ambiente di destinazione. Ad esempio, i candidati a basso accoppiamento sono app che comunicano tramite un broker di messaggi, che funzionano offline o sono progettate per tollerare la indisponibilità del resto dell'infrastruttura.
Sebbene esistano strategie per la migrazione dei dati delle app stateful, un'app stateless raramente richiede alcuna migrazione dei dati. La migrazione di un'app stateless può essere più semplice perché non devi preoccuparti di una fase transitoria in cui i dati sono in parte nel tuo ambiente attuale e parzialmente nell'ambiente di destinazione. Ad esempio, i microservizi stateless sono buoni candidati per il primo passaggio, perché non si basano su dati stateful locali.
Impegno di refactoring
Un primo passaggio dovrebbe richiedere una quantità minima di refactoring, in modo che tu possa concentrarti sulla migrazione stessa e su Google Cloud, invece di doverti dedicare molto alle modifiche al codice e alla configurazione delle tue app. Il refactoring dovrebbe concentrarsi sulle modifiche necessarie che consentono l'esecuzione delle app nell'ambiente di destinazione anziché sulla modernizzazione e sull'ottimizzazione delle app, che verrà affrontata nelle fasi di migrazione successive.
Ad esempio, un'app che richiede solo modifiche alla configurazione è un ottimo primo passo, perché non è necessario implementare alcuna modifica al codebase e puoi utilizzare gli artefatti esistenti.
Licenze e conformità
Anche le licenze sono determinanti per la scelta dei primi spostamenti, perché alcune delle tue app potrebbero essere concesse in licenza in base ai termini che influiscono sulla migrazione. Ad esempio, alcune licenze vietano esplicitamente l'esecuzione di app in un ambiente cloud.
Quando esamini i termini di licenza, non dimenticare i requisiti di conformità, perché potresti avere requisiti single-tenancy per alcune delle tue app. Per questi motivi, ti consigliamo di scegliere come prime app con un numero minimo di restrizioni relative a licenze 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 clienti potrebbero essere limitati a una regione specifica.
Disponibilità e affidabilità
Le buone prime operazioni sono quelle che possono permettersi un tempo di inattività causato da una finestra del cutover. Se scegli un'app che ha requisiti di disponibilità rigorosi, devi implementare una strategia di migrazione dei dati senza tempi di inattività come Y (scrittura e lettura) o sviluppando un microservizio di accesso ai dati. Sebbene questo approccio sia possibile, distrae i tuoi team dall'ottenere l'esperienza necessaria con Google Cloud, perché devono dedicare del tempo a implementare queste strategie.
Ad esempio, i requisiti di disponibilità di un motore di elaborazione batch possono tollerare un tempo di inattività più lungo rispetto all'app rivolta ai clienti del tuo sito di e-commerce in cui gli utenti finalizzano le proprie transazioni.
Passaggi successivi
- Scopri come pianificare la migrazione e creare le basi su Google Cloud.
- Scopri come trovare assistenza per le migrazioni.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.