Creare architetture ibride e multi-cloud utilizzando Google Cloud

Last reviewed 2023-12-14 UTC

Questa guida all'architettura fornisce indicazioni pratiche per la pianificazione e la progettazione di ambienti ibridi e multi-cloud utilizzando Google Cloud. Questo è il primo dei tre documenti della serie. Esamina le opportunità e le considerazioni associate a queste architetture da un punto di vista aziendale e tecnologico. Inoltre, analizza e analizza molti pattern di architetture ibride e multi-cloud comprovate.

Il set di documenti per i modelli di architettura ibrida e multi-cloud è costituito da queste parti:

Puoi leggere ciascuno di questi articoli sull'architettura in modo indipendente, ma per i maggiori vantaggi, ti consigliamo di leggerli in sequenza prima di prendere una decisione in merito all'architettura.

Il rapido cambiamento nelle richieste del mercato ha aumentato i requisiti e le aspettative per l'IT aziendale, come la scalabilità dinamica, il miglioramento delle prestazioni per un'esperienza utente ottimizzata e la sicurezza. Molte aziende a livello aziendale trovano difficile soddisfare queste esigenze e aspettative utilizzando solo infrastrutture e processi tradizionali. Anche i reparti IT sono sotto pressione per il miglioramento della convenienza economica, il che rende difficile giustificare ulteriori investimenti di capitale in data center e attrezzature.

Una strategia di cloud ibrido che utilizza funzionalità di cloud computing pubblico fornisce una soluzione pragmatica. Utilizzando il cloud pubblico, puoi estendere la capacità e le capacità delle tue piattaforme informatiche senza costi iniziali di investimento di capitale.

L'aggiunta di una o più soluzioni basate su cloud pubblico, come Google Cloud, all'infrastruttura esistente, non solo consente di preservare gli investimenti esistenti, ma evita anche di impegnarti con un unico fornitore di servizi cloud. Inoltre, utilizzando una strategia ibrida, puoi modernizzare le applicazioni e i processi in modo incrementale in base alle risorse consentite.

Per aiutarti a pianificare le decisioni relative all'architettura e la strategia ibrida o multi-cloud, devi tenere in considerazione diverse sfide e considerazioni di progettazione. Questa guida all'architettura in più parti evidenzia sia i potenziali vantaggi delle varie architetture sia le potenziali sfide.

Panoramica del cloud ibrido e del multi-cloud

Poiché i carichi di lavoro, l'infrastruttura e i processi sono unici per ogni azienda, ogni strategia di cloud ibrido deve essere adattata alle tue esigenze specifiche. Il risultato è che i termini cloud ibrido e multi-cloud a volte vengono utilizzati in modo incoerente.

Nell'ambito di questa guida all'architettura di Google Cloud, il termine cloud ibrido descrive un'architettura in cui viene eseguito il deployment dei carichi di lavoro in più ambienti di computing, uno basato sul cloud pubblico e almeno uno privato, ad esempio un data center on-premise o una struttura di colocation.

Il termine multi-cloud descrive un'architettura che combina almeno due CSP pubblici. Come illustrato nel diagramma seguente, a volte questa architettura include un ambiente di computing privato (che potrebbe includere l'utilizzo di un componente del cloud privato). Questa soluzione è chiamata architettura ibrida e multi-cloud.

Diagramma delle tre architetture discusse in questa serie: ibride, multi-cloud e mix di architetture ibride e multi-cloud.

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

Fattori chiave, considerazioni, strategia e approcci

Questo documento definisce e illustra gli obiettivi commerciali, i driver e i requisiti e come questi fattori possono influenzare le decisioni di progettazione durante la creazione di architetture ibride e multi-cloud.

Obiettivi

Un'organizzazione può adottare un'architettura ibrida o multi-cloud come soluzione permanente per soddisfare obiettivi aziendali specifici o come stato temporaneo per facilitare determinati requisiti, come la migrazione al cloud.

Rispondere alle seguenti domande sulla tua attività è un buon modo per definire i tuoi requisiti aziendali e stabilire aspettative specifiche su come raggiungere alcuni o tutti gli obiettivi commerciali. Queste domande si concentrano su ciò che è necessario per la tua attività, non su come raggiungerlo tecnicamente.

  • Quali obiettivi aziendali spingono la decisione di adottare un'architettura ibrida o multi-cloud?
  • Quali sono gli obiettivi aziendali e tecnici che un'architettura ibrida o multi-cloud può raggiungere?
  • Quali fattori aziendali hanno influenzato questi obiettivi?
  • Quali sono i requisiti aziendali specifici?

Nel contesto delle architetture ibride e multi-cloud, un obiettivo aziendale per un cliente aziendale potrebbe essere espandere le operazioni di vendita online o i mercati di un'unica regione per diventare uno dei leader globali nel proprio segmento di mercato. Uno degli scopi commerciali potrebbe essere iniziare ad accettare ordini di acquisto da utenti di tutto il mondo (o da regioni specifiche) entro sei mesi.

Per supportare i requisiti e gli obiettivi aziendali citati in precedenza, un potenziale obiettivo tecnico primario è quello di espandere l'infrastruttura IT e l'architettura delle applicazioni di un'azienda da un modello solo on-premise a un'architettura ibrida, utilizzando le funzionalità e i servizi globali dei cloud pubblici. Questo obiettivo deve essere specifico e misurabile, definendo chiaramente l'ambito di espansione in termini di regioni e tempistiche di destinazione.

In generale, un'architettura ibrida o multi-cloud raramente è un obiettivo in sé, ma piuttosto un mezzo per raggiungere obiettivi tecnici basati su determinati requisiti aziendali. Per scegliere la giusta architettura, ibrida o multi-cloud, occorre prima chiarire questi requisiti.

È importante distinguere tra gli scopi commerciali e quelli tecnici del progetto IT. Gli scopi commerciali devono concentrarsi sull'obiettivo e sulla missione della tua organizzazione. I tuoi obiettivi tecnici dovrebbero concentrarsi sulla creazione di una base tecnologica che consenta alla tua organizzazione di soddisfare i requisiti e gli obiettivi aziendali.

I fattori di business influenzano il raggiungimento degli obiettivi commerciali. Pertanto, una chiara identificazione dei fattori di business può contribuire a modellare tali obiettivi in modo che siano più pertinenti alle esigenze e alle tendenze del mercato.

Il seguente diagramma di flusso illustra i fattori che guidano l'attività, gli obiettivi e i requisiti, nonché gli scopi e i requisiti tecnici, nonché la correlazione tra tutti questi fattori:

Diagramma di flusso che mostra gli aspetti da considerare quando si sviluppano i requisiti tecnici, tra cui i driver aziendali, gli obiettivi, gli scopi e i requisiti, nonché gli obiettivi tecnici.

Fattori aziendali e tecnici

Considera come i tuoi fattori di business influenzano i tuoi obiettivi tecnici. Tra i fattori che spingono il business più comunemente a scegliere un'architettura ibrida, tra cui:

  • Rispettare le leggi e normative sulla sovranità dei dati.
  • Ridurre la spesa in conto capitale (CAPEX) o la spesa IT generale con il supporto di discipline di gestione finanziaria nel cloud e ottimizzazione dei costi come FinOps.
    • L'adozione del cloud può essere guidata da scenari che aiutano a ridurre le spese di capitale, ad esempio la creazione di una soluzione di ripristino di emergenza in un'architettura ibrida o multi-cloud.
  • Migliorare l'esperienza utente.
  • Maggiore flessibilità e agilità per rispondere alle mutevoli richieste del mercato.
  • Migliorare la trasparenza sui costi e sul consumo delle risorse.

Considera il tuo elenco di fattori di business per adottare insieme un'architettura ibrida o multi-cloud. Non considerarli isolati. La decisione finale dipende dall'equilibrio delle priorità aziendali.

Una volta che la tua organizzazione ha compreso i vantaggi del cloud, potrebbe decidere di eseguire la migrazione completa in assenza di vincoli che impediscono di farlo, ad esempio costi o requisiti di conformità specifici che richiedono l'hosting di dati on-premise, estremamente sicuri.

