Modelli di architettura ibrida e multi-cloud

Last reviewed 2024-10-24 UTC

Questo documento è il secondo di un insieme di tre documenti. Vengono illustrati i modelli di architettura ibrida e multi-cloud più comuni. Descrive inoltre gli scenari per cui questi pattern sono più adatti. Infine, fornisce le best practice che puoi utilizzare quando implementi queste architetture in Google Cloud.

Il set di documenti per i modelli di architettura ibrida e multi-cloud è composto da queste parti:

  • Crea architetture ibride e multi-cloud: descrive la pianificazione di una strategia per la progettazione di una configurazione ibrida e multi-cloud con Google Cloud.
  • Modelli di architettura ibrida e multi-cloud: descrive i modelli di architettura comuni da adottare nell'ambito di una strategia ibrida e multi-cloud (questo documento).
  • Modelli di architettura di rete sicura ibrida e multi-cloud: vengono illustrati i modelli di architettura di rete ibrida 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 architetturale è un modo ripetibile per strutturare più componenti funzionali di una soluzione tecnologica, un'applicazione o un servizio per creare una soluzione riutilizzabile che soddisfi determinati requisiti o casi d'uso. Una soluzione tecnologica basata sul cloud è spesso costituita 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 costituita da più livelli, moduli o servizi funzionali e ognuno può rappresentare un componente funzionale dell'architettura dell'applicazione. Questa architettura può essere standardizzata per rispondere a casi d'uso aziendali specifici e fungere da modello di base riutilizzabile.

Per definire in generale un pattern architetturale 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 una GUI o le funzioni backend per fornire l'accesso ai dati.
  • Come comunicano tra loro i componenti e con sistemi esterni o utenti. Nelle applicazioni moderne, questi componenti interagiscono tramite interfacce o API ben definite. Esiste un'ampia gamma di modelli di comunicazione, come asincrono e sincrono, richiesta-risposta o basato su code.

Di seguito sono riportate le due categorie principali di pattern di architettura ibrida e multicloud:

  • 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 computing più adatto al pattern. In questo modo, il pattern può sfruttare le diverse proprietà e caratteristiche degli ambienti di computing distribuiti e interconnessi.
  • Pattern di architettura ridondanti: 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 computing. L'obiettivo è aumentare la capacità o la resilienza di un'applicazione oppure replicare un ambiente esistente per lo sviluppo e il test.

Quando implementi il pattern di architettura che selezioni, devi utilizzare un archetipo di deployment adatto. Gli archetipi di deployment sono zonali, regionali, multiregionali o globali. Questa selezione costituisce la base per la creazione di architetture di deployment specifiche per l'applicazione. Ogni archetipo di deployment definisce una combinazione di domini di errore in cui un'applicazione può operare. Questi domini di errore possono comprendere una o più Google Cloud zone o regioni e possono essere espansi per includere i tuoi data center on-premise o domini di errore in altri fornitori di servizi cloud.

Questa serie contiene le seguenti pagine:

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

Avanti
Modelli di architettura distribuita