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.
Esegui il refactoring
In una migrazione di refactoring, modifichi i carichi di lavoro per sfruttare al meglio il cloud non solo per farle funzionare nel nuovo ambiente. Puoi migliorare per ogni carico di lavoro in termini di prestazioni, funzionalità, costi ed esperienza utente. Come evidenziato in Esegui il refactoring: sposta e migliora, alcuni scenari di refactoring ti consentono di modificare dei carichi di lavoro prima di eseguirne la migrazione al cloud. Questo approccio di refactoring offre i vantaggi riportati di seguito, soprattutto se il tuo obiettivo è creare un modello un'architettura con target a lungo termine:
- Puoi migliorare il processo di deployment.
- Puoi accelerare la cadenza di pubblicazione e ridurre cicli di feedback monitorando l'integrazione continua/il deployment continuo infrastruttura e strumenti (CI/CD).
- Puoi utilizzare il refactoring come base per creare e gestire 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, la configurazione di un account Container Registry e provisioning dei cluster Kubernetes per la containerizzazione diverse applicazioni. La versione Google Kubernetes Engine (GKE) Enterprise può essere utile in questo approccio per ambienti ibridi. Per saperne di più su GKE Enterprise, consulta quanto segue. . 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 computing a un altro
senza modificare significativamente l'applicazione e il modello operativo:
- Il deployment e la gestione delle applicazioni sono coerenti ambienti di computing.
- 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 all’automazione della creazione dell’infrastruttura è attraverso Infrastructure as Code (IaC). IaC implica la gestione dell'infrastruttura anziché configurare manualmente le risorse, ad esempio una VM, un gruppo 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 gruppi ambienti cloud-native.
Per ulteriori informazioni 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 Puppe o Cuoco per stabilire un processo comune di deployment e configurazione. In alternativa, puoi usare uno strumento di cottura delle immagini come Packer per creare immagini VM per piattaforme diverse. Utilizzando un singolo file condiviso di configurazione del deployment, puoi utilizzare Packer e Cloud Build per creare un'immagine VM da utilizzare su Compute Engine. Infine, puoi utilizzare le soluzioni come Prometheus e Grafana, per garantire un monitoraggio coerente ambienti cloud-native.
Sulla base di questi strumenti, puoi assemblare una catena di attrezzi comune come illustrato nella seguendo il diagramma logico. Questa catena di strumenti comune elimina le differenze tra gli ambienti di elaborazione. Consente inoltre di unificare provisioning, deployment la gestione e il monitoraggio.
Sebbene una catena di strumenti comune possa aiutare a raggiungere la portabilità, è soggetta alle diverse delle seguenti carenze:
- Usare le VM come base comune può rendere difficile l'implementazione le vere applicazioni cloud-first. Inoltre, l'utilizzo di VM solo può impedirti di utilizzando servizi gestiti nel cloud. Potresti perdere opportunità di ridurre costi generali amministrativi.
- 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 e su misura 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 offerte dal tuo cloud provider. Quando il tuo fornitore offre servizi gestiti che per supportare lo stesso caso d'uso, puoi astrarne parte della complessità. Attività Ciò ti consente di concentrarti sul carico di lavoro e sull'architettura delle applicazioni anziché dell'infrastruttura sottostante.
Ad esempio, puoi utilizzare Modello di risorse Kubernetes per automatizzare la creazione di cluster Kubernetes utilizzando un modello alla configurazione iniziale. Puoi utilizzare la modalità Conversione di Deployment Manager per convertire le configurazioni e i modelli di Deployment Manager ad altri formati di configurazione dichiarativi supportati da Google Cloud (come Terraform e Kubernetes Resource Model), quindi sono portabili quando pubblicare.
Puoi anche prendere in considerazione automatizzare nonché la creazione di progetti e 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 di funzionalità gestite nel cloud aiuta a ridurre la complessità della creazione e mantenere una catena di strumenti personalizzata per ottenere automazione e portabilità dei carichi di lavoro. Tuttavia, solo l'utilizzo delle VM come base comune rende difficile l'implementazione davvero cloud-first. Una soluzione è utilizzare container e Kubernetes .
I container consentono un'esecuzione affidabile del software quando lo sposti ambiente a un 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 per le tue applicazioni containerizzate. È open source e regolato dai Cloud Native Computing Foundation. Kubernetes fornisce i servizi che costituiscono la base di un ambiente cloud-first un'applicazione. Perché puoi installare ed eseguire Kubernetes su molte risorse ambienti di lavoro, puoi utilizzarlo anche per stabilire un livello di runtime comune di computing dei contenuti:
- 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ù alto rispetto a quando si lavora con le VM, il che si traduce in genere in una delle risorse di base e ha migliorato la produttività degli sviluppatori.
- A differenza di una catena di strumenti personalizzata, Kubernetes è ampiamente adottato sia per sviluppo e gestione delle applicazioni, in modo da poter attingere alle esperienza, documentazione e assistenza di terze parti.
- Kubernetes supporta tutte le implementazioni di container che:
- Supporta Kubernetes Interfaccia di runtime del container (CRI)
- 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 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 in molti ambienti di computing 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 e applicare la conformità di sicurezza e offrono osservabilità e risoluzione dei problemi profonda della rete.
Come illustrato nel diagramma seguente, utilizzando GKE Enterprise significa che puoi utilizza applicazioni multi-cluster come parchi risorse.
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 le complessità multi-cloud con una governance, operazioni e strategia di sicurezza coerenti 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 consente architettura distribuita Zero Trust. In un'architettura distribuita Zero Trust, per i servizi di cui viene eseguito on-premise o in un altro ambiente cloud possono comunicare tra ambienti mediante comunicazioni tra servizi 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 complicazioni e le differenze ambienti cloud-native. Il seguente elenco descrive alcune di queste astrazioni:
- Un'applicazione potrebbe essere portabile in un ambiente diverso
modifiche minime, ma ciò non significa che l'applicazione esegua
altrettanto 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.
- Comportamento e prestazioni dei bilanciatori del carico di cui è stato eseguito il provisioning Kubernetes o GKE Enterprise potrebbero differire da un ambiente all'altro.
Spostamento dei dati
Poiché può essere complesso spostare, condividere e accedere ai dati su larga scala ambienti di lavoro, le aziende di livello aziendale potrebbero esitare a creare un'architettura ibrida o multi-cloud. 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 ti aiutano per archiviare, condividere e accedere ai dati in diversi ambienti in un per 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 diverse 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 le diverse attività i casi d'uso e i dati su cui si basano. 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, la classificazione può aiutare a identificare le località di archiviazione e i dati tra regioni restrizioni di movimento 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 esplorare il processo, dalla pianificazione di un trasferimento di dati all'utilizzo delle best practice per implementare 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, il loro attacco della superficie può aumentare a seconda del modo in cui i sistemi e i dati sono distribuiti in diversi ambienti. 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 demarcazione esatta delle responsabilità in un'architettura multi-cloud.
L'osservabilità è fondamentale per ottenere insight e metriche dai diversi ambienti cloud-native. In un'architettura multi-cloud, ciascun cloud solitamente fornisce strumenti da monitorare sicurezza ed errori di configurazione. 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 sicurezza complessiva end-to-end visibilità per gli ambienti ibridi e multi-cloud, è difficile per stabilire le priorità e mitigare le vulnerabilità.
Per ottenere l'intero visibilità e postura di tutti gli ambienti, dare priorità alle vulnerabilità e a mitigare le vulnerabilità identificate. Consigliamo di eseguire il deployment di visibilità del modello. 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 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 per soddisfare i tuoi obiettivi di sicurezza e conformità, esplora Google Cloud Centro best practice per la sicurezza e ai progetto di base delle fondazioni aziendali.
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:
Sviluppa una strategia e un’architettura di sicurezza cloud personalizzate e unificate. Ibrido e le strategie di sicurezza multi-cloud devono essere adattate alle esigenze specifiche gli obiettivi 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.
Considera un'architettura di sicurezza unificata in ambienti ibridi e multi-cloud ambienti cloud-native.
Standardizza la progettazione e i deployment nel cloud, in particolare la progettazione e le funzionalità di machine learning. In questo modo è possibile migliorare l'efficienza e consentire una governance unificata e strumenti.
Utilizza più controlli di sicurezza.
In genere, nessun singolo controllo della sicurezza soddisfare in modo adeguato tutti i requisiti di protezione della sicurezza. Pertanto, le organizzazioni dovrebbero utilizzare una combinazione di controlli di sicurezza in un approccio alla difesa, noto anche come difesa in profondità.
Monitorare e migliorare continuamente le misure di sicurezza: la tua organizzazione dovrebbe monitora i suoi diversi ambienti alla ricerca di minacce e vulnerabilità alla sicurezza. Dovrebbe anche cercare di migliorare continuamente la propria strategia di sicurezza.
Valuta la possibilità di utilizzare Cloud Security posture Management (CSPM) per identificare e risolvere errori di configurazione della sicurezza e minacce alla cybersicurezza. CSPM offre valutazioni delle vulnerabilità in ambienti ibridi e multi-cloud ambienti cloud-native.
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 il proprio ambiente cloud multi-cloud o ibrido asset. 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.