Sebbene l'adozione di un unico cloud provider possa offrire diversi vantaggi, come la minore complessità, le integrazioni incorporate tra i servizi e le opzioni di ottimizzazione dei costi come gli sconti per impegno di utilizzo, esistono comunque alcuni scenari in cui un'architettura multi-cloud può essere vantaggiosa per un'azienda. Di seguito sono riportati i fattori aziendali più comuni per l'adozione di un'architettura multi-cloud, insieme alle considerazioni associate per ciascun conducente:

  • Rispetto delle leggi e delle normative sulla sovranità dei dati: lo scenario più comune è quando un'organizzazione espande la propria attività in una nuova regione o paese e deve rispettare le nuove normative sull'hosting dei dati.
    • Se il provider di servizi cloud usato (CSP) esistente non ha una regione cloud locale in quel paese, ai fini della conformità la soluzione comune è utilizzare un altro CSP che abbia una regione cloud locale in quel paese.
  • Riduzione dei costi: la riduzione dei costi è spesso il motore aziendale più comune per l'adozione di una tecnologia o architettura. Tuttavia, per decidere se adottare un'architettura multi-cloud, è importante considerare qualcosa in più oltre al costo dei servizi e ai potenziali sconti sui prezzi. Tieni conto dei costi di creazione e gestione di una soluzione su più cloud e di eventuali vincoli architetturali che potrebbero derivare da sistemi esistenti.

A volte, le sfide potenziali associate a una strategia multi-cloud possono superare i vantaggi. Una strategia multi-cloud potrebbe introdurre costi aggiuntivi in un secondo momento.

Le sfide comuni associate allo sviluppo di una strategia multi-cloud includono le seguenti:

  • Aumento della complessità di gestione.
  • Garantire una sicurezza coerente.
  • Integrazione degli ambienti software.
  • Ottenere prestazioni e affidabilità cross-cloud coerenti.
  • Creare un team tecnico con competenze multi-cloud può essere costoso e richiedere l'espansione del team, a meno che non sia gestito da un'azienda di terze parti.
  • Gestione dei prezzi dei prodotti e degli strumenti di gestione da ciascun CSP.
  • Utilizzo delle funzionalità uniche di ciascun CSP: un'architettura multi-cloud consente alle organizzazioni di utilizzare nuove tecnologie aggiuntive per migliorare le proprie offerte di capacità di business senza essere limitate alle scelte offerte da un singolo cloud provider.
    • Per evitare rischi o complessità imprevisti, valuta le potenziali sfide con una valutazione di fattibilità ed efficacia, incluse le sfide comuni menzionate in precedenza.
  • Evitare vincoli al fornitore: a volte le aziende vogliono evitare di essere bloccate da un unico cloud provider. Un approccio multi-cloud consente di scegliere la soluzione migliore per le proprie esigenze aziendali. Tuttavia, la fattibilità di questa decisione dipende da diversi fattori, tra cui:
    • Dipendenze tecniche
    • Considerazioni sull'interoperabilità tra le applicazioni
    • Costi di ricostruzione o refactoring delle applicazioni
    • Competenze tecniche
    • Sicurezza e gestibilità coerenti
  • Migliorare il livello di affidabilità e disponibilità delle applicazioni business critical: in alcuni scenari, un'architettura multi-cloud può fornire resilienza alle interruzioni. Ad esempio, se una regione di un CSP smette di funzionare, il traffico può essere instradato a un altro CSP nella stessa regione. Questo scenario presuppone che entrambi i cloud provider supportino le funzionalità o i servizi richiesti in quella regione.

Quando le normative sulla residenza dei dati in un paese o una regione specifici impongono l'archiviazione di dati sensibili, come le informazioni che consentono l'identificazione personale (PII), all'interno di quella località, un approccio multi-cloud può fornire una soluzione conforme. Utilizzando due CSP in una regione per garantire resilienza alle interruzioni, puoi facilitare la conformità alle restrizioni normative e rispettare al contempo i requisiti di disponibilità.

Di seguito sono riportate alcune considerazioni sulla resilienza da valutare prima di adottare un'architettura multi-cloud:

  • Spostamento dei dati: con quale frequenza i dati possono spostarsi all'interno del tuo ambiente multi-cloud?
    • Il trasferimento di dati può comportare costi significativi per il trasferimento di dati?
  • Sicurezza e gestibilità: esistono potenziali complessi in materia di sicurezza o gestibilità?
  • Parità di funzionalità: entrambi i CSP nella regione selezionata offrono le funzionalità e i servizi richiesti?
  • Competenze tecniche: il team ha le competenze necessarie per gestire un'architettura multi-cloud?

Considera tutti questi fattori al momento di valutare la fattibilità di utilizzare un'architettura multi-cloud per migliorare la resilienza.

Nel valutare la fattibilità di un'architettura multi-cloud, è importante considerare i vantaggi a lungo termine. Ad esempio, il deployment di applicazioni su più cloud per il ripristino di emergenza o una maggiore affidabilità potrebbe aumentare i costi a breve termine, ma potrebbe impedire interruzioni o errori. Questi errori possono causare danni finanziari e reputazionali a lungo termine. Pertanto, è importante valutare i costi a breve termine rispetto al valore potenziale a lungo termine dell'adozione del multi-cloud. Inoltre, il valore potenziale a lungo termine può variare in base alle dimensioni dell'organizzazione, alla scala tecnologica, alla criticità della soluzione tecnologica e al settore.

Le organizzazioni che prevedono di creare con successo un ambiente ibrido o multi-cloud dovrebbero valutare la possibilità di creare un Cloud Center of Excellence (COE). Un team COE può diventare il canale per trasformare il modo in cui i team interni dell'organizzazione servono l'azienda durante la transizione al cloud. Il COE è uno dei modi in cui la tua organizzazione può integrare più velocemente il cloud, promuovere la standardizzazione e mantenere un allineamento più solido tra la strategia aziendale e gli investimenti nel cloud.

Se l'obiettivo dell'architettura ibrida o multi-cloud è creare uno stato temporaneo, i fattori aziendali più comuni includono:

  • Necessità di ridurre le spese di capitale proprio o IT generale per i progetti a breve termine.
  • di eseguire rapidamente il provisioning dell'infrastruttura per supportare un caso d'uso aziendale. Ad esempio:
    • Questa architettura potrebbe essere utilizzata per progetti a tempo limitato. Potrebbe essere utilizzata per supportare un progetto che richiede un'infrastruttura distribuita su larga scala per un periodo di tempo limitato, pur utilizzando dati on-premise.
  • La necessità di progetti di trasformazione digitale pluriennali che richiedono una grande impresa di stabilire e che utilizzano per un certo periodo un'architettura ibrida per aiutarli ad allineare la modernizzazione dell'infrastruttura e delle applicazioni alle priorità aziendali.
  • La necessità di creare un'architettura ibrida temporanea, multi-cloud o mista dopo una fusione aziendale. In questo modo la nuova organizzazione può definire una strategia per lo stato finale della nuova architettura Capita spesso che due aziende che vengono unite utilizzano provider cloud diversi o che un'azienda utilizzi un data center privato on-premise e l'altra usi il cloud. In entrambi i casi, il primo passo nella fusione e acquisizione è quasi sempre l'integrazione dei sistemi IT.

Fattori tecnici

La sezione precedente riguardava i fattori di business. Per essere approvate, le principali decisioni sull'architettura hanno quasi sempre bisogno del supporto di quei fattori. Tuttavia, anche fattori tecnici, che possono essere basati su un guadagno o su un vincolo, possono influenzare anche i fattori di business. In alcuni scenari, è necessario tradurre i fattori tecnici in driver aziendali e spiegare in che modo potrebbero influire positivamente o negativamente sull'azienda.

