Migrazione a Google Cloud: valutazione e scoperta dei carichi di lavoro

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento può aiutarti a pianificare, progettare e implementare la fase di valutazione della migrazione a Google Cloud. Scoprire l'inventario di app e servizi e mapparne le dipendenze possono aiutarti a identificare ciò di cui devi eseguire la migrazione e in quale ordine. Quando pianifichi e progetti una migrazione a Google Cloud, devi prima conoscere a fondo il tuo ambiente attuale e le applicazioni e i carichi di lavoro di cui eseguire la migrazione.

Questo documento fa parte di una serie in più parti sulla migrazione a Google Cloud. Se ti interessa una panoramica della serie, vedi Migrazione a Google Cloud: Scegliere il percorso di migrazione.

Questo articolo fa parte di una serie:

Il seguente diagramma illustra il percorso del percorso di migrazione.

Percorso di migrazione in quattro fasi.

La fase di valutazione è la prima fase della migrazione a Google Cloud, in cui stabilisci i requisiti e le dipendenze per la migrazione delle app a Google Cloud.

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

La fase di valutazione è fondamentale per il successo della migrazione. Devi acquisire una conoscenza approfondita delle app di cui vuoi eseguire la migrazione, dei relativi requisiti, delle dipendenze e dell'ambiente attuale. Devi conoscere il tuo punto di partenza per pianificare ed eseguire correttamente una migrazione a Google Cloud.

In questa fase devi eseguire i seguenti passaggi:

  1. Crea un inventario completo delle tue app.
  2. Classifica le app in base alle loro proprietà e alle loro dipendenze.
  3. Forma e forma i tuoi team su Google Cloud.
  4. Crea un esperimento e una proof of concept su Google Cloud.
  5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
  6. Scegli prima i carichi di lavoro di cui vuoi eseguire la migrazione.

Creare un inventario delle tue app

Per definire l'ambito della migrazione, devi prima capire quanti elementi, ad esempio app ed appliance hardware, esistono nell'ambiente attuale, oltre alle loro dipendenze. La creazione dell'inventario non è un'attività faticosa che richiede un impegno significativo, specialmente quando non è presente un sistema di catalogazione automatico. Per avere un inventario completo, devi utilizzare le competenze dei team responsabili della progettazione, del deployment e del funzionamento di ogni carico di lavoro nel tuo ambiente attuale, nonché nell'ambiente stesso.

L'inventario non deve essere limitato solo alle app, ma deve contenere almeno quanto segue:

  • Dipendenze di ogni app, ad esempio database, intermediari di messaggi, sistemi di archiviazione 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.
  • Appliance fisiche, come dispositivi di rete, firewall e altri hardware dedicati.

Quando compili l'elenco, dovresti anche raccogliere informazioni su ogni elemento, tra cui:

  • La posizione del codice sorgente e se sei in grado di modificarla.
  • Metodo di deployment del carico di lavoro in un ambiente di runtime, ad esempio se utilizzi una pipeline di deployment automatizzata o manuale.
  • Limitazioni della rete o requisiti di sicurezza.
  • Requisiti relativi alle licenze per software o hardware.

Ad esempio, per ogni appliance hardware, dovresti conoscerne le specifiche dettagliate, come nome, fornitore, tecnologie e dipendenze degli altri elementi dell'inventario. Ad esempio:

  • Nome: NAS Appliance
  • 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 ai sensi dei termini di licenza autorizzati a utilizzare ciascun elemento ed eventuali altri requisiti di conformità. Mentre alcune licenze consentono il deployment di un'app in un ambiente cloud, altre vietano esplicitamente il deployment cloud. Alcune licenze vengono assegnate in base al numero di CPU o socket in uso e questi concetti potrebbero non essere applicabili durante l'esecuzione con tecnologia cloud. Alcuni tuoi dati potrebbero avere limitazioni relative alla regione geografica in cui sono archiviati. Infine, alcuni carichi di lavoro sensibili possono richiedere un single-tenant.

Insieme all'inventario, è utile fornire un'interpretazione visiva dei dati raccolti. Ad esempio, puoi fornire un grafico dei dipendenti e grafici per evidenziare aspetti di interesse, come la distribuzione delle tue 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 obsoleti e la migrazione risultante potrebbe non riuscire perché era basata su ipotesi errate.

