Modelli di architettura ibrida e multi-cloud

Last reviewed 2023-12-14 UTC

Questo è il secondo di tre documenti in un insieme. Parla dei modelli ibridi e di architettura multi-cloud. Descrive inoltre gli scenari per i quali questi pattern sono più adatti. Infine, fornisce le best practice che puoi quando si esegue 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 rete sicura ibrida e multi-cloud: discute i modelli di architettura di rete ibrida e multi-cloud dal punto di vista della rete.

Ogni azienda dispone di un portafoglio unico di carichi di lavoro delle applicazioni che Requisiti e vincoli dell'architettura di un ambiente ibrido o multi-cloud configurazione. 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 modello di architettura è un modo ripetibile per strutturare più funzioni componenti di una soluzione tecnologica, un'applicazione o un servizio per creare riutilizzabile che soddisfa determinati requisiti o casi d'uso. R soluzione tecnologica basata su cloud è spesso composta da diversi e servizi cloud distribuiti. Questi servizi collaborano per fornire le informazioni necessarie funzionalità. In questo contesto, ogni servizio è considerato 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. Una tale architettura può essere standardizzati per soddisfare casi d'uso aziendali specifici e fungere da di base e riutilizzabile.

Per definire in generale un pattern di architettura per un'applicazione o una soluzione, identificare e definire quanto segue:

  • I componenti della soluzione o dell'applicazione.
  • Le funzioni previste per ogni componente, ad esempio frontend per fornire una Graphic User Interface o funzioni di backend al che forniscono 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 architettura ibrida e multi-cloud pattern:

  • Modelli di architettura distribuita: Questi pattern si basano su un deployment distribuito di carichi di lavoro o componenti. Ciò significa che eseguono un'applicazione (o componenti specifici quell'applicazione) nell'ambiente di computing che meglio si adatta al pattern. In questo modo il pattern può trarre il massimo profitto dalle diverse proprietà caratteristiche degli ambienti di calcolo distribuiti e interconnessi.
  • Pattern di architettura ridondante: Questi pattern si basano su implementazioni ridondanti dei carichi di lavoro. In queste di progettazione, il deployment delle stesse applicazioni e dei relativi componenti ambienti di computing. L'obiettivo è aumentare il rendimento capacità o resilienza di un'applicazione o per replicare per lo sviluppo e il test.

Quando implementi il pattern di architettura selezionato, devi utilizzare un metodo adatto archetipo di deployment. Gli archetipi di deployment sono a livello di zona, di singola regione, di più regioni 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:

Collaboratori

Autore: Marwan Al Shawi | Partner Customer Engineer

Altri collaboratori:

Avanti
Modelli di architettura distribuita