Il seguente elenco non esaustivo contiene alcuni fattori tecnici comuni per l'adozione di un'architettura ibrida o multi-cloud:

  • Sviluppare funzionalità tecnologiche, come AI e servizi di analisi avanzati, che potrebbero essere difficili da implementare in ambienti esistenti.
  • Migliorare la qualità e le prestazioni del servizio.
  • Automatizzare e accelerare le implementazioni delle applicazioni per ottenere un time to market più rapido e tempi di ciclo più brevi.
  • Utilizzo di API e servizi di alto livello per accelerare lo sviluppo.
  • Accelerazione del provisioning delle risorse di computing e archiviazione.
  • Usare servizi serverless per creare funzionalità e servizi elastici in modo più rapido e su larga scala.
  • creare architetture globali o multiregionali al fine di soddisfare determinati requisiti tecnici.

Il driver tecnico più comune per le architetture multi-cloud temporanee e ibride temporanee è facilitare la migrazione da on-premise al cloud o a un cloud aggiuntivo. In generale, le migrazioni al cloud portano quasi sempre naturalmente alla configurazione del cloud ibrido. Le aziende devono eseguire sistematicamente la transizione di applicazioni e dati in base alle priorità. Analogamente, una configurazione a breve termine potrebbe essere intesa per facilitare una proof of concept utilizzando tecnologie avanzate disponibili nel cloud per un determinato periodo.

Decisioni di progettazione tecnica

L'obiettivo tecnico identificato e i suoi fattori chiave sono fondamentali per prendere una decisione relativa all'architettura basata sul business e selezionare uno dei modelli di architettura discussi in questa guida. Ad esempio, per supportare un obiettivo commerciale specifico, un'azienda potrebbe impostare uno scopo commerciale per creare una pratica di ricerca e sviluppo da tre a sei mesi. Il principale requisito aziendale per supportare questo obiettivo potrebbe essere quello di creare l'ambiente tecnologico necessario per la ricerca e la progettazione con il minor costo di spesa per investimenti possibile.

L'obiettivo tecnico in questo caso è avere una configurazione temporanea del cloud ibrido. Il motore per questo obiettivo tecnico è sfruttare il modello di prezzi on demand del cloud per soddisfare le esigenze aziendali indicate in precedenza. Un altro fattore è influenzato da specifici requisiti tecnologici che richiedono una soluzione basata su cloud con elevata capacità di calcolo e una rapida configurazione.

Utilizza Google Cloud per le architetture ibride e multi-cloud

L'uso di soluzioni open source può semplificare l'adozione di un approccio ibrido e multi-cloud e ridurre al minimo i vincoli al fornitore. Tuttavia, quando pianifichi un'architettura, dovresti prendere in considerazione le seguenti potenziali complessità:

  • Interoperabilità
  • Gestibilità
  • Costo
  • Sicurezza

Creare su una piattaforma cloud che contribuisce e supporta l'open source può contribuire a semplificare il percorso verso l'adozione di architetture ibride e multi-cloud. Il cloud aperto consente di adottare un approccio che offre la massima scelta e semplifica la complessità. Inoltre, Google Cloud offre la flessibilità necessaria per migrare, creare e ottimizzare le applicazioni in ambienti ibridi e multi-cloud, riducendo al minimo i vincoli al fornitore, utilizzando le migliori soluzioni e rispettando i requisiti normativi.

Google è inoltre uno dei migliori collaboratori dell'ecosistema open source e collabora con la community open source per sviluppare tecnologie open source note come Kubernetes. Quando implementato come servizio gestito, Kubernetes può aiutare a ridurre le complessità legate alla gestibilità e alla sicurezza ibridi e multi-cloud.

Pianifica una strategia ibrida e multi-cloud

Questo documento spiega come applicare le considerazioni aziendali predefinite quando si pianifica una strategia ibrida e multi-cloud. Amplia le linee guida in Driver, considerazioni, strategia e approcci. L'articolo definisce e analizza le considerazioni aziendali di cui le aziende devono tenere conto quando pianificano una strategia di questo tipo.

Chiarisci e concorda la vision e gli obiettivi

In definitiva, lo scopo principale di una strategia ibrida o multi-cloud è raggiungere i requisiti aziendali identificati e gli obiettivi tecnici associati per ciascun caso d'uso aziendale, in linea con gli obiettivi commerciali specifici. Per raggiungere questo obiettivo, crea un piano ben strutturato che includa le seguenti considerazioni:

Tenere presente che definire un piano che tenga in considerazione tutti i carichi di lavoro e i requisiti è, nella migliore delle ipotesi, difficile, soprattutto in un ambiente IT complesso. Inoltre, la pianificazione richiede tempo e potrebbe portare a visioni da parte degli stakeholder concorrenti.

Per evitare queste situazioni, inizialmente formula una dichiarazione visiva che risponda alle seguenti domande (come minimo):

  • Qual è il caso d'uso aziendale target per raggiungere gli scopi commerciali specifici?
  • Perché l'approccio e l'ambiente di calcolo attuali non sono sufficienti per raggiungere gli obiettivi?
  • Quali sono gli aspetti tecnologici principali per cui eseguire l'ottimizzazione con il cloud pubblico?
  • Perché e in che modo il nuovo approccio ottimizzerà e raggiungerà i tuoi scopi commerciali?
  • Per quanto tempo prevedi di utilizzare la tua configurazione ibrida o multi-cloud?

Un accordo sugli obiettivi aziendali e tecnici chiave e i fattori di motivazione, quindi ottenere l'approvazione pertinente degli stakeholder può fornire le basi per i passaggi successivi del processo di pianificazione. Per allineare efficacemente la soluzione proposta con la vision architetturale generale della tua organizzazione, allineati al tuo team e agli stakeholder responsabili della guida e della sponsorizzazione di questa iniziativa.

Identificare e chiarire altre considerazioni

Quando pianifichi un'architettura ibrida o multi-cloud, è importante identificare e concordare i vincoli architetturali e operativi del progetto.

Per quanto riguarda le operazioni, il seguente elenco non esaustivo fornisce alcuni requisiti che potrebbero creare alcuni vincoli da considerare durante la pianificazione dell'architettura:

  • Gestire e configurare più cloud separatamente rispetto alla creazione di un modello olistico per gestire e proteggere i diversi ambienti cloud.
  • Garantire autenticazione, autorizzazione, controllo e criteri coerenti in tutti gli ambienti.
  • Utilizzare strumenti e processi coerenti nei vari ambienti per fornire una visione olistica su sicurezza, costi e opportunità di ottimizzazione.
  • Usare standard di conformità e sicurezza coerenti per applicare una governance unificata.

Per quanto riguarda la pianificazione dell'architettura, i vincoli più grandi spesso provengono dai sistemi esistenti e possono includere quanto segue:

  • Dipendenze tra le applicazioni
  • Requisiti di prestazioni e latenza per la comunicazione tra i sistemi
  • Dipendenza da hardware o sistemi operativi che potrebbero non essere disponibili nel cloud pubblico
  • Limitazioni di licenza
  • Dipendenza dalla disponibilità delle funzionalità richieste nelle regioni selezionate di un'architettura

Per ulteriori informazioni sulle altre considerazioni relative alla portabilità dei carichi di lavoro, allo spostamento dei dati e agli aspetti di sicurezza, consulta Altre considerazioni.

Progetta una strategia per un'architettura ibrida e multi-cloud

Dopo aver chiarito le specifiche degli obiettivi aziendali e tecnici con i requisiti aziendali associati (e idealmente chiarito e concordato una dichiarazione visionale), puoi creare la tua strategia per creare un'architettura ibrida o multi-cloud.

Il seguente diagramma di flusso riassume i passaggi logici per creare tale strategia.

Al momento di sviluppare una strategia, considera i tuoi scopi commerciali, incentiva la strategia, sviluppa un piano di alto livello e utilizzalo per definire la tua strategia.

Per aiutarti a determinare le esigenze e gli scopi tecnici dell'architettura ibrida o multi-cloud, i passaggi nel diagramma di flusso precedente iniziano con i requisiti e gli obiettivi aziendali. Il modo in cui implementi la tua strategia può variare a seconda degli obiettivi, dei fattori trainanti e del percorso di migrazione tecnologico di ciascun caso d'uso aziendale.