Creare l'inventario non è un esercizio una tantum. Se il tuo ambiente attuale è altamente 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 un determinato momento.

Google collabora con più società per assisterti nel tuo percorso di migrazione. Per ulteriori informazioni, consulta la sezione Trovare la guida.

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 ed appliance hardware.

App

Per ogni app nell'ambiente, la tabella seguente 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 Automatico L'ufficio legale deve convalidare i contenuti Servizio di memorizzazione nella cache 5 core di 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
App di e-commerce App proprietaria 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
Pianificazione risorse aziendali (ERP) App proprietaria Fornitore Z, modello C, versione 7.0 Manuale N/D Database SQL 10 core CPU
32 GB di RAM
microservizi stateless Repository aziendale Java Automatico N/D Servizio di memorizzazione nella cache 4 core CPU
8 GB di RAM

Dipendenze

La 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 dei clienti devono risiedere all'interno dell'Unione Europea Sistema di backup e archiviazione 30 core CPU
512 GB di RAM

Servizi di supporto

Nel tuo ambiente, potresti avere servizi che supportano più 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/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, lo spazio di archiviazione a lungo termine è obbligatorio per alcuni elementi N/D 10 core CPU
8 GB di RAM
Strumento CI Jenkins N/D Repository di codice sorgente
repository artefatti
sistema di backup e archiviazione
32 core CPU
128 GB di RAM
Repository elementi Fornitore A
Modello N
Versione 5.0.0
N/D Sistema di backup e archiviazione 4 core CPU
8 GB di RAM
Servizio di elaborazione batch Cron job in esecuzione nello 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 include le seguenti appliance hardware:

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

Classificazione delle app

Dopo aver completato l'inventario, devi organizzare le app in diverse categorie. Questa classificazione può aiutarti a dare la priorità alle app di cui eseguire la migrazione in base alla loro complessità e al rischio di passare 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 soddisfino tutti i requisiti del tuo ambiente, incluse le risorse di sistema richieste da ogni app. Ad esempio, potrebbe interessarti sapere se un'app ha dipendenze o se è stateful o stateful. Quando progetti la matrice del catalogo, considera che per ogni criterio che aggiungi aggiungi 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 e complessa.

Inoltre, accanto a ogni app, devi aggiungere un indicatore di complessità della migrazione. Questo indicatore indica la valutazione della difficoltà di migrazione di ogni app. La granularità di questo indicatore dipende dal tuo ambiente. Per un esempio di base, potresti avere tre categorie: facile da trasferire, difficile da sottoporre a migrazione o impossibile eseguire la migrazione. Per completare questa attività, hai bisogno di esperti per ogni elemento dell'inventario per stimare la sua complessità della migrazione. I fattori determinanti per questa complessità sono specifici di 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 interesse. Ad esempio, traccia un grafico che evidenzi il numero di componenti con dipendenze o evidenzia la difficoltà di migrazione di ciascun componente.

Esempio di catalogo di un'app

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

  1. Indica se un'app ha dipendenze o è dipendente da altre.
  2. Il grado di importanza di un'app per l'attività.
  3. Quanto è difficile eseguire la migrazione di un'app.
Non ha dipendenze o dipendenze Con dipendenze o dipendenze Difficoltà
Mission critical microservizi stateless Facile
ERP Difficile
App di e-commerce Difficile
Firewall hardware Impossibile spostare
Database SQL Facile
Repository di codice sorgente Facile
Non mission Sito web di marketing Facile
Backup e archiviazione Facile
Servizio di elaborazione batch Facile
Servizio di memorizzazione nella cache Facile
Back-office Difficile
Strumento CI Facile
Repository elementi Facile

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

Grafico che mostra la difficoltà associata allo spostamento di app in Google Cloud.

Nel grafico precedente, la maggior parte delle app è facile da spostare, mentre solo tre sono difficili da trasferire e una di queste non può essere spostata.

Formazione della tua organizzazione su Google Cloud

Per sfruttare appieno 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 gli account di prova gratuiti di Google Cloud che contengono crediti per aiutarli a sperimentare e apprendere in modo pratico. Creare un ambiente gratuito per eseguire test e apprendere è fondamentale per l'esperienza di apprendimento del tuo personale.

