Il modello di architettura multi-cloud partizionato combina più istanze gestiti da diversi provider di servizi cloud. Questo offre la flessibilità necessaria per eseguire il deployment di un'applicazione di computing che tiene conto i driver multi-cloud e le considerazioni discusse nella prima parte di questo Google Cloud.
Il seguente diagramma mostra un'architettura multi-cloud partizionata pattern.
Questo pattern di architettura può essere creato in due modi diversi. Il primo approccio si basa sul deployment dei componenti dell'applicazione in diversi cloud pubblico ambienti cloud-native. Questo approccio è noto anche come architettura composita ed è lo stesso approccio del pattern di architettura ibrida a più livelli. Invece di utilizzare un ambiente on-premise con un servizio cloud, tuttavia, utilizza almeno due ambienti cloud. In un'architettura composita, un singolo carico di lavoro o un'applicazione utilizza componenti di più cloud. Il secondo approccio esegue il deployment di diverse applicazioni ambienti cloud pubblico. Il seguente elenco non esaustivo descrive alcuni fattori di business per il secondo approccio:
- Per integrare completamente le applicazioni ospitate in ambienti cloud diversi durante uno scenario di fusione e acquisizione tra due aziende.
- Per promuovere la flessibilità e soddisfare le diverse preferenze relative al cloud all'interno della tua organizzazione. Adotta questo approccio per incoraggiare le unità organizzative a scegliere il cloud provider più adatto alle loro esigenze e preferenze specifiche.
- Per operare in un deployment cloud multiregionale o globale. Se di un'azienda è tenuta ad aderire alle normative sulla residenza dei dati in regioni o paesi, dovrà scegliere tra quelli disponibili dai provider di servizi cloud in quella località se il loro cloud provider principale non una regione cloud.
Con il pattern di architettura multi-cloud partizionato, facoltativamente puoi mantenere la possibilità di spostare i carichi di lavoro in base alle esigenze da un ambiente cloud pubblico all'altro. In questo caso, la portabilità dei carichi di lavoro diventa un requisito chiave. Quando esegui il deployment dei carichi di lavoro in più ambienti di computing, e vuoi mantenere la capacità di spostare i carichi di lavoro tra gli ambienti, devono astrarre le differenze tra gli ambienti. Utilizzando GKE Enterprise, puoi progettare e creare una soluzione complessità multi-cloud con governance, operazioni e sicurezza coerenti le posture. Per ulteriori informazioni, consulta GKE Multi-Cloud.
Come detto in precedenza, in alcune situazioni potrebbero verificarsi per motivi aziendali e tecnici per combinare Google Cloud con un altro cloud del cloud privato e di partizionare i carichi di lavoro tra questi ambienti cloud. Le soluzioni multi-cloud offrono la flessibilità necessaria per eseguire la migrazione, creare e ottimizzare la portabilità delle applicazioni in ambienti multi-cloud, riducendo al minimo i vincoli e aiutandoti a soddisfare i requisiti normativi. Ad esempio, potresti collegare Google Cloud a Oracle Cloud Infrastructure (OCI) per creare una soluzione multi-cloud che sfrutta le funzionalità di ogni piattaforma utilizzando un Cloud Interconnect privato per combinare i componenti in esecuzione in OCI con le risorse in esecuzione su Google Cloud. Per ulteriori informazioni, consulta Google Cloud e Oracle Cloud Infrastructure: sfrutta al meglio il multi-cloud. Inoltre, Cross-Cloud Interconnect facilita la connettività dedicata a elevata larghezza di banda tra Google Cloud e altro provider di servizi cloud supportati, che ti consente di progettare e creare soluzioni multi-cloud per gestire volume di traffico tra cloud.
Vantaggi
Sebbene l'utilizzo di un'architettura multi-cloud offra diversi vantaggi tecnici e aziendali, come discusso in Fattori, considerazioni, strategia e approcci, è essenziale eseguire una valutazione dettagliata della fattibilità di ogni potenziale vantaggio. La valutazione deve prendere in considerazione attentamente eventuali sfide dirette o indirette o potenziali ostacoli associati e la tua capacità di gestirli in modo efficace. Inoltre, tieni presente che la crescita a lungo termine delle tue applicazioni o dei tuoi servizi può possono introdurre complessità che potrebbero superare i vantaggi iniziali.
Ecco alcuni vantaggi chiave del pattern di architettura multicloud suddivisa:
In scenari in cui potresti dover ridurre al minimo l'impegno nei confronti di un singolo provider cloud, puoi distribuire le applicazioni su più provider cloud. Di conseguenza, potresti ridurre relativamente i vincoli al fornitore la possibilità di cambiare piano (in una certa misura) tra i vari cloud provider. Il cloud aperto aiuta a portare le funzionalità di Google Cloud, come GKE Enterprise, in località fisiche diverse. Di l'estensione delle funzionalità di Google Cloud on-premise, in più aree cloud e a livello perimetrale, offre flessibilità, agilità e promuove la trasformazione.
Per motivi normativi, puoi pubblicare annunci per un determinato segmento di utenti e i dati di un paese in cui Google Cloud non ha regione cloud.
Il pattern di architettura multi-cloud partizionato può contribuire a ridurre la latenza e migliorare la qualità complessiva dell'esperienza utente nelle località in cui il provider cloud principale non dispone di una regione cloud o di un point of presence. Questo pattern è particolarmente utile quando si utilizzano alta capacità e bassa latenza la connettività multi-cloud, come Cross-Cloud Interconnect e Interconnessione CDN con una rete CDN distribuita.
Puoi eseguire il deployment delle applicazioni su più cloud provider in modo da scegliere tra i migliori servizi offerti dagli altri cloud provider.
Il pattern di architettura multicloud partizionato può contribuire a semplificare e accelerare gli scenari di fusione e acquisizione, in cui le applicazioni e i servizi delle due aziende potrebbero essere ospitati in ambienti cloud pubblico diversi.
Best practice
- Inizia con il deployment di un carico di lavoro non mission critical. Questo deployment iniziale nel cloud secondario può quindi fungere da modello per futuri deployment o migrazioni. Tuttavia, questo approccio probabilmente non è applicabile in situazioni in cui il carico di lavoro specifico è legalmente o regolamentato devono risiedere in una regione cloud specifica e il cloud primario Il provider non dispone di una regione nel territorio richiesto.
- Riduci al minimo le dipendenze tra sistemi in esecuzione in diversi in ambienti cloud pubblico, in particolare quando la comunicazione in modo sincrono. Queste dipendenze possono rallentare le prestazioni e diminuire in generale e potrebbero incorrere in costi aggiuntivi per il trasferimento di dati in uscita.
- Per astrarre le differenze tra gli ambienti, valuta la possibilità di utilizzare i container e Kubernetes, laddove supportato e fattibile dalle applicazioni.
- Assicurati che le pipeline CI/CD e gli strumenti per il deployment e il monitoraggio sono coerenti tra gli ambienti cloud.
- Seleziona il pattern di architettura di rete ottimale che fornisca
soluzione di comunicazione efficiente ed efficace per le applicazioni
che utilizzano.
- La comunicazione deve essere granulare e controllata. Utilizza la sicurezza API per esporre i componenti dell'applicazione.
- Prendi in considerazione l'utilizzo di Pattern di architettura mesh o uno dei pattern di networking gated, in base ai tuoi requisiti tecnici e aziendali specifici.
- Per soddisfare le aspettative di disponibilità e prestazioni, progetta la tua soluzione in modo da garantire un'alta disponibilità (HA) end-to-end, una bassa latenza e livelli di throughput appropriati.
Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito.
- Se è richiesta la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cross-Cloud Interconnect.
Se utilizzi più CDN nell'ambito del tuo pattern di architettura partizionata multicloud e stai compilando l'altra CDN con file di dati di grandi dimensioni da Google Cloud, valuta la possibilità di utilizzare i link CDN Interconnect tra Google Cloud e i fornitori supportati per ottimizzare questo traffico e, potenzialmente, il relativo costo.
Estendi la tua soluzione di gestione delle identità tra gli ambienti in modo che i sistemi possano eseguire l'autenticazione sicura confini ambientali.
Per bilanciare efficacemente le richieste tra Google Cloud e un altro Google Cloud, puoi usare Cloud Load Balancing. Per ulteriori informazioni, vedi Routing del traffico a una località on-premise o a un altro cloud.
- Se il volume di trasferimento di dati in uscita da Google Cloud verso altri ambienti è elevato, valuta la possibilità Cross-Cloud Interconnect.
Per superare incoerenze nei protocolli, nelle API e nell'autenticazione in backend diversi, consigliamo, ove applicabile, eseguire il deployment di un gateway API o di un proxy come facade (facade). Questo gateway o proxy funge da punto di controllo centralizzato ed esegue le seguenti misure:
- Implementa misure di sicurezza aggiuntive.
- Protegge le app client e altri servizi dalle modifiche al codice del backend.
- facilita gli audit trail per la comunicazione tra tutti delle applicazioni cross-environment e dei relativi componenti disaccoppiati.
- Agisce come
livello di comunicazione intermedio
tra i servizi legacy e modernizzati.
- Apigee e Apigee ibrido consente di ospitare e gestire gateway di livello enterprise e ibridi in ambienti on-premise, perimetrali, in altri cloud ambienti Google Cloud.
In alcuni dei seguenti casi, l'utilizzo Cloud Load Balancing con un gateway API può fornire una soluzione solida e sicura per la gestione, la che distribuisce il traffico delle API su larga scala in più regioni:
- Esegui il deployment del failover multiregione per gli ambienti di runtime delle API Apigee in regioni diverse.
Aumento del rendimento con Cloud CDN.
Fornisce protezione WAF e DDoS tramite Google Cloud Armor.
Utilizza strumenti coerenti per il logging e il monitoraggio nel cloud ove possibile. Potresti considerare l'utilizzo dell'open source sistemi di monitoraggio di rete. Per ulteriori informazioni, consulta Pattern di logging e monitoraggio per cloud ibrido e multi-cloud.
Se esegui il deployment dei componenti dell'applicazione in modo distribuito, in modo che i componenti di una singola applicazione vengano implementati in più ambienti cloud, consulta le best practice per il pattern di architettura ibrida a più livelli.