È importante ricordare che una migrazione è un viaggio. Il seguente diagramma illustra le fasi di questo percorso come descritto in Eseguire la migrazione a Google Cloud.

Percorso di migrazione diviso in quattro fasi.

Questa sezione fornisce indicazioni sulle fasi "Valuta", "Pianifica", "Esegui il deployment" e "Ottimizza" nel diagramma precedente. Presenta queste informazioni nel contesto di una migrazione ibrida o multi-cloud. Devi allineare ogni migrazione alle indicazioni e alle best practice discusse nella sezione del percorso di migrazione della guida Migrate to Google Cloud. Queste fasi possono applicarsi a ogni singolo carico di lavoro, non a tutti i carichi di lavoro contemporaneamente. In qualsiasi momento, diversi carichi di lavoro possono trovarsi in fasi diverse:

Valuta la fase

Nella fase Valutazione, esegui una valutazione iniziale del carico di lavoro. Durante questa fase, considera gli obiettivi delineati nei documenti di pianificazione della vision e della strategia. Scegli un piano di migrazione identificando prima un elenco di carichi di lavoro candidati di carichi di lavoro che potrebbero trarre vantaggio dal deployment o dalla migrazione nel cloud pubblico.

Per iniziare, scegli un carico di lavoro non critico per l'azienda o troppo difficile da migrare (con dipendenze minime o nulle da qualsiasi carico di lavoro in altri ambienti), ma abbastanza tipico da fungere da modello per i deployment o le migrazioni imminenti.

Idealmente, il carico di lavoro o l'applicazione selezionati dovrebbero far parte di una funzione o di un caso d'uso aziendale mirato che abbia un effetto misurabile sull'azienda al termine.

Per valutare e mitigare eventuali rischi potenziali di migrazione, esegui una valutazione dei rischi di migrazione. È importante valutare il carico di lavoro candidato per determinare se è idoneo alla migrazione a un ambiente multi-cloud. Questa valutazione comporta la valutazione di vari aspetti delle applicazioni e dell'infrastruttura, tra cui:

  • Requisiti di compatibilità delle applicazioni con i cloud provider selezionati
  • Modelli di prezzo
  • Funzionalità di sicurezza offerte dai cloud provider selezionati
  • Requisiti di interoperabilità delle applicazioni

L'esecuzione di una valutazione consente inoltre di identificare i requisiti di privacy dei dati, di conformità, di coerenza e di soluzioni in più ambienti cloud. I rischi identificati possono influire sui carichi di lavoro di cui scegli di eseguire la migrazione o di eseguire le operazioni.

Esistono diversi tipi di strumenti, come il Centro di migrazione di Google Cloud, per aiutarti a valutare i carichi di lavoro esistenti. Per ulteriori informazioni, consulta Migrazione a Google Cloud: scegli uno strumento di valutazione.

Dal punto di vista della modernizzazione dei carichi di lavoro, lo strumento di valutazione dell'idoneità aiuta a valutare un carico di lavoro VM per determinare se è adatto alla modernizzazione a un container o alla migrazione su Compute Engine.

Fase del piano

Nella fase di pianificazione, inizia con le applicazioni identificate e i carichi di lavoro cloud richiesti ed esegui le attività seguenti:

  1. Sviluppa una strategia di migrazione prioritaria che definisce le onde e i percorsi di migrazione delle applicazioni.
  2. Identificare il pattern di architettura delle applicazioni ibride o multi-cloud di alto livello applicabile.
  3. Seleziona un pattern di architettura di networking che supporti il pattern di architettura dell'applicazione selezionato.

Idealmente, dovresti incorporare il pattern di cloud networking con la progettazione della zona di destinazione. La progettazione della zona di destinazione funge da elemento fondamentale delle architetture ibride e multi-cloud complessive. La progettazione richiede un'integrazione perfetta con questi pattern. Non progettare la zona di destinazione in isolamento. Considera questi pattern di networking come sottoinsieme della progettazione della zona di destinazione.

Una zona di destinazione può essere composta da diverse applicazioni, ciascuna con un diverso modello di architettura di networking. Inoltre, in questa fase, è importante decidere il design della gerarchia delle organizzazioni, dei progetti e delle risorse di Google Cloud per preparare la zona di destinazione dell'ambiente cloud per l'integrazione e il deployment ibridi o multi-cloud.

Nell'ambito di questa fase, devi considerare quanto segue:

  • Definire l'approccio alla migrazione e alla modernizzazione. Ulteriori informazioni sugli approcci alla migrazione saranno disponibili più avanti in questa guida. È trattato in modo più dettagliato anche nella sezione sui tipi di migrazione di Eseguire la migrazione a Google Cloud.
  • Utilizza i risultati della fase di valutazione e scoperta. Allineale al carico di lavoro dei candidati di cui prevedi di eseguire la migrazione. Quindi sviluppa un piano di Migration Waves dell'applicazione. Il piano deve incorporare i requisiti stimati per il dimensionamento delle risorse che hai determinato durante la fase di valutazione.
  • Definire il modello di comunicazione richiesto tra le applicazioni distribuite e tra i componenti dell'applicazione per l'architettura ibrida o multi-cloud prevista.
  • Scegli un archetipo di deployment adatto per il deployment del carico di lavoro, ad esempio a livello di zona, a livello di regione, multiregionale o globale, per il modello di architettura scelto. L'archetipo che selezioni costituisce la base per costruire architetture di deployment specifiche per l'applicazione su misura per le tue esigenze aziendali e tecniche.
  • Stabilisci i criteri di successo misurabili per la migrazione, con traguardi chiari per ogni fase o fase della migrazione. La selezione dei criteri è essenziale, anche se l'obiettivo tecnico è fare in modo che l'architettura ibrida sia una configurazione a breve termine.
  • Definisci gli SLA (accordi sul livello del servizio) e i KPI delle applicazioni quando le applicazioni operano in una configurazione ibrida, in particolare per quelle applicazioni che potrebbero avere componenti distribuiti in più ambienti.

Per ulteriori informazioni, consulta Informazioni sulla pianificazione della migrazione per pianificare una migrazione di successo e ridurre al minimo i rischi associati.

Fase di deployment

Nella fase di deployment, puoi iniziare a eseguire la tua strategia di migrazione. Dato il potenziale numero di requisiti, è meglio adottare un approccio iterativo.

Assegna le priorità ai carichi di lavoro in base alle wave di migrazione e applicazioni sviluppate durante la fase di pianificazione. Con le architetture ibride e multi-cloud, avvia il deployment stabilendo la connettività necessaria tra Google Cloud e gli altri ambienti di computing. Per facilitare il modello di comunicazione richiesto per la tua architettura ibrida o multi-cloud, basa il deployment sul tipo di progettazione e connettività di rete selezionato, insieme al pattern di networking applicabile. Ti consigliamo di adottare questo approccio per prendere una decisione generale sulla progettazione della zona di destinazione.

Inoltre, devi testare e convalidare l'applicazione o il servizio in base ai criteri di successo dell'applicazione definiti. Idealmente, questi criteri dovrebbero includere i requisiti di test funzionali e di carico (non funzionali) prima di passare alla produzione.

Fase di ottimizzazione

Nella fase Ottimizzazione, testa il deployment: dopo aver completato i test e se l'applicazione o il servizio soddisfa le aspettative in termini di capacità funzionale e prestazioni, puoi portarlo in produzione. Gli strumenti di monitoraggio e visibilità su cloud, come Cloud Monitoring, sono in grado di fornire insight su prestazioni, disponibilità e integrità delle tue applicazioni e dell'infrastruttura e ti aiutano a eseguire l'ottimizzazione laddove necessario.

Per maggiori informazioni, consulta Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente. Per saperne di più su come progettare questi strumenti per un'architettura ibrida o multi-cloud, consulta Pattern di monitoraggio e logging ibridi e multi-cloud.

Valuta i carichi di lavoro candidati

