Questo documento mette in evidenza le considerazioni di progettazione di base che svolgono un ruolo fondamentale nella definizione dell'architettura ibrida e multi-cloud complessiva. Analizza e valuta in modo olistico queste considerazioni nell'intera architettura della soluzione, includendo tutti i carichi di lavoro, non solo quelli specifici.
Refactor
In una migrazione di refactoring, modifichi 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 Refactor: sposta e migliora, alcuni scenari di refactoring ti 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 mirata a lungo termine:
- Puoi migliorare il processo di implementazione.
- Puoi contribuire ad accelerare la cadenza delle release e abbreviare i cicli di feedback investendo in infrastrutture e strumenti di integrazione/deployment continui (CI/CD).
- Puoi utilizzare il refactoring come base per creare e gestire un'architettura ibrida con la portabilità delle applicazioni.
Per funzionare bene, questo approccio in genere richiede determinati investimenti in infrastrutture e strumenti on-premise. Ad esempio, configurare un Container Registry locale ed eseguire il provisioning di cluster Kubernetes per containerizzare le applicazioni. La versione Enterprise di Google Kubernetes Engine (GKE) può essere utile in questo approccio per gli ambienti ibridi. Ulteriori informazioni su GKE Enterprise sono riportate nella sezione seguente. Per ulteriori dettagli, puoi anche consultare l'architettura di riferimento dell'ambiente ibrido GKE Enterprise.
Portabilità del carico di lavoro
Con le architetture ibride e multi-cloud, potresti voler spostare i carichi di lavoro tra gli ambienti di calcolo che ospitano i tuoi dati. Per contribuire a abilitare il trasferimento senza problemi dei carichi di lavoro tra gli ambienti, prendi in considerazione i seguenti fattori:
- Puoi spostare un'applicazione da un ambiente di calcolo all'altro
senza modificarla in modo significativo e il relativo modello operativo:
- Il deployment e la gestione delle applicazioni sono coerenti tra gli ambienti di calcolo.
- Visibilità, configurazione e sicurezza sono coerenti tra gli ambienti di calcolo.
- La possibilità di rendere un carico di lavoro portabile non deve essere in conflitto con il fatto che il carico di lavoro sia cloud-first.
Automazione dell'infrastruttura
L'automazione dell'infrastruttura è essenziale per la portabilità nelle architetture ibridhe e multi-cloud. Un approccio comune per automatizzare la creazione dell'infrastruttura è tramite Infrastructure as Code (IaC). L'IaC prevede la gestione dell'infrastruttura in file anziché la configurazione manuale delle risorse, come una VM, un gruppo di sicurezza o un bilanciatore del carico, in un'interfaccia utente. Terraform è uno strumento IaC molto utilizzato per definire le risorse di infrastruttura in un file. Terraform consente inoltre di automatizzare la creazione di queste risorse in ambienti eterogenei.
Per ulteriori informazioni sulle funzioni di base di Terraform che possono aiutarti a automatizzare il provisioning e la gestione Google Cloud delle risorse, consulta Modelli e moduli Terraform per Google Cloud.
Puoi utilizzare strumenti di gestione della configurazione come Ansible, Puppet o Chef per stabilire una procedura di deployment e configurazione comune. In alternativa, puoi utilizzare uno strumento di creazione di immagini come Packer per creare immagini VM per piattaforme diverse. Utilizzando un unico 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 gli ambienti.
In base a questi strumenti, puoi assemblare una catena di strumenti comune come illustrato nel seguente diagramma logico. Questa catena di strumenti comuni rimuove le differenze tra gli ambienti di calcolo. Inoltre, ti consente di unificare il provisioning, il deployment, la gestione e il monitoraggio.
Sebbene una catena di strumenti comune possa aiutarti a ottenere la portabilità, è soggetta a diversi dei seguenti inconvenienti:
- L'utilizzo delle VM come base comune può rendere difficile l'implementazione di applicazioni cloud-first. Inoltre, l'utilizzo esclusivo di VM può impedirti di utilizzare i servizi gestiti nel cloud. Potresti perdere opportunità per ridurre il carico amministrativo.
- La creazione e la gestione di una catena di strumenti comuni comportano costi operativi e di overhead.
- Man mano che la catena di strumenti si espande, può sviluppare complessità uniche personalizzate in base alle 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 provider cloud. Quando il tuo provider offre servizi gestiti che supportano lo stesso caso d'uso, puoi rimuoverne parte della complessità. In questo modo, puoi concentrarti sul carico di lavoro e sull'architettura dell'applicazione anziché sull'infrastruttura di base.
Ad esempio, puoi utilizzare il modello di risorse Kubernetes per automatizzare la creazione di cluster Kubernetes utilizzando un approccio di configurazione declarative. Puoi utilizzare Deployment Manager convert per convertire le configurazioni e i modelli di Deployment Manager in altri formati di configurazione dichiarativa supportati da Google Cloud (come Terraform e il modello di risorse Kubernetes) in modo che siano portabili al momento della pubblicazione.
Puoi anche valutare la possibilità di automatizzare la creazione dei progetti e delle risorse al loro interno. Questa automazione può aiutarti ad adottare un approccio Infrastructure as Code per il provisioning dei progetti.
Container e Kubernetes
L'utilizzo delle funzionalità gestite dal cloud consente di ridurre la complessità di creazione e gestione di una catena di strumenti personalizzata per ottenere l'automazione e la portabilità dei carichi di lavoro. Tuttavia, l'utilizzo esclusivo delle VM come base comune rende difficile implementare applicazioni veramente cloud-first. Una soluzione è utilizzare i container e Kubernetes.
I container consentono al software di funzionare in modo affidabile quando lo sposti da un ambiente all'altro. Poiché i container separano le applicazioni dall'infrastruttura dell'host sottostante, facilitano il deployment in ambienti di calcolo, come ibridi e multi-cloud.
Kubernetes gestisce l'orchestrazione, il deployment, la scalabilità e la gestione delle tue applicazioni containerizzate. È open source e regolato dalla Cloud Native Computing Foundation. L'utilizzo di Kubernetes fornisce i servizi che costituiscono la base di un'applicazione cloud-first. Poiché puoi installare ed eseguire Kubernetes su molti ambienti di calcolo, puoi utilizzarlo anche per stabilire un livello di runtime comune in tutti gli ambienti di calcolo:
- Kubernetes fornisce gli stessi servizi e API in un ambiente di calcolo privato o cloud. Inoltre, il livello di astrazione è molto più elevato rispetto al lavoro con le VM, il che in genere si traduce in una preparazione meno impegnativa e in una maggiore produttività degli sviluppatori.
- A differenza di una catena di strumenti personalizzata, Kubernetes è ampiamente adottato sia per lo sviluppo sia per la gestione delle applicazioni, quindi puoi sfruttare le competenze, la documentazione e l'assistenza di terze parti esistenti.
- Kubernetes supporta tutte le implementazioni dei container che:
- Supporta l'interfaccia Container Runtime (CRI) di Kubernetes
- Sono adottate dal settore per l'applicazione
- Non sono legati a un fornitore specifico
Quando un carico di lavoro è in esecuzione su Google Cloud, puoi evitare la fatica di installare e utilizzare Kubernetes utilizzando una piattaforma Kubernetes gestita come Google Kubernetes Engine (GKE). In questo modo, il personale addetto alle operazioni può spostare il proprio focus dalla creazione e dalla manutenzione dell'infrastruttura alla creazione e alla manutenzione 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, tieni conto dei tuoi requisiti di scalabilità e dei relativi limiti di scalabilità.
Tecnicamente, puoi installare ed eseguire Kubernetes su molti ambienti di calcolo per stabilire un livello di runtime comune. Tuttavia, in pratica, la creazione e il funzionamento di un'architettura di questo tipo possono creare complessità. L'architettura diventa ancora più complessa quando è necessario un controllo della sicurezza a livello di contenitore (mesh di servizi).
Per semplificare la gestione dei deployment multi-cluster, puoi utilizzare GKE Enterprise per eseguire applicazioni moderne ovunque e su larga scala. GKE include potenti componenti open source gestiti per proteggere i carichi di lavoro, applicare i criteri di conformità e fornire un'ampia osservabilità e risoluzione dei problemi della rete.
Come illustrato nel seguente diagramma, l'utilizzo di GKE Enterprise consente di gestire le applicazioni multi-cluster come parchi risorse.
GKE Enterprise offre le seguenti opzioni di progettazione per supportare le architetture ibride e multi-cloud:
Progetta e crea esperienze cloud-like on-premise o soluzioni unificate per la transizione delle applicazioni all'ambiente ibrido GKE Enterprise. Per ulteriori informazioni, consulta la architettura di riferimento dell'ambiente ibrido GKE Enterprise.
Progetta e crea una soluzione per risolvere la complessità multicloud con una strategia coerente per governance, operazioni e sicurezza con GKE Multi-Cloud. Per saperne di più, consulta la documentazione di GKE Multi-Cloud.
GKE Enterprise fornisce inoltre raggruppamenti logici di ambienti simili con sicurezza, configurazione e gestione dei servizi coerenti. Ad esempio, GKE Enterprise supporta l'architettura distribuita zero trust. In un'architettura distribuita zero trust, i servizi di cui è stato eseguito il deployment on-premise o in un altro ambiente cloud possono comunicare tra ambienti tramite comunicazioni service-to-service sicure mTLS end-to-end.
Considerazioni sulla portabilità del carico 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 calcolo. L'elenco seguente descrive alcune di queste astrazioni:
- Un'applicazione potrebbe essere portabile in un ambiente diverso con modifiche minime, ma ciò non significa che funzioni ugualmente bene in entrambi gli ambienti.
- Le differenze nelle funzionalità di sicurezza dell'infrastruttura o di calcolo di base o nell'infrastruttura di rete, insieme alla vicinanza ai servizi dipendenti, potrebbero portare a prestazioni notevolmente diverse.
- Lo spostamento di un carico di lavoro tra ambienti di calcolo potrebbe anche richiedere di spostare i dati.
- Ambienti diversi possono avere servizi e strutture di archiviazione e gestione dei dati diversi.
- Il comportamento e le prestazioni dei bilanciatori del carico di cui è stato eseguito il provisioning con Kubernetes o GKE Enterprise potrebbero 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 calcolo, le aziende di livello enterprise potrebbero esitare a creare un'architettura ibrida o multi-cloud. Questa esitazione potrebbe aumentare se già archiviano la maggior parte dei dati on-premise o in un cloud.
Tuttavia, le varie opzioni di spostamento dei dati offerte da Google Cloudforniscono alle aziende un insieme completo di soluzioni per spostare, integrare e trasformare i dati. Queste opzioni consentono alle imprese di archiviare, condividere e accedere ai dati in ambienti diversi in modo da soddisfare i loro casi d'uso specifici. Questa capacità semplifica in definitiva la possibilità per i responsabili delle decisioni aziendali e tecnologiche di adottare architetture ibride e multicloud.
Il movimento dei dati è un aspetto importante per la strategia ibrida e multi-cloud e per la pianificazione dell'architettura. Il tuo team deve identificare i diversi casi d'uso della tua attività e i dati che li supportano. Devi anche considerare il tipo di archiviazione, la capacità, l'accessibilità e le opzioni di movimento.
Se un'azienda dispone di una classificazione dei dati per settori regolamentati, questa classificazione può essere utile per identificare le posizioni di archiviazione e le limitazioni di trasferimento dei dati tra regioni per determinate classi di dati. Per ulteriori 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 esaminare la procedura, dalla pianificazione di un trasferimento dati all'utilizzo delle best practice durante l'implementazione di un piano, consulta Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni.
Sicurezza
Quando le organizzazioni adottano architetture ibride e multi-cloud, la loro superficie di attacco può aumentare a seconda del modo in cui i sistemi e i dati sono distribuiti in ambienti diversi. Se combinato con il panorama delle minacce in continua evoluzione, l'aumento delle superfici di attacco può comportare un maggiore rischio di accesso non autorizzato, perdita di dati e altri incidenti di sicurezza. Valuta attentamente la sicurezza quando pianifichi e implementi strategie ibride o multi-cloud.
Per saperne di più, consulta Attack Surface Management per Google Cloud.
Quando si progetta un'architettura ibrida, non è sempre tecnicamente possibile o fattibile estendere gli approcci di sicurezza on-premise al cloud. 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 della rete cloud-first di Google Cloud, consulta Sicurezza della rete cloud.
Le architetture ibride e multi-cloud possono introdurre ulteriori sfide di sicurezza, come coerenza e osservabilità. Ogni provider di cloud pubblico ha il proprio approccio alla sicurezza, inclusi modelli diversi, best practice, funzionalità di sicurezza dell'infrastruttura e delle applicazioni, obblighi di conformità e persino i nomi dei servizi di sicurezza. Queste incoerenze possono aumentare il rischio per la sicurezza. Inoltre, il modello di responsabilità condivisa di ciascun provider cloud può essere diverso. È essenziale identificare e comprendere la delimitazione esatta delle responsabilità in un'architettura multicloud.
L'osservabilità è fondamentale per ottenere approfondimenti e metriche dai diversi ambienti. In un'architettura multicloud, ogni cloud in genere fornisce strumenti per monitorare la strategia di sicurezza e le configurazioni errate. Tuttavia, l'utilizzo di questi strumenti comporta una visibilità silos, che impedisce di creare informazioni sulle minacce avanzate nell'intero ambiente. Di conseguenza, il team di sicurezza deve passare da uno strumento all'altro e da una dashboard all'altra per mantenere il cloud al sicuro. Senza una visibilità complessiva della sicurezza end-to-end per gli ambienti ibridi e multi-cloud, è difficile dare la priorità alle vulnerabilità e attenuarle.
Per ottenere la visibilità e la postura completa di tutti i tuoi ambienti, dai la priorità alle vulnerabilità e mitiga quelle che identifichi. Ti consigliamo un modello di visibilità centralizzato. Un modello di visibilità centralizzato evita la necessità di correlazione manuale tra diversi strumenti e dashboard di piattaforme diverse. Per maggiori informazioni, consulta la sezione Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.
Nell'ambito della pianificazione per mitigare i rischi per la sicurezza ed eseguire il deployment dei carichi di lavoro su Google Cloud, nonché per aiutarti a pianificare e progettare la tua soluzione cloud per raggiungere i tuoi obiettivi di sicurezza e conformità, esplora il Google Cloud Security Best Practice Center e il Enterprise Foundations Blueprint.
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, visita il Google Cloud Centro risorse per la conformità. Di seguito sono riportati alcuni dei principali approcci consigliati per progettare un'architettura ibrida e multi-cloud sicura:
Sviluppare una strategia e un'architettura di sicurezza cloud unificate e personalizzate. Le strategie di sicurezza ibride e multicloud devono essere personalizzate in base alle esigenze e agli scopi specifici della tua organizzazione.
È essenziale comprendere l'architettura e l'ambiente scelti come target prima di implementare i controlli di sicurezza, perché ogni ambiente può utilizzare funzionalità, configurazioni e servizi diversi.
Valuta la possibilità di adottare un'architettura di sicurezza unificata negli ambienti ibridi e multi-cloud.
Standardizzare la progettazione e i deployment del cloud, in particolare la progettazione e le funzionalità di sicurezza. In questo modo, puoi migliorare l'efficienza e consentire una governance e strumenti unificati.
Utilizza più controlli di sicurezza.
In genere, nessun singolo controllo di sicurezza può soddisfare adeguatamente tutti i requisiti di protezione della sicurezza. Pertanto, le organizzazioni devono utilizzare una combinazione di controlli di sicurezza in un approccio di difesa a più livelli, noto anche come difesa in profondità.
Monitora e migliora continuamente le posture di sicurezza: la tua organizzazione deve monitorare i diversi ambienti per rilevare minacce e vulnerabilità alla sicurezza. Dovrebbe anche cercare di migliorare continuamente la propria strategia di sicurezza.
Valuta la possibilità di utilizzare la gestione della strategia di sicurezza del cloud (CSPM) per identificare e rimediare a errori di configurazione della sicurezza e minacce alla cybersicurezza. La CSPM fornisce inoltre valutazioni delle 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 e vulnerabilità e altro ancora. Security Health Analytics è uno strumento di scansione per la valutazione delle vulnerabilità gestita. Si tratta di una funzionalità di Security Command Center che identifica i rischi e le vulnerabilità per la sicurezza nel tuo ambienteGoogle Cloud e fornisce consigli per risolverli.
Mandiant Attack Surface Management per Google Cloud consente alla tua organizzazione di vedere meglio le risorse del proprio ambiente cloud ibrido o multi-cloud. Rileva automaticamente gli asset di diversi fornitori di servizi cloud, DNS e della superficie di attacco esterna estesa per offrire alla tua azienda una comprensione più approfondita del proprio ecosistema. Utilizza queste informazioni per dare la priorità alla correzione delle vulnerabilità e delle esposizioni che presentano il rischio maggiore.
- Soluzione SIEM (Security Information and Event Management) cloud: consente di raccogliere e analizzare i log di sicurezza da ambienti ibridi e multicloud per rilevare e rispondere alle minacce. Google Security Operations SIEM di Google Cloud ti aiuta a fornire gestione degli eventi e delle informazioni di sicurezza raccogliendo, analizzando, rilevando ed esaminando tutti i tuoi dati di sicurezza in un unico posto.