Questo documento evidenzia le considerazioni di progettazione principali che svolgono un ruolo fondamentale nella definizione dell'architettura ibrida e multicloud complessiva. Analizza e valuta in modo olistico queste considerazioni nell'intera architettura della soluzione, comprendendo tutti i carichi di lavoro, non solo quelli specifici.
Refactor
In una migrazione di refactoring, modifichi i tuoi carichi di lavoro per sfruttare le funzionalità del cloud, non solo per farli funzionare nel nuovo ambiente. Puoi migliorare ogni workload in termini di prestazioni, funzionalità, costi ed esperienza utente. Come evidenziato in Refactoring: 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, soprattutto se il tuo obiettivo è creare un'architettura ibrida come architettura di destinazione a lungo termine:
- Puoi migliorare il processo di deployment.
- Puoi contribuire ad accelerare la cadenza delle release e a ridurre i cicli di feedback investendo in strumenti e infrastrutture 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 bene, questo approccio in genere richiede determinati investimenti in infrastrutture e strumenti on-premise. Ad esempio, la configurazione di un Container Registry locale e il provisioning dei cluster Kubernetes per containerizzare le applicazioni. La versione GKE Enterprise può essere utile in questo approccio per gli ambienti ibridi. Ulteriori informazioni su GKE Enterprise sono disponibili 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 multicloud, potresti voler spostare i carichi di lavoro tra gli ambienti di computing che ospitano i tuoi dati. Per facilitare lo spostamento senza interruzioni dei carichi di lavoro tra gli ambienti, 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 possibilità di rendere un workload portatile non deve essere in conflitto con il fatto che il workload sia cloud-first.
Automazione dell'infrastruttura
L'automazione dell'infrastruttura è essenziale per la portabilità nelle architetture ibride e multi-cloud. Un approccio comune per automatizzare la creazione dell'infrastruttura è tramite Infrastructure as Code (IaC). IaC prevede la gestione dell'infrastruttura nei 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 popolare per definire le risorse dell'infrastruttura in un file. Terraform consente anche 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 Blueprint e moduli Terraform per Google Cloud.
Puoi utilizzare strumenti di gestione della configurazione come Ansible, Puppet, o Chef per stabilire un processo 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 in tutti gli ambienti.
In base a questi strumenti, puoi assemblare una toolchain comune come illustrato nel seguente diagramma logico. Questa catena di strumenti comune astrae le differenze tra gli ambienti di computing. Consente inoltre 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 svantaggi:
- L'utilizzo delle VM come base comune può rendere difficile l'implementazione di vere applicazioni cloud-first. Inoltre, l'utilizzo delle sole VM può impedirti di utilizzare i servizi gestiti dal cloud. Potresti perdere opportunità per ridurre l'overhead amministrativo.
- La creazione e la manutenzione di una catena di strumenti comuni comporta costi generali e operativi.
- 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 addestramento.
Prima di decidere di sviluppare strumenti e automazione, esplora i servizi gestiti offerti dal tuo fornitore di servizi cloud. Quando il tuo provider offre servizi gestiti che supportano lo stesso caso d'uso, puoi astrarre parte della sua complessità. In questo modo puoi concentrarti sul carico di lavoro e sull'architettura dell'applicazione anziché sull'infrastruttura sottostante.
Ad esempio, puoi utilizzare il modello di risorse Kubernetes per automatizzare la creazione di cluster Kubernetes utilizzando un approccio di configurazione dichiarativa. 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 Kubernetes Resource Model) in modo che siano portatili quando li pubblichi.
Puoi anche valutare l'automatizzazione 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 dei progetti.
Container e Kubernetes
L'utilizzo di funzionalità gestite dal cloud contribuisce a ridurre la complessità della creazione e della manutenzione di una toolchain personalizzata per ottenere l'automazione e la portabilità dei carichi di lavoro. Tuttavia, l'utilizzo delle sole VM come base comune rende difficile l'implementazione di applicazioni veramente cloud-first. Una soluzione è utilizzare i container e Kubernetes.
I container aiutano il software a essere eseguito in modo affidabile quando lo sposti da un ambiente all'altro. Poiché i container separano le applicazioni dall'infrastruttura host sottostante, facilitano il deployment in ambienti di computing, come quelli ibridi e multi-cloud.
Kubernetes gestisce l'orchestrazione, il deployment, lo scaling e la gestione delle 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 in 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 API in un ambiente di cloud o di computing privato. Inoltre, il livello di astrazione è molto più alto rispetto a quando si lavora con le VM, il che in genere si traduce in un lavoro preparatorio meno impegnativo e in una maggiore produttività degli sviluppatori.
- A differenza di una toolchain personalizzata, Kubernetes è ampiamente adottato sia per lo sviluppo che per la gestione delle applicazioni, quindi puoi sfruttare competenze, documentazione e supporto di terze parti esistenti.
- Kubernetes supporta tutte le implementazioni di container che:
- Supporta l'interfaccia Container Runtime Interface (CRI) di Kubernetes
- Sono adottati dal settore per l'applicazione
- Non sono vincolati a un fornitore specifico
Quando un workload è in esecuzione su Google Cloud, puoi evitare lo sforzo di installare e utilizzare Kubernetes utilizzando una piattaforma Kubernetes gestita come Google Kubernetes Engine (GKE). In questo modo, il personale operativo può spostare la propria attenzione 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, considera i tuoi requisiti di scalabilità e i relativi limiti di scalabilità.
Tecnicamente, puoi installare ed eseguire Kubernetes in molti ambienti di computing per stabilire un livello di runtime comune. Tuttavia, in pratica, la creazione e la gestione di un'architettura di questo tipo possono creare complessità. L'architettura diventa ancora più complessa quando richiedi il controllo della sicurezza a livello di container (service mesh).
Per semplificare la gestione dei deployment multi-cluster, puoi utilizzare GKE Enterprise per eseguire applicazioni moderne ovunque su larga scala. GKE include potenti componenti open source gestiti per proteggere i carichi di lavoro, applicare criteri di conformità e fornire osservabilità e risoluzione dei problemi di rete approfondite.
Come illustrato nel seguente diagramma, l'utilizzo di GKE Enterprise ti consente di gestire 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 al cloud on-premise o soluzioni unificate per la transizione delle applicazioni all'ambiente ibrido GKE Enterprise. Per maggiori informazioni, consulta l'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 anche raggruppamenti logici di ambienti simili con gestione coerente di sicurezza, configurazione e servizi. Ad esempio, GKE Enterprise supporta un'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 gli ambienti tramite comunicazioni service-to-service sicure mTLS end-to-end.
Considerazioni sulla portabilità del workload
Kubernetes e GKE Enterprise forniscono un livello di astrazione per i carichi di lavoro che può nascondere le numerose complessità e differenze tra gli ambienti di computing. L'elenco seguente descrive alcune di queste astrazioni:
- Un'applicazione potrebbe essere trasferibile a un ambiente diverso con
modifiche minime, ma ciò non significa che le prestazioni dell'applicazione
siano ugualmente buone in entrambi gli ambienti.
- Differenze nel calcolo sottostante, nelle funzionalità di sicurezza dell'infrastruttura o nell'infrastruttura di rete, nonché la vicinanza ai servizi dipendenti, potrebbero comportare prestazioni sostanzialmente diverse.
- Lo spostamento di un workload tra ambienti di computing potrebbe richiedere anche lo spostamento dei dati.
- Ambienti diversi possono avere servizi e strutture di archiviazione e gestione dei dati diversi.
- Il comportamento e il rendimento dei bilanciatori del carico di cui è stato eseguito il provisioning con Kubernetes o GKE Enterprise potrebbero variare a seconda dell'ambiente.
Spostamento dei dati
Poiché lo spostamento, la condivisione e l'accesso ai dati su larga scala tra ambienti di computing possono essere complessi, le aziende di livello enterprise potrebbero esitare a creare un'architettura ibrida o multicloud. Questa esitazione potrebbe aumentare se già archiviano la maggior parte dei loro 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 aiutano le aziende ad archiviare, condividere e accedere ai dati in diversi ambienti in un modo che soddisfi i loro casi d'uso specifici. Questa capacità, in definitiva, semplifica l'adozione di architetture ibride e multi-cloud per i responsabili delle decisioni aziendali e tecnologiche.
Lo spostamento dei dati è un aspetto importante da considerare per la strategia ibrida e multi-cloud e la pianificazione dell'architettura. Il tuo team deve identificare i diversi casi d'uso della tua attività e i dati che li alimentano. Devi anche pensare al tipo di spazio di archiviazione, alla capacità, all'accessibilità e alle opzioni di movimento.
Se un'azienda ha una classificazione dei dati per i settori regolamentati, questa classificazione può aiutare a identificare le posizioni di archiviazione e le limitazioni al trasferimento dei dati tra regioni per determinate classi di dati. Per ulteriori informazioni, consulta Sensitive Data Protection. Protezione dei dati sensibili è 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 dati all'utilizzo delle best practice durante l'implementazione di un piano, consulta Migrazione verso Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni.
Sicurezza
Man mano che le organizzazioni adottano architetture ibride e multicloud, la loro superficie di attacco può aumentare a seconda della modalità di distribuzione dei sistemi e dei dati in ambienti diversi. In combinazione con il panorama delle minacce in continua evoluzione, l'aumento delle superfici di attacco può portare a 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 fattibile o praticabile estendere al cloud gli approcci di sicurezza on-premise. Tuttavia, molte delle funzionalità di sicurezza di rete degli appliance hardware sono funzionalità cloud-first e funzionano in modo distribuito. Per saperne di più sulle funzionalità di sicurezza di 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 fornitore di cloud pubblico ha il proprio approccio alla sicurezza, inclusi modelli, best practice, funzionalità di sicurezza di infrastruttura e applicazioni, obblighi di conformità e persino i nomi dei servizi di sicurezza. Queste incongruenze possono aumentare il rischio per la sicurezza. Inoltre, il modello di responsabilità condivisa di ogni provider cloud può variare. È essenziale identificare e comprendere la demarcazione esatta delle responsabilità in un'architettura multicloud.
L'osservabilità è fondamentale per ottenere insight e metriche dai diversi ambienti. In un'architettura multicloud, ogni cloud in genere fornisce strumenti per monitorare la postura di sicurezza e le configurazioni errate. Tuttavia, l'utilizzo di questi strumenti comporta una visibilità isolata, che impedisce la creazione di informazioni avanzate sulle minacce nell'intero ambiente. Di conseguenza, il team di sicurezza deve passare da uno strumento all'altro e da un dashboard all'altro per mantenere il cloud sicuro. Senza una visibilità end-to-end della sicurezza per gli ambienti ibridi e multi-cloud, è difficile dare la priorità alle vulnerabilità e mitigarle.
Per ottenere la visibilità e la postura complete 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 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 Cloude per aiutarti a pianificare e progettare la tua soluzione cloud per raggiungere i tuoi obiettivi di sicurezza e conformità, esplora il Google Cloud centro per le best practice di sicurezza e il progetto base per la sicurezza.
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 saperne di più, consulta il Google Cloud Centro risorse per la conformità. Di seguito sono riportati alcuni degli approcci principali consigliati per la progettazione di un'architettura ibrida e multi-cloud sicura:
Sviluppa una strategia e un'architettura di sicurezza cloud unificate e personalizzate. Le strategie di sicurezza ibride e multicloud devono essere adattate alle esigenze e agli obiettivi specifici della tua organizzazione.
È essenziale comprendere l'architettura e l'ambiente di destinazione prima di implementare i controlli di sicurezza, perché ogni ambiente può utilizzare funzionalità, configurazioni e servizi diversi.
Prendi in considerazione un'architettura di sicurezza unificata negli ambienti ibridi e multi-cloud.
Standardizzare la progettazione e i deployment cloud, in particolare la progettazione e le funzionalità di sicurezza. In questo modo è possibile migliorare l'efficienza e attivare la governance e gli 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. Inoltre, dovrebbe cercare di migliorare continuamente la propria strategia di sicurezza.
Valuta la possibilità di utilizzare la gestione della postura di sicurezza nel cloud (CSPM) per identificare e correggere errori di configurazione della sicurezza e minacce informatiche. CSPM fornisce anche valutazioni delle vulnerabilità in ambienti ibridi e multi-cloud.
Security Command Center è una soluzione integrata di sicurezza e gestione dei rischi per Google Cloudche aiuta a identificare configurazioni errate, vulnerabilità e altro ancora. Security Health Analytics è uno strumento di scansione gestito per la valutazione delle vulnerabilità. 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 la loro correzione.
Mandiant Attack Surface Management per Google Cloud consente alla tua organizzazione di visualizzare meglio gli asset dell'ambiente multi-cloud o cloud ibrido. Rileva automaticamente gli asset di più provider cloud, DNS e la superficie di attacco esterna estesa per fornire alla tua azienda una comprensione più approfondita del suo ecosistema. Utilizza queste informazioni per dare la priorità alla correzione delle vulnerabilità e delle esposizioni che presentano il rischio maggiore.
- Soluzione di gestione degli eventi e delle informazioni di sicurezza (SIEM) nel 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 consente di fornire la gestione degli eventi e delle informazioni di sicurezza raccogliendo, analizzando, rilevando e analizzando tutti i dati di sicurezza in un unico posto.