La scelta di ambienti di computing per diversi carichi di lavoro influisce notevolmente sul successo di una strategia ibrida e multi-cloud. Le decisioni sul posizionamento del carico di lavoro devono essere in linea con gli scopi commerciali specifici. Pertanto, queste decisioni devono basarsi su casi d'uso aziendali mirati che consentano effetti aziendali misurabili. Tuttavia, non è sempre necessario né consigliato iniziare con il carico di lavoro/l'applicazione più critici per l'azienda. Per ulteriori informazioni, consulta Scegliere le app di cui eseguire la migrazione per prime nella guida Migrate to Google Cloud.

Come discusso nella sezione Driver aziendali e tecnici, esistono diversi tipi di driver e considerazioni per le architetture ibride e multi-cloud.

Il seguente elenco riepilogativo di fattori può aiutarti a valutare il tuo caso d'uso per la migrazione nel contesto di un'architettura ibrida o multi-cloud con la possibilità di ottenere un effetto aziendale misurabile:

  • Potenziale per la differenziazione o l'innovazione di mercato tramite l'uso di servizi cloud per abilitare determinate funzioni o capacità aziendali, ad esempio le funzionalità di intelligence artificiale che utilizzano dati on-premise esistenti per addestrare modelli di machine learning.
  • Potenziali risparmi sul costo totale di proprietà per un'applicazione.
  • Potenziali miglioramenti in termini di disponibilità, resilienza, sicurezza o prestazioni, ad esempio l'aggiunta di un sito per il ripristino di emergenza (RE) nel cloud.
  • Potenziale accelerazione dei processi di sviluppo e rilascio, ad esempio la creazione di ambienti di sviluppo e test nel cloud.

I seguenti fattori possono aiutarti a valutare i rischi della migrazione:

  • Il potenziale effetto di interruzioni causate da una migrazione.
  • L'esperienza del tuo team con i deployment nel cloud pubblico o con i deployment per un cloud provider nuovo o secondo.
  • La necessità di rispettare eventuali restrizioni legali o normative esistenti.

I seguenti fattori possono aiutarti a valutare le difficoltà tecniche di una migrazione:

  • Le dimensioni, la complessità e l'età dell'applicazione.
  • Il numero di dipendenze con altre applicazioni e servizi nei diversi ambienti di elaborazione.
  • Eventuali restrizioni imposte da licenze di terze parti.
  • Eventuali dipendenze da versioni specifiche di sistemi operativi, database o altre configurazioni di ambiente.

Dopo aver valutato i carichi di lavoro iniziali, puoi iniziare a assegnargli la priorità e definire le onde di migrazione e gli approcci. Potrai quindi identificare i pattern di architettura applicabili e i pattern di networking di supporto. Questo passaggio potrebbe richiedere più iterazioni, perché la valutazione potrebbe cambiare nel tempo. Vale quindi la pena rivalutare i carichi di lavoro dopo aver eseguito i primi deployment cloud.

Approcci all'architettura per l'adozione di un'architettura ibrida o multi-cloud

Questo documento fornisce indicazioni su approcci comuni e comprovati e considerazioni per eseguire la migrazione dei carichi di lavoro nel cloud. Approfondisce le linee guida riportate in Progettare una strategia per un'architettura ibrida e multi-cloud, che illustra i vari passaggi possibili e consigliati per progettare una strategia per l'adozione di un'architettura ibrida o multi-cloud.

Cloud-first

Un modo comune per iniziare a utilizzare il cloud pubblico è l'approccio cloud-first. Con questo approccio, esegui il deployment dei nuovi carichi di lavoro nel cloud pubblico, mentre quelli esistenti rimangono dove si trovano. In tal caso, prendi in considerazione un deployment classico in un ambiente di computing privato solo se un deployment nel cloud pubblico è impossibile per motivi tecnici o organizzativi.

La strategia cloud-first presenta vantaggi e svantaggi. Il lato positivo è che è lungimirante. Puoi eseguire il deployment di nuovi carichi di lavoro in modo modernizzato, evitando (o almeno riducendo al minimo) i problemi legati alla migrazione dei carichi di lavoro esistenti.

Sebbene un approccio cloud-first possa offrire determinati vantaggi, potrebbe trasmettere potenziali opportunità di miglioramento o utilizzo dei carichi di lavoro esistenti. I nuovi carichi di lavoro potrebbero rappresentare una frazione del panorama IT complessivo e il loro effetto sulle spese e sulle prestazioni IT può essere limitato. L'allocazione di tempo e risorse alla migrazione di un carico di lavoro esistente potrebbe portare a vantaggi o risparmi sui costi più sostanziali rispetto a quando si tenta di accogliere un nuovo carico di lavoro nell'ambiente cloud.

Seguendo un rigoroso approccio cloud-first, rischi anche di aumentare la complessità generale del tuo ambiente IT. Questo approccio potrebbe creare ridondanze, prestazioni inferiori a causa di una potenziale comunicazione cross-environment eccessiva o portare a un ambiente di computing non adatto al singolo carico di lavoro. Inoltre, la conformità alle normative del settore e alle leggi sulla privacy dei dati può impedire alle aziende di eseguire la migrazione di determinate applicazioni che contengono dati sensibili.

Considerati questi rischi, potrebbe essere meglio utilizzare un approccio cloud-first solo per determinati carichi di lavoro. L'approccio cloud-first consente di concentrarsi sui carichi di lavoro che possono trarre vantaggio da un deployment o una migrazione cloud. Questo approccio considera anche la modernizzazione dei carichi di lavoro esistenti.

Un esempio comune di architettura ibrida cloud-first è quando le applicazioni e i servizi legacy che contengono dati critici devono essere integrati con nuovi dati o applicazioni. Per completare l'integrazione, puoi utilizzare un'architettura ibrida che modernizza i servizi legacy mediante le interfacce API, che li sbloccano per il consumo da parte di nuovi servizi e applicazioni cloud. Con una piattaforma di gestione delle API cloud, come Apigee, puoi implementare questi casi d'uso con modifiche minime alle applicazioni e aggiungere sicurezza, analisi e scalabilità ai servizi legacy.

Migrazione e modernizzazione

Il multi-cloud ibrido e la modernizzazione dell'IT sono concetti distinti collegati in un circolo virtuoso. Il cloud pubblico può facilitare e semplificare la modernizzazione dei carichi di lavoro IT. La modernizzazione dei carichi di lavoro IT può aiutarti a ottenere di più dal cloud.

Gli obiettivi principali della modernizzazione dei carichi di lavoro sono i seguenti:

  • Ottieni una maggiore agilità per adattarti ai requisiti in continuo cambiamento.
  • Riduci i costi dell'infrastruttura e delle operazioni.
  • Aumenta l'affidabilità e la resilienza per ridurre al minimo i rischi.

Tuttavia, potrebbe non essere possibile modernizzare contemporaneamente ogni applicazione durante il processo di migrazione. Come descritto in Migrazione a Google Cloud, puoi implementare uno dei seguenti tipi di migrazione o anche combinare più tipi in base alle esigenze:

  • Rehosting (lift and shift)
  • Replatforming (lift and Optimize)
  • Refactoring (spostamento e miglioramento)
  • Riprogetta (continua per modernizzare)
  • Ricrea (rimuovi e sostituisci, a volte chiamato ripresa e sostituisci)
  • Riacquisto

Quando si prendono decisioni strategiche sulle architetture ibride e multi-cloud, è importante considerare la fattibilità della strategia dal punto di vista dei costi e dei tempi. L'approccio alla migrazione è graduale. Il passaggio successivo prevede il lift and shift o il replatforming e poi il refactoring o riprogettazione. In genere, il lift and shifting aiuta a ottimizzare le applicazioni dal punto di vista dell'infrastruttura. Quando le applicazioni sono in esecuzione nel cloud, è più facile utilizzare e integrare i servizi cloud per ottimizzarli ulteriormente mediante architetture e funzionalità cloud-first. Inoltre, queste applicazioni possono comunque comunicare con altri ambienti tramite una connessione di rete ibrida.

