Questo documento è il secondo di tre documenti in un insieme. Vengono descritti i modelli di architettura ibrida e multi-cloud più comuni. Descrive inoltre gli scenari per i quali questi pattern sono più adatti. Infine, fornisce le best practice che puoi utilizzare per il deployment di queste architetture in Google Cloud.
Il set di documenti per i modelli di architettura ibrida e multi-cloud è costituito da queste parti:
- Crea architetture ibride e multi-cloud: discute la pianificazione di una strategia per l'architettura di una configurazione ibrida e multi-cloud con Google Cloud.
- Modelli di architettura ibrida e multi-cloud: illustra i modelli di architettura comuni da adottare nell'ambito di una strategia ibrida e multi-cloud (questo documento).
- Modelli di architettura di reti sicure ibride e multi-cloud: discute i modelli di architettura di reti ibride e multi-cloud dal punto di vista della rete.
Ogni azienda ha un portafoglio unico di carichi di lavoro delle applicazioni che impongono requisiti e vincoli all'architettura di una configurazione ibrida o multi-cloud. Sebbene tu debba progettare e personalizzare l'architettura per soddisfare questi vincoli e requisiti, puoi fare affidamento su alcuni pattern comuni per definire l'architettura di base.
Un pattern di architettura è un modo ripetibile per strutturare più componenti funzionali di una soluzione, un'applicazione o un servizio tecnologico per creare una soluzione riutilizzabile che soddisfi determinati requisiti o casi d'uso. Una soluzione tecnologica basata su cloud è spesso composta da diversi servizi cloud distinti e distribuiti. Questi servizi collaborano per fornire le funzionalità richieste. In questo contesto, ogni servizio è considerato un componente funzionale della soluzione tecnologica. Analogamente, un'applicazione può essere composta da più livelli, moduli o servizi funzionali, ciascuno dei quali può rappresentare un componente funzionale dell'architettura dell'applicazione. Un'architettura di questo tipo può essere standardizzata per risolvere casi d'uso aziendali specifici e fungere da modello di base riutilizzabile.
Per definire in generale un pattern di architettura per un'applicazione o una soluzione, identifica e definisci quanto segue:
- I componenti della soluzione o dell'applicazione.
- Le funzioni previste per ogni componente, ad esempio le funzioni frontend per fornire un'interfaccia utente grafica o le funzioni di backend per fornire l'accesso ai dati.
- Come i componenti comunicano tra loro e con sistemi o utenti esterni. Nelle applicazioni moderne, questi componenti interagiscono tramite API o interfacce ben definite. Esistono diversi modelli di comunicazione, ad esempio asincroni e sincroni, basati su richiesta/risposta o su coda.
Di seguito sono riportate le due categorie principali di schemi di architettura ibrida e multi-cloud:
- Pattern di architettura distribuita: Questi pattern si basano su un deployment distribuito di carichi di lavoro o componenti di applicazioni. Ciò significa che eseguono un'applicazione (o componenti specifici di quell'applicazione) nell'ambiente di calcolo più adatto al pattern. In questo modo, il pattern può sfruttare le diverse proprietà e caratteristiche degli ambienti di calcolo distribuiti e interconnessi.
- Pattern di architettura ridondante: Questi pattern si basano su deployment ridondanti dei workload. In questi pattern, esegui il deployment delle stesse applicazioni e dei relativi componenti in più ambienti di calcolo. L'obiettivo è aumentare la capacità o la resilienza delle prestazioni di un'applicazione oppure replicare un ambiente esistente per lo sviluppo e i test.
Quando implementi il pattern di architettura selezionato, devi utilizzare un archetipo di implementazione adatto. Gli archetipi di deployment sono zonali, regionali, multiregionali o globali. Questa selezione costituisce la base per la costruzione di architetture di deployment specifiche per l'applicazione. Ogni archetipo di deployment definisce una combinazione di ambiti di errore all'interno dei quali un'applicazione può operare. Questi domini di errore possono includere una o più zone o regioni Google Cloud e possono essere espansi per includere i tuoi data center on-premise o i domini di errore in altri provider cloud.
Questa serie contiene le seguenti pagine:
Modelli di architettura ridondanti
Collaboratori
Autore: Marwan Al Shawi | Partner Customer Engineer
Altri collaboratori:
- Saud Albazei | Customer Engineer, Application Modernization
- Anna Berenberg | Engineering Fellow
- Marco Ferrari | Cloud Solutions Architect
- Victor Moreno | Product Manager, Cloud Networking
- Johannes Passing | Cloud Solutions Architect
- Mark Schlagenhauf | Technical Writer, Networking
- Daniel Strebel | Solution Lead EMEA, Application Modernization
- Ammett Williams | Developer Relations Engineer