Altre considerazioni

Last reviewed 2023-12-14 UTC

Questo documento mette in evidenza le principali considerazioni sulla progettazione che un ruolo fondamentale nel plasmare l'architettura ibrida e multi-cloud complessiva. Analizza e valuta queste considerazioni in modo olistico nell'intera soluzione che comprende 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 per 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 accelerare la cadenza di pubblicazione e ridurre cicli di feedback investendo nell'integrazione e nel deployment continuo infrastruttura e strumenti (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 richiede in genere determinati investimenti in l'infrastruttura e gli 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. Puoi anche fare riferimento alle GKE Enterprise ibrido architettura di riferimento dell'ambiente per ulteriori dettagli.

Portabilità del carico di lavoro

Con le architetture ibride e multi-cloud, potresti voler essere in grado tra gli ambienti di elaborazione che ospitano i tuoi dati. Per contribuire all'attivazione lo spostamento continuo dei carichi di lavoro tra gli ambienti, considera quanto segue 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 ambienti di computing.
  • La capacità di rendere portabile un carico di lavoro non deve essere in conflitto con cloud-first per il tuo carico di lavoro.

Automazione dell'infrastruttura

L'automazione dell'infrastruttura è essenziale per la portabilità negli ambienti ibridi e multi-cloud architetture. 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 è 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 automatizzare il provisioning e la gestione delle risorse Google Cloud, Progetti e moduli di Terraform per Google Cloud.

Puoi usare strumenti di gestione delle configurazioni Ansible Puppet o Cuoco per stabilire un processo comune di deployment e configurazione. 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 comune elimina le differenze tra gli ambienti di elaborazione. Inoltre, ti consente di unificare il provisioning, il deployment, la gestione e il monitoraggio.

Una catena di strumenti consente la portabilità delle applicazioni.

Sebbene una catena di strumenti comune possa aiutare a raggiungere la portabilità, è soggetta alle diverse delle seguenti carenze:

  • 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 dal cloud. Potresti perdere opportunità per ridurre il carico amministrativo.
  • La creazione e la gestione di una catena di strumenti comune comporta overhead e costi 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ò contribuiscono all'aumento dei costi della 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 eliminare 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 Modello di risorse Kubernetes per automatizzare la creazione di cluster Kubernetes utilizzando un modello alla configurazione iniziale. 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 automatizzare la creazione dei progetti e delle risorse al loro interno. Questa automazione può aiutarti ad adottare un approccio Infrastructure as Code per eseguire 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 container e Kubernetes .

I container consentono al software di funzionare in modo affidabile quando lo sposti da un ambiente all'altro. Poiché i container disaccoppiano le applicazioni all'infrastruttura host sottostante, facilitano il deployment nei sistemi ad esempio ambienti 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. Kubernetes fornisce i servizi che costituiscono la base di un ambiente cloud-first un'applicazione. 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 le stesse API, in un ambiente cloud o privato nell'ambiente di computing. 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 di container che:

Quando un carico di lavoro è in esecuzione su Google Cloud, puoi evitare lo sforzo di l'installazione e il funzionamento di Kubernetes tramite una piattaforma Kubernetes gestita, come Google Kubernetes Engine (GKE). In questo modo è possibile aiutare il personale operativo dalla creazione e gestione dell'infrastruttura alla creazione e alla gestione delle applicazioni.

Puoi anche utilizzare Autopilot, una modalità operativa GKE che gestisce il tuo cluster configurazione, inclusi nodi, scalabilità, sicurezza e altre impostazioni. Quando utilizzi GKE Autopilot, considera dei requisiti di scalabilità e le relative limiti di scalabilità.

Tecnicamente, puoi installare ed eseguire Kubernetes su molti ambienti di calcolo per stabilire un livello di runtime comune. In pratica, però, la creazione e la gestire una simile architettura può creare complessità. L'architettura diventa ancora più più complessa quando occorre il controllo di sicurezza a livello di container (servizio 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 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.

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

GKE Enterprise aiuta con le seguenti opzioni di progettazione di supportare architetture ibride e multi-cloud:

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

  • Progetta e crea una soluzione per risolvere la complessità del multicloud con una strategia coerente per governance, operazioni e sicurezza con GKE Multi-Cloud. Per ulteriori informazioni, consulta GKE multi-cloud documentazione.

GKE Enterprise fornisce inoltre raggruppamenti logici ambienti con una sicurezza, una configurazione e una gestione dei servizi coerenti. Ad esempio, GKE Enterprise supporta 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à dei carichi di lavoro