Ad esempio, è possibile eseguire il refactoring o la riprogettazione di una grande applicazione monolitica basata su VM e trasformarla in vari microservizi indipendenti, sulla base di un'architettura di microservizi basata su cloud. In questo esempio, l'architettura dei microservizi utilizza servizi per container gestiti di Google Cloud come Google Kubernetes Engine (GKE) o Cloud Run. Tuttavia, se l'architettura o l'infrastruttura di un'applicazione non è supportata nell'ambiente cloud di destinazione così com'è, potresti valutare di iniziare con il replatforming, il refactoring o la riprogettazione della strategia di migrazione per superare questi vincoli ove possibile.

Quando utilizzi uno di questi approcci alla migrazione, valuta la possibilità di modernizzare le tue applicazioni (ove applicabile e fattibile). La modernizzazione può richiedere l'adozione e l'implementazione dei principi di Site Reliability Engineering (SRE) o DevOps, tale che potrebbe essere necessario estendere la modernizzazione delle applicazioni al tuo ambiente privato in una configurazione ibrida. Anche se l'implementazione dei principi SRE coinvolge fondamentalmente la progettazione, è più un processo di trasformazione che una sfida tecnica. Di conseguenza, probabilmente richiedono cambiamenti procedurali e culturali. Per saperne di più su come il primo passo per implementare l'SRE in un'organizzazione sia ottenere il sostegno del team dirigenziale, consulta Con SRE, non pianificare correttamente.

Combina e abbina gli approcci alla migrazione

Ogni approccio alla migrazione qui discusso presenta determinati punti di forza e di debolezza. Un vantaggio chiave di seguire una strategia ibrida e multi-cloud è che non è necessario accontentarsi di un singolo approccio. Puoi invece decidere quale approccio funziona meglio per ogni carico di lavoro o stack di applicazioni, come mostrato nel diagramma seguente.

Diagramma di flusso che mostra i diversi approcci alla migrazione dei carichi di lavoro dall'ambiente cloud.

Questo diagramma concettuale illustra i vari percorsi o approcci di migrazione e modernizzazione che possono essere applicati contemporaneamente a diversi carichi di lavoro, guidati dagli unici requisiti aziendali, tecnici e obiettivi di ogni carico di lavoro o applicazione.

Inoltre, non è necessario che gli stessi componenti dello stack di applicazioni seguano lo stesso approccio o strategia di migrazione. Ad esempio:

  • Il database on-premise backend di un'applicazione può essere sottoposto a replatforming da MySQL self-hosted a un database gestito utilizzando Cloud SQL in Google Cloud.
  • È possibile eseguire il refactoring delle macchine virtuali frontend delle applicazioni per l'esecuzione su container utilizzando GKE Autopilot, dove Google gestisce la configurazione del cluster, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate.
  • La soluzione di bilanciamento del carico hardware on-premise e le funzionalità WAF firewall dell'applicazione web possono essere sostituite con Cloud Load Balancing e Google Cloud Armor.

Scegli rehosting (lift and shift), se per i carichi di lavoro si verifica una delle seguenti condizioni:

  • e hanno un numero relativamente ridotto di dipendenze nell'ambiente.
  • Non viene considerato la necessità di eseguire il refactoring, oppure il refactoring prima che la migrazione non sia fattibile.
  • Si basano su software di terze parti.

Valuta la possibilità di eseguire il refactoring (spostamento e miglioramento) per questi tipi di carichi di lavoro:

  • Hanno dipendenze che devono essere distribuite.
  • Si basano su sistemi operativi, hardware o database che non possono essere inseriti nel cloud.
  • Non utilizzano in modo efficiente le risorse di calcolo o archiviazione.
  • e non possono essere implementate in modo automatizzato senza uno sforzo.

Valuta se la ricreazione (rimozione e sostituzione) soddisfa le tue esigenze per questi tipi di carichi di lavoro:

  • Non soddisfano più i requisiti attuali.
  • Possono essere incorporate con altre applicazioni che offrono funzionalità simili senza compromettere i requisiti aziendali.
  • Si basano su tecnologie di terze parti che hanno raggiunto la fine del loro ciclo di vita.
  • Richiedono tariffe per licenze di terze parti che non sono più economiche.

Il Rapid Migration Program mostra come Google Cloud aiuta i clienti a utilizzare le best practice, ridurre i rischi, controllare i costi e semplificare il percorso verso il successo nel cloud.

Altre considerazioni

Questo documento evidenzia le considerazioni chiave di progettazione che svolgono un ruolo fondamentale nel plasmare l'architettura ibrida e multi-cloud complessiva. Analizza e valuta queste considerazioni in modo olistico nell'intera architettura della soluzione, comprendendo tutti i carichi di lavoro, non solo quelli specifici.

Esegui il refactoring

In una migrazione di refactoring, modificherai i carichi di lavoro per sfruttare le funzionalità del cloud, non solo per farli funzionare nel nuovo ambiente. Puoi migliorare ogni carico di lavoro in termini di prestazioni, funzionalità, costi ed esperienza utente. Come evidenziato in Refactoring: spostamento e miglioramento, alcuni scenari di refactoring consentono di modificare i carichi di lavoro prima di eseguirne la migrazione al cloud. Questo approccio di refactoring offre i seguenti vantaggi, in particolare se il tuo obiettivo è creare un'architettura ibrida come architettura con targeting a lungo termine:

  • Puoi migliorare il processo di deployment.
  • Puoi accelerare la cadenza di rilascio e abbreviare i cicli di feedback sfruttando l'infrastruttura e gli strumenti di integrazione continua/deployment continuo (CI/CD).
  • Puoi utilizzare il refactoring come base per creare e gestire un'architettura ibrida con portabilità delle applicazioni.

Per funzionare correttamente, questo approccio richiede in genere determinati investimenti in infrastrutture e strumenti on-premise. Ad esempio, configurare un Container Registry locale e il provisioning di cluster Kubernetes per containerizzare le applicazioni. La versione Google Kubernetes Engine (GKE) Enterprise può essere utile in questo approccio per gli ambienti ibridi. Per saperne di più su GKE Enterprise, consulta la sezione seguente. Per ulteriori dettagli, puoi anche consultare l'architettura di riferimento dell'ambiente ibrido di GKE Enterprise.

Portabilità del carico di lavoro

Con le architetture ibride e multi-cloud, potrebbe essere utile spostare i carichi di lavoro tra gli ambienti di computing che ospitano i tuoi dati. Per consentire lo spostamento senza interruzioni dei carichi di lavoro da un ambiente all'altro, considera i seguenti fattori:

  • Puoi spostare un'applicazione da un ambiente di computing a un altro senza modificare in modo significativo l'applicazione e il relativo modello operativo:
    • il deployment e la gestione delle applicazioni sono coerenti in tutti gli ambienti di computing.
    • Visibilità, configurazione e sicurezza sono coerenti in tutti gli ambienti di computing.
  • La capacità di rendere portabile un carico di lavoro non deve essere in conflitto con il carico di lavoro cloud-first.

Automazione dell'infrastruttura

L'automazione dell'infrastruttura è essenziale per la portabilità nelle architetture ibride e multi-cloud. Un approccio comune all'automazione della creazione di infrastrutture è tramite Infrastructure as Code (IaC). IaC prevede la gestione dell'infrastruttura in file, invece di configurare manualmente le risorse, come una VM, un gruppo di sicurezza o un bilanciatore del carico, in un'interfaccia utente. Terraform è un noto strumento IaC per definire le risorse di infrastruttura in un file. Terraform consente inoltre di automatizzare la creazione di queste risorse in ambienti eterogenei.

Per saperne di più sulle funzioni principali di Terraform che possono aiutarti ad automatizzare il provisioning e la gestione delle risorse Google Cloud, consulta Progetti e moduli Terraform per Google Cloud.