Sono disponibili diverse opzioni di formazione:

  1. Risorse pubbliche e aperte: puoi iniziare a imparare Google Cloud con labs pratici, serie di video, webinar su Cloud OnAir e eventi di formazione su Cloud.
  2. Corsi approfonditi: se vuoi comprendere più a fondo il funzionamento di Google Cloud, puoi seguire corsi on demand di Google Cloud Skills Boost o Specializzazioni di Google Cloud Training di Coursera che puoi seguire online secondo i tuoi tempi o accedere a formazione in classe dei nostri partner di formazione autorizzati in tutto il mondo. In genere questo corso dura da uno a diversi giorni.
  3. Percorsi di apprendimento basati sui ruoli: puoi formare i tuoi tecnici in base al loro ruolo nella tua organizzazione. Ad esempio, puoi addestrare i tuoi sviluppatori di app o gli operatori di infrastruttura a come utilizzare al meglio i servizi Google Cloud.

Puoi anche certificare i tuoi ingegneri la conoscenza di Google Cloud con varie certificazioni, su diversi livelli:

  1. Certificazioni associate: un punto di partenza per coloro che non hanno mai utilizzato Google Cloud e possono aprire le porte a certificazioni professionali, come la certificazione Associate Cloud Engineer.
  2. Certificazioni Professional: se vuoi valutare competenze avanzate di progettazione e implementazione per Google Cloud da anni di esperienza, puoi ottenere certificazioni, come il professionista cloud architect o il professionista data engineer.
  3. Certificazioni Google Workspace: puoi dimostrare le competenze di collaborazione utilizzando gli strumenti di Google Workspace con una certificazione Google Workspace.
  4. Certificazioni Apigee: con la certificazione per tecnici delle API certificate Apigee, puoi dimostrare la capacità di progettare e sviluppare API solide, sicure e scalabili.
  5. Certificazioni per sviluppatori Google: puoi dimostrare le tue competenze di sviluppo alle certificazioni Associate sviluppatore Android (è in corso l'aggiornamento di questa certificazione) e agli specialisti del 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.

Sperimentazione e progettazione di 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 (PoC) per ogni categoria di app nel catalogo delle app. Sperimentazione e test ti consentono di convalidare ipotesi e dimostrare il valore del cloud ai leader aziendali.

Come minimo, il tuo punto di contatto dovrebbe includere quanto segue:

  • Un elenco completo dei casi d'uso supportati dalle tue app, inclusi quelli insoliti e casi d'angolo.
  • Tutti i requisiti relativi a ogni caso d'uso, come i requisiti di prestazioni e scalabilità, le garanzie di coerenza previste, i meccanismi di failover e i requisiti di rete.
  • Un potenziale elenco di tecnologie e prodotti che vuoi esaminare e testare.

Dovresti progettare PoC ed esperimenti per convalidare tutti i casi d'uso nell'elenco. Ogni esperimento deve avere un contesto preciso in termini di validità, ambito, output previsti 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 il tempo necessario per farlo. Se riscontri un valore aggiunto significativo, ad esempio riducendo i nuovi tempi di scale up dell'app del 95% rispetto al tuo ambiente attuale, questo può dimostrare un valore aziendale istantaneo.

Se ti interessa confrontare le prestazioni dei tuoi database on-premise con Cloud SQL, Cloud Spanner, Firestore o Cloud Bigtable, puoi implementare un PoC in cui la stessa logica di business utilizza database diversi. Questo POC offre un'opportunità a basso rischio di identificare la giusta soluzione di database gestito per il 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 Benchmark di PerfKit 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 relative alle prestazioni di picco, tra cui latenza, velocità effettiva e tempo fino al completamento. Ad esempio, potresti essere alla ricerca del tempo e dell'impegno necessari per eseguire il provisioning di molti cluster Kubernetes. PerfKit Benchmarker è un progetto di una community open source che ha coinvolto più di 500 partecipanti, tra cui ricercatori, istituti accademici e aziende, tra cui Google.

Calcolo del costo totale di proprietà

Quando hai una visione chiara delle risorse necessarie nel nuovo ambiente, puoi creare un modello di 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 costi, devi considerare non solo i costi relativi all'hardware e al software, ma anche tutti i costi operativi per la gestione del tuo data center, ad esempio l'energia, il raffreddamento, la manutenzione e altri servizi di assistenza. Tieni presente che in genere è anche più semplice 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 considerano le migrazioni cloud è l'uso di una rete cloud. In un data center, l'acquisto di infrastruttura di rete, come router e switch, e quindi l'esecuzione di un cablaggio di rete appropriato sono costi una tantum che ti consentono di utilizzare l'intera capacità della rete. In un ambiente cloud, sono disponibili molti modi per eseguire l'addebito per l'utilizzo della rete. Per le app ad alta intensità di dati o 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 anche un'ampia gamma di opzioni per la scalabilità intelligente delle risorse e dei costi. Ad esempio, in Compute Engine puoi ridimensionare le risorse durante la migrazione con Migrate for Compute Engine o dopo l'esecuzione delle VM, oppure creando scalabilità automatica dei gruppi di istanze. Queste opzioni possono avere un grande impatto sui costi dei servizi di gestione e devono essere esplorate per calcolare il costo totale di proprietà (TCO).

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

Scegliere prima le app di cui eseguire la migrazione

Ora che hai una panoramica completa dell'ambiente attuale, devi completare il piano di migrazione scegliendo l'ordine iniziale in cui eseguire la migrazione delle app. Puoi perfezionare questo ordine durante la migrazione quando acquisisci esperienza con Google Cloud e comprendi il tuo ambiente e le tue app.

Le app di cui esegui la migrazione sono quelle che consentono ai tuoi team di acquisire le proprie conoscenze ed esperienza su Google Cloud. Una maggiore esposizione ed esperienza cloud dal tuo team può ridurre il rischio di complicazioni durante la fase di migrazione e rendere le migrazioni successive più semplici e veloci. Per questo motivo, scegliere i primi clienti giusti è fondamentale per una migrazione efficace. Puoi scegliere un'app o inserire tante app nella matrice delle app nel tuo elenco di primi dispositivi.

L'attività di identificazione delle prime figure è complessa, ma di seguito sono riportati alcuni criteri utili:

  • Il valore aziendale dell'app.
  • Se il deployment dell'app viene eseguito o eseguito in modo univoco rispetto al resto dell'infrastruttura.
  • I team responsabili dello sviluppo, del deployment e delle operazioni dell'app.
  • Numero, tipo e ambito delle dipendenze dell'app.
  • Eseguire il refactoring per rendere l'app funzionante nel nuovo ambiente.
  • Conformità e requisiti di licenza dell'app.
  • Disponibilità e affidabilità dell'app.

Valore aziendale

Scegliere un'app che non sia critica per l'attività protegge la tua linea di business principale e riduce l'impatto sull'attività da rischi e errori imprevisti mentre il tuo team sta imparando le tecnologie cloud. Ad esempio, se scegli il componente in cui la logica delle transazioni finanziarie principali dell'app di e-commerce viene implementata come primo passo, qualsiasi errore durante la migrazione potrebbe causare un impatto sul settore di attività principale. Una scelta migliore è il database SQL che supporta le tue app o, ancora meglio, il database temporaneo.

Dovresti evitare le app usate di rado. Ad esempio, se scegli un'app che viene utilizzata solo poche volte all'anno da un numero ridotto di utenti, mentre è una migrazione a basso rischio, la migrazione non cresce, e può essere difficile rilevare e rispondere ai problemi.

Casi limite

Dovresti anche evitare i casi perimetrali, in modo da individuare i pattern che puoi applicare ad altre app di cui eseguire la migrazione. Un obiettivo principale quando si seleziona un primo responsabile della migrazione è acquisire esperienza con i pattern comuni della tua organizzazione, in modo da poter creare una base di conoscenze. Puoi applicare nuovamente ciò che hai imparato con questi primi utenti durante la migrazione futura delle app.

Ad esempio, se la maggior parte delle tue app è progettata secondo una metodologia di sviluppo basata sui test e viene sviluppata utilizzando il linguaggio di programmazione Python, scegliendo un'app con poca copertura di test e sviluppata utilizzando il linguaggio di programmazione Java, non puoi scoprire qualsiasi pattern che puoi applicare durante la migrazione delle app Python.

Team

Quando scegli i primi utenti, presta attenzione ai team responsabili di ogni app. Il team responsabile di un primo movimento deve essere molto motivato e non vede l'ora di provare Google Cloud e i suoi servizi. Inoltre, la leadership aziendale deve avere obiettivi chiari per i team che si occupano di primo posto e lavorare attivamente per sponsorizzare e supportare questo team durante la procedura.

Ad esempio, un team ad alte prestazioni che si trova nella sede principale con una storia comprovata di implementazione di pratiche di sviluppo moderne come DevOps e discipline come l'ingegneria di affidabilità del sito può essere un buon candidato. Se hanno anche sponsor di leadership e obiettivi chiari per ogni migrazione delle app, possono essere un candidato eccellente.

Dipendenze

Inoltre, dovresti concentrarti sulle app con il minor numero di dipendenze, provenienti da altri servizi o app. 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 loro dipendenze. Se un'app è già progettata per l'eventuale indisponibilità delle sue dipendenze, può ridurre la attrito durante la migrazione dell'app all'ambiente di destinazione. Ad esempio, i candidati a basso accoppiamento sono app che comunicano tramite un intermediario dei messaggi o che funzionano offline o che sono progettate per tollerare l'indisponibilità del resto dell'infrastruttura.

Sebbene esistano strategie per eseguire la migrazione dei dati delle app stateful, raramente un'app stateless richiede una migrazione di 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 nell'ambiente attuale e in parte nell'ambiente di destinazione. Ad esempio, i microservizi stateless sono buoni candidati prima di tutto, perché non si basano sui dati stateful locali.

Impegno di refactoring

Un primo utente dovrebbe richiedere una quantità minima di refactoring, in modo che tu possa concentrarti sulla migrazione stessa e su Google Cloud, invece di dedicare un grande impegno alle modifiche al codice e alla configurazione delle tue app. Il refactoring dovrebbe concentrarsi sulle modifiche necessarie che consentono l'esecuzione delle tue app nell'ambiente di destinazione anziché concentrarsi sulla modernizzazione e sull'ottimizzazione delle app, che viene trattata nelle fasi successive della migrazione.

Ad esempio, un'app che richiede solo modifiche alla configurazione è una buona idea, perché non è necessario implementare alcuna modifica del codebase e si possono utilizzare gli artefatti esistenti.

Licenze e conformità

Anche le licenze svolgono un ruolo nella scelta delle prime impostazioni, perché alcune delle tue app potrebbero essere concesse in licenza in base a termini che influiscono sulla tua migrazione. Ad esempio, alcune licenze vietano esplicitamente l'esecuzione di app in un ambiente cloud.

Quando esamini i termini di licenza, non dimenticare di rispettare i requisiti di conformità perché potresti avere requisiti di single-tenant per alcune delle tue app. Per questi motivi, devi scegliere quali app che hanno una quantità minima di licenze e limitazioni di conformità.

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

Disponibilità e affidabilità

Le prime variabili sono quelle che possono permettersi un tempo di inattività causato da una finestra di cutover. Se scegli un'app che ha severi requisiti di disponibilità, devi implementare una strategia di migrazione dei dati zero-time, ad esempio Y (scrittura e lettura) o sviluppando un microservizio di accesso ai dati. Sebbene questo approccio sia possibile, distrae i tuoi team dall'esperienza dell'esperienza necessaria con Google Cloud, in quanto devono dedicare del tempo per implementare tali 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 per il sito di e-commerce in cui gli utenti finalizzano le transazioni.

Trovare assistenza

Google Cloud offre varie opzioni e risorse per trovare l'assistenza e l'assistenza necessarie per utilizzare al meglio i servizi Google Cloud:

  • Risorse self-service. Se non hai bisogno di assistenza dedicata, hai a disposizione diverse opzioni che puoi utilizzare secondo i tuoi tempi.
  • Partner tecnologici. Google Cloud ha collaborato con diverse società per aiutarti a utilizzare i nostri prodotti e servizi.
  • Servizi professionali di Google Cloud. I nostri servizi professionali possono aiutarti a ottenere il massimo dal tuo investimento in Google Cloud.

Sono disponibili altre risorse per aiutare a eseguire la migrazione dei carichi di lavoro in Google Cloud nel Google Cloud Migration Center.

Per ulteriori informazioni su queste risorse, consulta la sezione di assistenza su Migrazione a Google Cloud: guida introduttiva.

Passaggi successivi