Kubernetes e GKE Enterprise forniscono un livello di astrazione carichi di lavoro in grado di nascondere le complessità e le differenze tra computing ambienti cloud-native. 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.
    • Differenze nelle funzionalità di computing di base e nella sicurezza dell'infrastruttura funzionalità o infrastruttura di rete, oltre alla vicinanza che dipendono da servizio, possono portare a prestazioni sostanzialmente diverse.
  • Anche lo spostamento di un carico di lavoro tra ambienti di computing potrebbe richiedere per spostare i dati.
    • Ambienti diversi possono avere archiviazione dei dati differenti e le strutture per la gestione.
  • 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 multicloud. L'esitazione potrebbe aumentare se già archiviano la maggior parte dei dati on-premise o in un solo cloud.

Tuttavia, i vari opzioni di spostamento dei dati offerti da Google Cloud, forniscono alle aziende una serie completa soluzioni per lo spostamento, l'integrazione e la trasformazione dei 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 la per i responsabili delle decisioni aziendali e tecnologiche di adottare ambienti ibridi e multi-cloud architetture.

Lo spostamento dei dati è una considerazione importante per la strategia ibrida e multi-cloud e alla pianificazione dell'architettura. Il tuo team deve identificare i diversi casi d'uso della tua attività e i dati che li supportano. Dovresti anche pensare allo spazio di archiviazione tipo, capacità, accessibilità e 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, vedi 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 verso 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. Combinata con una minaccia in costante evoluzione un aumento delle superfici di attacco può comportare un aumento del rischio accessi non autorizzati, perdita di dati e altri incidenti di sicurezza. Valuta attentamente sicurezza durante la pianificazione e l'implementazione di 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 per estendere al cloud gli approcci alla sicurezza on-premise. Tuttavia, molte delle funzionalità di sicurezza della rete sono funzionalità cloud-first e operano in un ambiente in modo adeguato. Per ulteriori informazioni sulle funzionalità di sicurezza di rete cloud-first di Google Cloud, vedi Sicurezza della rete cloud.

Le architetture ibride e multi-cloud possono introdurre maggiore sicurezza come la coerenza e l'osservabilità. Tutti i cloud provider pubblici adotta un approccio alla sicurezza basato su diversi modelli, best practice funzionalità di sicurezza dell'infrastruttura e delle applicazioni, gli obblighi di conformità e persino i nomi dei servizi di sicurezza. Queste incoerenze possono aumentare rischio per la sicurezza. Inoltre, modello di responsabilità condivisa di ciascun provider cloud possono differire. È 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'uso di questi strumenti comporta evitando di creare informazioni avanzate sulle minacce in tutta l'azienda completamente gestito di Google Cloud. Di conseguenza, il team di sicurezza deve passare da uno strumento all'altro per proteggere il cloud. 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à centralizzata evita la necessità di usare e la correlazione tra vari strumenti e dashboard di piattaforme diverse. Per ulteriori informazioni, vedi Pattern di logging e monitoraggio ibridi 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à, consulta il Security Best Practice Center di Google Cloud e il Enterprise Foundations Blueprint.

Gli obiettivi di conformità possono variare in quanto sono influenzati da sia i regolamenti specifici del settore sia i diversi requisiti normativi di regioni e paesi diversi. Per ulteriori informazioni, consulta Google Cloud centro risorse per la conformità. Di seguito sono riportate alcune delle principali approcci per la progettazione di 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 capire il target dell'architettura e dell'ambiente prima di implementare i controlli di sicurezza, 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 è possibile migliorare l'efficienza e consentire una governance unificata e strumenti.

  • 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, vulnerabilità e altro ancora. Analisi dello stato della sicurezza è uno strumento gestito di analisi delle vulnerabilità. È una funzionalità di Security Command Center che identifica i rischi e le vulnerabilità per la sicurezza Google Cloud e fornisce suggerimenti per la correzione che li rappresentano.

Mandiant Attack Surface Management per Google Cloud consente alla tua organizzazione di vedere meglio gli asset del proprio ambiente multicloud o cloud ibrido. Rileva automaticamente gli asset più cloud provider, il DNS e la superficie di attacco esterna estesa una comprensione più approfondita del suo ecosistema. Utilizza queste informazioni per dare priorità alla correzione di vulnerabilità ed esposizioni che presentano il rischio maggiore.

  • Soluzione SIEM (Security Information and Event Management) nel cloud: aiuta per raccogliere e analizzare i log di sicurezza da ambienti ibridi e multi-cloud ambienti per rilevare e rispondere alle minacce. SIEM per le operazioni di sicurezza di Google di Google Cloud consente di fornire informazioni di sicurezza ed eventi della gestione raccogliendo, analizzando, rilevando e indagando tutti i tuoi dati di sicurezza in un unico posto.