Puoi utilizzare strumenti di gestione delle configurazioni come Ansible, Puppet o Chef per stabilire un processo di deployment e configurazione comune. In alternativa, puoi utilizzare uno strumento di baking delle immagini come Packer per creare immagini VM per piattaforme diverse. Utilizzando un singolo file di configurazione condiviso, puoi utilizzare Packer e Cloud Build per creare un'immagine VM da utilizzare su Compute Engine. Infine, puoi utilizzare soluzioni come Prometheus e Grafana per garantire un monitoraggio coerente tra tutti gli ambienti.

Sulla base di questi strumenti, puoi creare una catena di strumenti comune come illustrato nel seguente diagramma logico. Questa catena di strumenti comune elimina le differenze tra gli ambienti di computing. Consente inoltre di unificare provisioning, deployment, gestione e monitoraggio.

Una catena di strumenti consente la portabilità delle applicazioni.

Sebbene una catena di strumenti comune possa aiutarti a raggiungere la portabilità, presenta diversi dei seguenti inconvenienti:

  • Usare le VM come base comune può rendere difficile l'implementazione di applicazioni cloud-first vere. Inoltre, l'uso delle VM solo può impedirti di usare i servizi gestiti nel cloud. Potresti perdere l'opportunità di ridurre i costi amministrativi.
  • La creazione e la gestione di una catena di strumenti comune comporta costi operativi e overhead.
  • Con l'espansione della catena di strumenti, può sviluppare complessità uniche, su misura per le esigenze specifiche della tua azienda. Questa maggiore complessità può contribuire all'aumento dei costi di formazione.

Prima di decidere di sviluppare strumenti e automazione, esplora i servizi gestiti offerti dal tuo cloud provider. Quando il tuo provider offre servizi gestiti che supportano lo stesso caso d'uso, puoi astraerne parte. In questo modo puoi concentrarti sul carico di lavoro e sull'architettura delle applicazioni anziché sull'infrastruttura sottostante.

Ad esempio, puoi utilizzare il modello di risorse di Kubernetes per automatizzare la creazione di cluster Kubernetes utilizzando un approccio alla configurazione dichiarativa. Puoi utilizzare la conversione di Deployment Manager per convertire le configurazioni e i modelli di Deployment Manager in altri formati di configurazione dichiarativi supportati da Google Cloud (come Terraform e il modello di risorse di Kubernetes), in modo che siano portabili quando pubblica.

Puoi anche considerare l'automazione della creazione di progetti e di risorse all'interno di questi progetti. Questa automazione può aiutarti ad adottare un approccio Infrastructure as Code per il provisioning del progetto.

Container e Kubernetes

L'utilizzo di funzionalità gestite nel cloud aiuta a ridurre la complessità della creazione e della manutenzione di una catena di strumenti personalizzati per ottenere automazione e portabilità dei carichi di lavoro. Tuttavia, solo l'utilizzo delle VM come base comune rende difficile implementare applicazioni davvero cloud-first. Una soluzione è utilizzare container e Kubernetes.

I container consentono un'esecuzione affidabile del software quando lo sposti da un ambiente all'altro. Poiché i container disaccoppiano le applicazioni dall'infrastruttura host sottostante, facilitano il deployment in diversi ambienti di computing, ad esempio quelli ibridi e multi-cloud.

Kubernetes gestisce l'orchestrazione, il deployment, la scalabilità e la gestione delle applicazioni containerizzate. È open source ed è regolato dalla Cloud Native Computing Foundation. Kubernetes fornisce i servizi che costituiscono la base di un'applicazione cloud-first. Poiché è possibile installare ed eseguire Kubernetes su molti ambienti di computing, puoi utilizzarlo anche per stabilire un livello di runtime comune in tutti gli ambienti di computing:

  • Kubernetes fornisce gli stessi servizi e le stesse API in un ambiente cloud o di computing privato. Inoltre, il livello di astrazione è molto più elevato rispetto a quando si lavora con le VM, il che si traduce in genere in basi meno necessarie e in una migliore produttività degli sviluppatori.
  • A differenza di una catena di strumenti personalizzata, Kubernetes è ampiamente adottato sia per lo sviluppo che per la gestione delle applicazioni, per cui è possibile attingere a competenze, documentazione e assistenza di terze parti esistenti.
  • Kubernetes supporta tutte le implementazioni di container che:

Quando un carico di lavoro è in esecuzione su Google Cloud, puoi evitare di installare e utilizzare Kubernetes utilizzando una piattaforma Kubernetes gestita come Google Kubernetes Engine (GKE). In questo modo è possibile aiutare il personale operativo a spostare l'attenzione dalla creazione e gestione dell'infrastruttura alla creazione e alla gestione delle applicazioni.

Puoi anche utilizzare Autopilot, una modalità operativa di GKE che gestisce la configurazione del cluster, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate. Quando utilizzi GKE Autopilot, considera i tuoi requisiti di scalabilità e i relativi limiti di scalabilità.

Tecnicamente, è possibile installare ed eseguire Kubernetes su molti ambienti di computing per stabilire un livello di runtime comune. In pratica, tuttavia, la creazione e la gestione di un'architettura di questo tipo possono creare complessità. L'architettura diventa ancora più complessa quando è necessario il controllo di sicurezza a livello di container (mesh di servizio).

Per semplificare la gestione dei deployment multi-cluster, puoi utilizzare GKE Enterprise per eseguire applicazioni moderne ovunque su larga scala. GKE include componenti open source gestiti efficaci per proteggere i carichi di lavoro, applicare criteri di conformità e fornire osservabilità e risoluzione dei problemi della rete.

Come illustrato nel diagramma seguente, l'utilizzo di GKE Enterprise consente di utilizzare applicazioni multi-cluster come parchi risorse.

Diagramma dello stack che mostra le opportunità di gestione del parco risorse offerte da GKE Enterprise.

GKE Enterprise offre le seguenti opzioni di progettazione per supportare architetture ibride e multi-cloud:

  • Progetta e crea esperienze simili a quelle del cloud, on-premise o unificate, per eseguire la transizione delle applicazioni all'ambiente ibrido GKE Enterprise. Per ulteriori informazioni, consulta l'architettura di riferimento dell'ambiente ibrido di GKE Enterprise.

  • Progetta e crea una soluzione per risolvere le complessità multi-cloud con governance, operazioni e security posture coerenti con GKE Multi-Cloud. Per ulteriori informazioni, consulta la documentazione su GKE Multi-Cloud.

Inoltre, GKE Enterprise fornisce raggruppamenti logici di ambienti simili con coerenza in termini di sicurezza, configurazione e gestione dei servizi. Ad esempio, GKE Enterprise è alla base dell'architettura distribuita Zero Trust. In un'architettura distribuita Zero Trust, i servizi di cui viene eseguito il deployment on-premise o in un altro ambiente cloud possono comunicare tra ambienti tramite comunicazioni end-to-end sicure service-to-service mTLS.

Considerazioni sulla portabilità dei carichi di lavoro

Kubernetes e GKE Enterprise forniscono un livello di astrazione per i carichi di lavoro che può nascondere le molte complessità e differenze tra gli ambienti di computing. Il seguente elenco descrive alcune di queste astrazioni:

  • Un'applicazione potrebbe essere portabile in un ambiente diverso con variazioni minime, ma ciò non significa che l'applicazione funzioni in modo uguale in entrambi gli ambienti.
    • Le differenze a livello di computing, funzionalità di sicurezza dell'infrastruttura o di rete sottostanti, nonché la vicinanza ai servizi dipendenti, possono portare a prestazioni sostanzialmente diverse.
  • Anche lo spostamento di un carico di lavoro tra ambienti di computing può richiedere il trasferimento dei dati.
    • Ambienti diversi possono avere servizi e strutture di archiviazione e gestione diversi.
  • Il comportamento e le prestazioni dei bilanciatori del carico di cui è stato eseguito il provisioning con Kubernetes o GKE Enterprise possono variare da un ambiente all'altro.

Spostamento dei dati

Poiché può essere complesso spostare, condividere e accedere ai dati su larga scala tra ambienti di computing, le aziende di livello aziendale potrebbero esitare a creare un'architettura ibrida o multi-cloud. Questa esitazione potrebbe aumentare se stanno già archiviando la maggior parte dei dati on-premise o in un cloud.

