Modèles d'architecture hybride et multicloud

Last reviewed 2024-10-24 UTC

Ce document est le deuxième d'un ensemble de trois. Il aborde les modèles courants d'architecture hybride et multicloud. Il décrit également les scénarios auxquels ces modèles sont les plus adaptés. Enfin, il fournit les bonnes pratiques à suivre lors du déploiement de telles architectures dans Google Cloud.

L'ensemble de documents sur les modèles d'architecture hybride et multicloud se compose des parties suivantes :

Chaque entreprise dispose d'un portefeuille unique de charges de travail d'application qui imposent des exigences et des contraintes à l'architecture d'une configuration hybride ou multicloud. Bien que vous deviez concevoir et adapter votre architecture pour répondre à ces contraintes et exigences, vous pouvez aussi vous appuyer sur certains modèles courants pour définir l'architecture de base.

Un modèle d'architecture est une façon reproductible de structurer plusieurs composants fonctionnels d'une solution technologique, d'une application ou d'un service pour créer une solution réutilisable qui répond à certaines exigences ou à certains cas d'utilisation. Une solution technologique basée sur le cloud est souvent composée de plusieurs services cloud distincts et distribués. Ces services collaborent pour fournir les fonctionnalités requises. Dans ce contexte, chaque service est considéré comme un composant fonctionnel de la solution technologique. De même, une application peut se composer de plusieurs niveaux fonctionnels, modules ou services, chacun pouvant représenter un composant fonctionnel de l'architecture de l'application. Une telle architecture peut être standardisée pour répondre à des cas d'utilisation spécifiques et servir de modèle réutilisable et fondamental.

Pour définir de manière générale un modèle d'architecture pour une application ou une solution, identifiez et définissez les éléments suivants :

  • Composants de la solution ou de l'application.
  • Les fonctions attendues pour chaque composant (par exemple, les fonctions de l'interface utilisateur graphique ou les fonctions de backend pour fournir un accès aux données).
  • Comment les composants communiquent entre eux et avec les systèmes ou utilisateurs externes. Dans les applications modernes, ces composants interagissent via des interfaces ou des API bien définies. Il existe un large éventail de modèles de communication, tels que les modèles asynchrones et synchrones, requête/réponse ou basés sur des files d'attente.

Voici les deux principales catégories de modèles d'architecture hybride et multicloud :

  • Modèles d'architecture distribuée : ces modèles reposent sur un déploiement distribué des charges de travail ou des composants d'application. Cela signifie qu'ils exécutent une application (ou des composants spécifiques de cette application) dans l'environnement informatique qui convient le mieux au modèle. Cela permet au modèle de tirer parti des différentes propriétés et caractéristiques des environnements informatiques distribués et interconnectés.
  • Modèles d'architecture redondante : ces modèles sont basés sur des déploiements redondants de charges de travail. Dans ces modèles, vous déployez les mêmes applications et leurs composants dans plusieurs environnements informatiques. L'objectif est d'augmenter la capacité de performances ou la résilience d'une application, ou de répliquer un environnement existant pour le développement et les tests.

Lorsque vous implémentez le modèle d'architecture que vous sélectionnez, vous devez utiliser un archétype de déploiement approprié. Les archétypes de déploiement sont zonaux, régionaux, multirégionaux ou mondiaux. Cette sélection constitue la base de la construction d'architectures de déploiement spécifiques aux applications. Chaque archétype de déploiement définit une combinaison de domaines de défaillance dans lesquels une application peut fonctionner. Ces domaines de défaillance peuvent englober une ou plusieurs Google Cloud zones ou régions et peuvent être étendus pour inclure vos centres de données sur site ou vos domaines de défaillance dans d'autres fournisseurs de services cloud.

Cette série contient les pages suivantes :

Contributeurs

Auteur : Marwan Al Shawi | Partner Customer Engineer

Autres contributeurs :