Les composants d'architecture d'une application peuvent être classés en tant que composants d'interface ou de backend. Dans certains cas, ces composants peuvent être hébergés pour fonctionner à partir de différents environnements informatiques. Dans le modèle d'architecture hybride par tranche, les environnements informatiques sont situés dans un environnement informatique privé sur site et dans Google Cloud.
Les composants de l'application d'interface sont directement exposés aux utilisateurs finaux ou aux appareils. Par conséquent, ces applications sont souvent sensibles aux performances. Pour développer de nouvelles fonctionnalités et améliorations, les mises à jour logicielles peuvent être fréquentes. Comme les applications de frontend reposent généralement sur des applications backend pour stocker et gérer les données, et éventuellement la logique métier et le traitement des entrées utilisateur, elles sont souvent sans état ou ne gèrent que des volumes limités de données.
Pour qu'elles soient accessibles et utilisables, vous pouvez créer vos applications d'interface avec différents frameworks et technologies. Les performances de l'application, la vitesse de réponse et la compatibilité avec les navigateurs sont quelques-uns des facteurs clés d'une application d'interface réussie.
Les composants d'application backend sont généralement axés sur le stockage et la gestion des données. Dans certaines architectures, la logique métier peut être intégrée au composant backend. Les applications backend ont tendance à être mises à jour moins souvent que les applications d'interface. Les applications backend doivent gérer les problèmes suivants :
- Gérer un grand volume de requêtes
- Gérer un grand volume de données
- Sécuriser les données
- Maintenir les données actuelles et mises à jour sur toutes les instances dupliquées du système
L'architecture d'application à trois niveaux est l'une des implémentations les plus populaires pour créer des applications Web d'entreprise, comme des sites Web d'e-commerce contenant différents composants d'application. Cette architecture contient les niveaux suivants. Chaque niveau fonctionne indépendamment, mais ils sont étroitement liés et fonctionnent tous ensemble.
- Interface Web et niveau de présentation
- Niveau d'application
- Accès aux données ou niveau de backend
Placer ces couches dans des conteneurs permet de séparer leurs besoins techniques, comme les exigences de mise à l'échelle, et de les migrer de manière progressive. Cela permet également de les déployer sur des services cloud indépendants de la plate-forme, pouvant être portables entre différents environnements, d'utiliser la gestion automatisée et d'évoluer avec des plates-formes gérées dans le cloud telles que Cloud Run ou Google Kubernetes Engine (GKE) édition Enterprise De plus, les bases de données gérées par Google Cloud, telles que Cloud SQL, permettent de fournir le backend en tant que couche de base de données.
Le modèle d'architecture hybride par tranche consiste à déployer des composants d'application d'interface existants dans le cloud public. Dans ce modèle, vous conservez tous les composants d'application backend existants dans leur environnement informatique privé. En fonction de l'échelle et de la conception spécifique de l'application, vous pouvez migrer les composants d'application de l'interface utilisateur au cas par cas. Pour en savoir plus, consultez Migrer vers Google Cloud.
Si vous disposez déjà d'une application avec des composants backend et d'interface hébergés dans votre environnement sur site, tenez compte des limites de votre architecture actuelle. Par exemple, à mesure que votre application évolue et que les exigences de ses performances et de sa fiabilité augmentent, vous devez commencer à évaluer si certaines parties de votre application doivent être refactorisées ou déplacées vers une autre architecture plus optimale. Le modèle d'architecture hybride par tranche vous permet de transférer certaines charges de travail et certains composants de votre application vers le cloud avant d'effectuer une transition complète. Il est également essentiel de prendre en compte le coût, le temps et les risques liés à une telle migration.
Le schéma suivant montre un modèle d'architecture hybride par tranche.
Dans le schéma précédent, les requêtes client sont envoyées à l'interface de l'application hébergée dans Google Cloud. À son tour, l'interface de l'application renvoie des données à l'environnement sur site où le backend de l'application est hébergé (idéalement via une passerelle API).
Avec le modèle d'architecture hybride par tranche, vous pouvez exploiter l'infrastructure et les services mondiaux de Google Cloud, comme illustré dans l'exemple d'architecture du schéma suivant. L'interface de l'application est accessible via Google Cloud. Elle eut également ajouter de l'élasticité à l'interface en utilisant l'autoscaling pour répondre de manière dynamique et efficace à la demande de scaling sans provisionner l'infrastructure de manière excessive. Vous pouvez utiliser différentes architectures pour créer et exécuter des applications Web évolutives sur Google Cloud. Chaque architecture présente des avantages et des inconvénients pour différentes exigences.
Pour en savoir plus, regardez la vidéo Trois façons d'exécuter des applications Web évolutives sur Google Cloud sur YouTube. Pour en savoir plus sur les différentes façons de moderniser votre plate-forme d'e-commerce sur Google Cloud, consultez Créer une plate-forme d'e-commerce numérique sur Google Cloud.
Dans le schéma précédent, l'interface de l'application est hébergée sur Google Cloud pour offrir une expérience utilisateur multirégionale et optimisée à l'échelle mondiale, qui utilise l'équilibrage de charge global, l'auto-scaling et la protection contre les attaques par déni de service via Google Cloud Armor.
Au fil du temps, le nombre d'applications que vous déployez dans le cloud public peut augmenter au point que vous pourriez envisager de transférer les composants de l'application backend vers le cloud public. Si vous prévoyez de gérer un trafic important, l'utilisation de services gérés dans le cloud peut vous aider à réduire les efforts d'ingénierie liés à la gestion de votre propre infrastructure. Envisagez cette option, sauf si des contraintes ou des exigences exigent l'hébergement de composants d'application backend sur site. Par exemple, si vos données backend sont soumises à des restrictions réglementaires, vous devrez probablement les conserver sur site. Toutefois, le cas échéant et conformément aux exigences de conformité, vous pouvez déplacer ces données à l'aide des fonctionnalités de protection des données sensibles telles que les techniques d'anonymisation lorsque cela est nécessaire.
Dans le modèle d'architecture hybride par tranche, vous pouvez également utiliser Google Distributed Cloud Edge dans certains scénarios. Le service Cloud Edge distribué vous permet d'exécuter des clusters Google Kubernetes Engine sur du matériel dédié fourni et géré par Google et distinct du centre de données Google Cloud. Pour vous assurer que le service Cloud Edge distribué répond à vos besoins actuels et futurs, soyez conscient des limites de ce service par rapport à une zone GKE traditionnelle dans le cloud.
Avantages
Le fait de se concentrer d'abord sur les applications d'interface présente plusieurs avantages, y compris les suivants:
- Les composants d'interface dépendent des ressources du backend et parfois d'autres composants d'interface.
- Les composants backend ne dépendent pas des composants d'interface. Par conséquent, l'isolement et la migration d'applications d'interface ont tendance à être moins complexes que l'opération de migration d'applications backend.
- Étant donné que les applications d'interface sont souvent sans état ou qu'elles ne gèrent pas les données elles-mêmes, elles ont tendance à être plus faciles à migrer que les backends.
- Les composants d'interface peuvent être optimisés lors de la migration pour utiliser une architecture sans état. Pour en savoir plus, regardez la vidéo Porter des applications Web avec état vers Cloud Run sur YouTube.
Le déploiement d'applications d'interface existantes ou nouvellement développées dans le cloud public présente plusieurs avantages :
- De nombreuses applications d'interface sont soumises à des modifications fréquentes. Lorsque ces applications sont exécutées dans le cloud public, la configuration d'un processus d'intégration continue/de déploiement continu (CI/CD) est simplifiée. Vous pouvez utiliser CI/CD pour envoyer des mises à jour de manière efficace et automatisée. Pour plus d'informations, consultez la page CI/CD sur Google Cloud.
- Les interfaces sensibles aux performances et soumises à des charges de trafic variables peuvent grandement bénéficier des fonctionnalités d'équilibrage de charge, de déploiement multirégional, de mise en cache de Cloud CDN, sans serveur et d'autoscaling offertes par un déploiement dans le cloud (idéalement avec une architecture sans état).
L'adoption de microservices avec des conteneurs à l'aide d'une plate-forme gérée dans le cloud, comme GKE, vous permet d'utiliser des architectures modernes telles que le microfrontend, qui étendent les microservices aux composants frontaux.
L'extension des microservices est couramment utilisée avec des interfaces qui impliquent plusieurs équipes collaborant sur la même application. Ce type de structure d'équipe nécessite une approche itérative et une maintenance continue. Voici quelques-uns des avantages qu'offre l'utilisation de microinterfaces:
- Elle peut être transformée en modules de microservices indépendants pour le développement, les tests et le déploiement.
- Elle permet aux équipes de développement individuelles de sélectionner leurs technologies et leur code préférés.
- Cela permet d'accélérer les cycles de développement et de déploiement sans affecter les autres composants d'interface pouvant être gérés par d'autres équipes.
Qu'elles mettent en œuvre des interfaces utilisateur ou des API, ou qu'elles gèrent l'ingestion de données IoT (Internet des objets), les applications d'interface peuvent bénéficier des fonctionnalités de services cloud tels que Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine ou Cloud Run.
Les proxys d'API gérés dans le cloud permettent d'effectuer les opérations suivantes:
- Dissocier l'API associée aux applications de vos services de backend, tels que les microservices.
- Protéger les applications contre les modifications du code backend.
- Compatibilité avec vos architectures de frontend basées sur des API existantes, comme le backend pour les interface (BFF), le microfrontend et d'autres.
- Exposer vos API sur Google Cloud ou dans d'autres environnements en implémentant des proxys d'API sur Apigee.
Vous pouvez également appliquer le modèle hybride par tranche dans l'ordre inverse, en déployant des backends dans le cloud tout en conservant les interfaces dans des environnements informatiques privés. Bien que cette approche soit moins courante, elle est particulièrement adaptée à une interface lourde et monolithique. Dans ce cas, il pourrait être plus facile d'extraire les fonctionnalités de backend par itération et de déployer ces nouveaux backends dans le cloud.
La troisième partie de cette série présente les modèles de réseau possibles pour permettre une telle architecture. Apigee hybrid sert de plate-forme pour créer et gérer des proxys d'API dans un modèle de déploiement hybride. Pour en savoir plus, consultez la section Architecture à couplage lâche, y compris les architectures monolithiques et multicouches.
Bonnes pratiques
Utilisez les informations de cette section pour planifier votre architecture hybride par tranche.
Bonnes pratiques pour réduire la complexité
Lorsque vous appliquez le modèle d'architecture hybride par tranche, tenez compte des bonnes pratiques suivantes qui peuvent vous aider à réduire son déploiement global et sa complexité opérationnelle:
- Sur la base de l'évaluation des modèles de communication des applications identifiées, sélectionnez la solution de communication la plus efficace pour ces applications.
Comme la plupart des interactions utilisateur impliquent des systèmes connectés à travers plusieurs environnements informatiques, une connectivité rapide et à faible latence entre ces systèmes est importante. Pour répondre aux attentes de disponibilité et de performances, vous devez concevoir des solutions offrant une haute disponibilité, une faible latence et des niveaux de débit appropriés. Du point de vue de la sécurité, la communication doit être précise et contrôlée. Idéalement, vous devez exposer les composants de l'application à l'aide d'API sécurisées. Pour en savoir plus, consultez la section Sortie contrôlée.
- Pour minimiser la latence des communications entre les environnements, sélectionnez une région Google Cloud géographiquement proche de l'environnement informatique privé dans lequel les composants du backend de votre application sont hébergés. Pour plus d'informations, consultez la section Bonnes pratiques pour la sélection des régions Compute Engine.
- Réduisez les dépendances élevées entre les systèmes exécutés dans des environnements différents, en particulier lorsque la communication est gérée de manière synchrone. Ces dépendances peuvent ralentir les performances, réduire la disponibilité globale et entraîner des frais de transfert de données sortantes supplémentaires.
- Avec le modèle d'architecture hybride par tranche, vous pouvez avoir des volumes de trafic entrants plus importants depuis des environnements sur site vers Google Cloud par rapport au trafic sortant de Google Cloud. Néanmoins, vous devez connaître le volume de transfert de données sortant attendu qui quitte Google Cloud. Si vous prévoyez d'utiliser cette architecture à long terme avec des volumes de transfert de données sortants élevés, envisagez d'utiliser Cloud Interconnect. Cloud Interconnect peut vous aider à optimiser les performances de connectivité et à réduire les frais de transfert de données sortants pour le trafic qui répond à certaines conditions. Pour en savoir plus, consultez la section sur les tarifs de Cloud Interconnect.
- Pour protéger les informations sensibles, nous vous recommandons de chiffrer toutes les communications en transit. Si le chiffrement est requis au niveau de la couche de connectivité, vous pouvez utiliser des tunnels VPN, le VPN haute disponibilité sur Cloud Interconnect et MACsec pour Cloud Interconnect.
Pour résoudre les incohérences entre les protocoles, les API et les mécanismes d'authentification sur divers backends, nous vous recommandons, le cas échéant, de déployer une passerelle API ou un proxy en tant que façade unifiée. Cette passerelle ou ce proxy agit comme un point de contrôle centralisé et effectue les mesures suivantes :
- Met en œuvre des mesures de sécurité supplémentaires.
- Protège les applications clientes et d'autres services contre les modifications du code de backend.
- Facilite les pistes d'audit pour la communication entre toutes les applications multi-environnements et ses composants découplés.
- Agit comme une couche de communication intermédiaire entre les services anciens et modernisés.
- Apigee et Apigee hybrid vous permettent d'héberger et de gérer des passerelles hybrides et de niveau entreprise dans des environnements sur site, de périphérie, d'autres clouds et Google Cloud.
Pour faciliter la mise en place de configurations hybrides, utilisez Cloud Load Balancing avec la connectivité hybride. Cela signifie que vous pouvez étendre les avantages de l'équilibrage de charge cloud aux services hébergés dans votre environnement de calcul sur site. Cette approche permet de migrer les charges de travail vers Google Cloud par étapes, avec une interruption minimale ou nulle, garantissant une transition en douceur des services distribués. Pour en savoir plus, consultez la page Présentation des groupes de points de terminaison du réseau de connectivité hybride.
Parfois, l'utilisation d'une passerelle API, ou d'un proxy et d'un équilibreur de charge d'application ensemble, peut fournir une solution plus robuste pour gérer, sécuriser et distribuer le trafic d'API à grande échelle. Utiliser Cloud Load Balancing avec des passerelles API vous permet d'effectuer les opérations suivantes :
- Fournissez des API hautes performances avec Apigee et Cloud CDN pour réduire la latence, héberger des API dans le monde entier et augmenter la disponibilité pendant les périodes de forte affluence. Pour en savoir plus, regardez la vidéo Fournir des API hautes performances avec Apigee et Cloud CDN sur YouTube.
- Implémentez une gestion avancée du trafic.
- Utilisez Google Cloud Armor comme service de protection contre les attaques DDoS et de sécurité réseau pour protéger vos API.
- Gérez l'équilibrage de charge efficace sur plusieurs passerelles dans plusieurs régions. Pour en savoir plus, regardez la vidéo Sécuriser les API et mettre en œuvre le basculement multirégional avec Private Service Connect et Apigee sur YouTube.
Utilisez la gestion d'API et le maillage de services pour sécuriser et contrôler la communication et l'exposition des services avec une architecture de microservices.
- Utilisez Cloud Service Mesh pour permettre la communication de service à service qui maintient la qualité de service dans un système composé de services distribués où vous pouvez gérer l'authentification, l'autorisation et le chiffrement entre les services.
- Utilisez une plate-forme de gestion des API telle qu'Apigee, qui permet à votre organisation et à vos entités externes d'utiliser ces services en les exposant sous forme d'API.
Établissez une identité commune entre les environnements afin que les systèmes puissent s'authentifier de manière sécurisée au-delà des limites de l'environnement.
Déployez des systèmes CI/CD et de gestion de la configuration dans le cloud public. Pour en savoir plus, consultez Modèle d'architecture de réseau en miroir.
Pour accroître l'efficacité opérationnelle, utilisez des outils et des pipelines CI/CD cohérents dans tous les environnements.
Bonnes pratiques pour les architectures d'applications et de charges de travail individuelles
- Bien que l'accent soit mis sur les applications d'interface dans ce modèle, n'oubliez pas pour autant la nécessité de moderniser les applications backend. Si le rythme de développement des applications backend est nettement plus lent que celui des applications d'interface, cette différence peut entraîner une complexité supplémentaire.
- Traiter les API comme des interfaces de backend simplifie les intégrations, le développement de l'interface utilisateur, les interactions avec les services et masque les complexités du système backend. Pour relever ces défis, Apigee facilite le développement et la gestion de passerelles/proxys d'API pour les déploiements hybrides et multicloud.
- Choisissez l'approche de rendu de votre application Web d'interface en fonction du contenu (statique ou dynamique), des performances de référencement et des attentes concernant la vitesse de chargement des pages.
- Lorsque vous sélectionnez une architecture pour des applications Web basées sur le contenu, différentes options sont disponibles, y compris des architectures monolithiques, sans serveur, basées sur des événements et à base de microservices. Pour sélectionner l'architecture la plus adaptée, évaluez soigneusement ces options en fonction de vos exigences actuelles et futures. Pour vous aider à prendre une décision architecturale qui correspond à vos objectifs commerciaux et techniques, consultez Comparaison des différentes architectures pour les backends d'applications Web axées sur le contenu et Points clés à prendre en compte pour les backends Web.
Avec une architecture de microservices, vous pouvez utiliser des applications en conteneurs avec Kubernetes en tant que couche d'exécution commune. Avec le modèle d'architecture hybride par tranche, vous pouvez l'exécuter dans l'un des scénarios suivants :
Dans les deux environnements (Google Cloud et vos environnements sur site).
- Lorsque vous utilisez des conteneurs et Kubernetes dans différents environnements, vous pouvez moderniser vos charges de travail, puis migrer vers Google Cloud à différents moments. Cela est utile lorsqu'une charge de travail dépend fortement d'une autre et ne peut pas être migrée individuellement, ou lorsqu'il faut utiliser la portabilité des charges de travail hybrides pour utiliser les meilleures ressources disponibles dans chaque environnement. Dans tous les cas, GKE Enterprise peut être une technologie clé. Pour en savoir plus, consultez la page Environnement hybride GKE Enterprise.
Dans un environnement Google Cloud pour les composants d'application migrés et modernisés.
- Utilisez cette approche lorsque d'anciens backends sur site ne sont pas compatibles avec la conteneurisation, ou que la modernisation à court terme requiert beaucoup de temps et de ressources.
Pour en savoir plus sur la conception et la refactorisation d'une application monolithique en architecture de microservices afin de moderniser votre architecture d'application Web, consultez la page Présentation des microservices.
Vous pouvez combiner des technologies de stockage de données en fonction des besoins de vos applications Web. L'utilisation de Cloud SQL pour les données structurées et de Cloud Storage pour les fichiers multimédias est une approche courante pour répondre à différents besoins de stockage de données. Cela dit, le choix dépend fortement de votre cas d'utilisation. Pour en savoir plus sur les options de stockage de données pour les backends d'applications basées sur le contenu et les modalités efficaces, consultez la page Options de stockage de données pour les applications Web basées sur le contenu. Consultez également Présentation des options de votre base de données Google Cloud.