Tuttavia, le varie opzioni di spostamento dei dati offerte da Google Cloud, forniscono alle aziende un set completo di soluzioni per aiutare a spostare, integrare e trasformare i loro dati. Queste opzioni aiutano le aziende ad archiviare, condividere e accedere ai dati in diversi ambienti nel modo che meglio risponde ai loro casi d'uso specifici. Questa capacità, in ultima analisi, semplifica l'adozione di architetture ibride e multi-cloud per i responsabili delle decisioni aziendali e tecnologiche.

Lo spostamento dei dati è un aspetto importante per la pianificazione dell'architettura e delle strategie ibride e multi-cloud. Il tuo team deve identificare i diversi casi d'uso aziendali e i dati alla base. Occorre anche tenere conto del tipo di archiviazione, della capacità, dell'accessibilità e delle opzioni di spostamento.

Se un'azienda dispone di una classificazione dei dati per settori regolamentati, la classificazione può aiutare a identificare località di archiviazione e restrizioni di spostamento dei dati tra regioni per determinate classi di dati. Per maggiori informazioni, consulta Sensitive Data Protection. Sensitive Data Protection è un servizio completamente gestito progettato per aiutarti a scoprire, classificare e proteggere i tuoi asset di dati.

Per esplorare il processo, dalla pianificazione di un trasferimento di dati all'utilizzo delle best practice per l'implementazione di un piano, consulta Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni.

Sicurezza

Man mano che le organizzazioni adottano architetture ibride e multi-cloud, la loro superficie di attacco può aumentare a seconda del modo in cui sistemi e dati sono distribuiti in diversi ambienti. In combinazione con il panorama delle minacce in costante evoluzione, l'aumento delle superfici di attacco può comportare un rischio maggiore di accessi non autorizzati, perdita di dati e altri incidenti di sicurezza. Considera attentamente la sicurezza quando pianifichi e implementi le strategie ibride o multi-cloud.

Per ulteriori informazioni, vedi Attack Surface Management per Google Cloud.

Quando si progetta per un'architettura ibrida, non è sempre tecnicamente fattibile o attuabile estendere al cloud gli approcci alla sicurezza on-premise. Tuttavia, molte delle funzionalità di sicurezza di rete delle appliance hardware sono funzionalità cloud-first e operano in modo distribuito. Per ulteriori informazioni sulle funzionalità di sicurezza di rete cloud-first di Google Cloud, consulta Sicurezza di rete Cloud.

Le architetture ibride e multi-cloud possono introdurre ulteriori problemi di sicurezza, come la coerenza e l'osservabilità. Ogni cloud provider pubblico ha il proprio approccio alla sicurezza, compresi modelli, best practice, funzionalità di sicurezza dell'infrastruttura e delle applicazioni, obblighi di conformità e persino nomi di servizi di sicurezza. Queste incoerenze possono aumentare i rischi per la sicurezza. Inoltre, il modello di responsabilità condivisa di ciascun cloud provider può differire. È essenziale identificare e comprendere l'esatta demarcazione delle responsabilità in un'architettura multi-cloud.

L'osservabilità è fondamentale per ottenere insight e metriche dai diversi ambienti. In un'architettura multi-cloud, ciascun cloud in genere fornisce strumenti per monitorare la postura di sicurezza e le configurazioni errate. Tuttavia, l'utilizzo di questi strumenti si traduce in una visibilità isolata, che impedisce la creazione di intelligence avanzata sulle minacce in tutto l'ambiente. Di conseguenza, il team di sicurezza deve passare da uno strumento all'altro e da una dashboard all'altra per garantire la sicurezza del cloud. Senza una visibilità generale della sicurezza end-to-end per gli ambienti ibridi e multi-cloud, è difficile assegnare le priorità e mitigare le vulnerabilità.

Per ottenere la piena visibilità e la postura di tutti i tuoi ambienti, assegna la priorità alle vulnerabilità e mitiga le vulnerabilità identificate. Consigliamo un modello di visibilità centralizzato. Un modello di visibilità centralizzato evita la necessità di correlazioni manuali tra vari strumenti e dashboard da piattaforme differenti. Per maggiori informazioni, consulta Pattern di monitoraggio e logging ibridi e multi-cloud.

Nell'ambito della tua pianificazione per mitigare i rischi per la sicurezza ed eseguire il deployment dei carichi di lavoro su Google Cloud e per aiutarti a pianificare e progettare la tua soluzione cloud al fine di raggiungere i tuoi obiettivi di sicurezza e conformità, esplora il Centro best practice per la sicurezza di Google Cloud e il progetto delle basi aziendali.

Gli obiettivi di conformità possono variare in quanto sono influenzati sia dalle normative specifiche del settore sia dai diversi requisiti normativi di regioni e paesi diversi. Per ulteriori informazioni, consulta il Centro risorse per la conformità di Google Cloud. Ecco alcuni dei principali approcci consigliati per progettare un'architettura ibrida e multi-cloud sicura:

  • Sviluppa una strategia e un’architettura di sicurezza cloud personalizzate e unificate. Le strategie di sicurezza ibride e multi-cloud devono essere adattate alle esigenze e agli obiettivi specifici della tua organizzazione.

    È essenziale comprendere l'architettura e l'ambiente scelti come target prima di implementare i controlli di sicurezza, poiché ogni ambiente può utilizzare funzionalità, configurazioni e servizi diversi.

  • Valutare un'architettura di sicurezza unificata in ambienti ibridi e multi-cloud.

  • Standardizza la progettazione e i deployment cloud, in particolare la progettazione e le funzionalità di sicurezza. Così facendo puoi migliorare l'efficienza e abilitare governance e strumenti unificati.

  • Utilizza più controlli di sicurezza.

    In genere, nessun singolo controllo di sicurezza può soddisfare in modo adeguato tutti i requisiti di protezione. Pertanto, le organizzazioni devono utilizzare una combinazione di controlli di sicurezza in un approccio a più livelli di difesa, noto anche come difesa in profondità.

  • Monitora e migliora continuamente le misure di sicurezza: la tua organizzazione dovrebbe monitorare i diversi ambienti per rilevare eventuali minacce e vulnerabilità alla sicurezza. Dovrebbe anche cercare di migliorare continuamente la propria strategia di sicurezza.

  • Prendi in considerazione l'utilizzo di Cloud Security posture Management (CSPM) per identificare e correggere gli errori di configurazione della sicurezza e le minacce alla cybersicurezza. CSPM fornisce anche valutazioni di vulnerabilità in ambienti ibridi e multi-cloud.

Security Command Center è una soluzione integrata di sicurezza e gestione dei rischi per Google Cloud che aiuta a identificare errori di configurazione, vulnerabilità e altro ancora. Security Health Analytics è uno strumento gestito di analisi della valutazione delle vulnerabilità. È una funzionalità di Security Command Center che identifica i rischi e le vulnerabilità per la sicurezza nel tuo ambiente Google Cloud e fornisce suggerimenti per risolverli.

Mandiant Attack Surface Management per Google Cloud consente alla tua organizzazione di vedere meglio gli asset del proprio ambiente cloud ibrido o multi-cloud. Rileva automaticamente gli asset di più cloud provider, DNS e della superficie di attacco esterna estesa per consentire alla tua azienda di comprendere più a fondo il suo ecosistema. Utilizza queste informazioni per dare priorità alle correzioni delle vulnerabilità e delle esposizioni che presentano il rischio maggiore.

  • Soluzione SIEM (Security Information and Event Management) su cloud: aiuta a raccogliere e analizzare i log di sicurezza da ambienti ibridi e multi-cloud per rilevare e rispondere alle minacce. Google Security Operations SIEM di Google Cloud consente di fornire informazioni sulla sicurezza e gestione degli eventi raccogliendo, analizzando, rilevando e analizzando tutti i dati di sicurezza in un'unica posizione.

Crea architetture ibride e multi-cloud utilizzando Google Cloud: novità