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.
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:
- Supportare Container Runtime Interface (CRI) di Kubernetes
- Vengono adottati dal settore per la candidatura
- Non sono legati a fornitori specifici
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.
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.