Modèle hybride par tranche

Les composants d'architecture d'une application peuvent être classés dans l'une des deux catégories suivantes : frontend ou 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 d'application d'interface sont directement exposés aux utilisateurs finaux ou aux appareils. Par conséquent, ces applications sont souvent sensibles aux performances. Les mises à jour logicielles peuvent être fréquentes pour développer de nouvelles fonctionnalités et apporter des améliorations. Comme les applications 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 de données limités.

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 dédiés au stockage et à la gestion des données. Dans certaines architectures, la logique métier peut être intégrée au composant de backend. Les applications backend ont tendance à être mises à jour moins souvent que les applications d'interface. Les applications de backend doivent relever les défis suivants :

• Gérer un grand nombre de demandes
• Gérer un grand volume de données
• Sécuriser les données
• Maintenir des données actuelles et à jour dans toutes les répliques du système

La solution d'application Web à trois niveaux est l'une des implémentations les plus populaires pour créer des applications Web d'entreprise, comme les 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
• Niveau d'accès aux données ou backend

En plaçant ces couches dans des conteneurs, vous séparez leurs besoins techniques, comme les exigences de scaling, et vous pouvez 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 parGoogle Cloud, comme 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 de l'application d'interface 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 tenir compte du coût, du temps et des 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. En retour, l'interface de l'application renvoie les données à l'environnement sur site où est hébergé le backend de l'application (idéalement via une passerelle API).

Avec le modèle d'architecture hybride par tranche, vous pouvez exploiter l'infrastructure et les services mondiaux deGoogle 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 surGoogle 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 surGoogle Cloud pour offrir une expérience utilisateur multirégionale et optimisée à l'échelle mondiale, qui utilise l'équilibrage de charge global, l'autoscaling et la protection DDoS 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 d'application de backend vers le cloud public. Si vous prévoyez de diffuser un trafic important, opter pour des services gérés dans le cloud peut vous aider à économiser des efforts d'ingénierie lors de la gestion de votre propre infrastructure. Envisagez cette option, sauf si des contraintes ou des exigences imposent d'héberger les composants de l'application de backend sur site. Par exemple, si vos données de 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 dans certains scénarios. Distributed Cloud vous permet d'exécuter des clusters Google Kubernetes Engine sur du matériel dédié fourni et géré par Google, indépendamment du centre de données Google Cloud . Pour vous assurer que le service Distributed Cloud 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 frontend dépendent des ressources backend et parfois d'autres composants frontend.
• Les composants de backend ne dépendent pas des composants de frontend. Par conséquent, l'isolement et la migration d'applications d'interface ont tendance à être moins complexes que la 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 applications backend.
  • 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 YouTube How to port stateful web apps to Cloud Run (Comment migrer des applications Web avec état vers Cloud Run).

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 en savoir plus, consultez CI/CD sur Google Cloud.
• Les interfaces sensibles aux performances avec une charge de trafic variable peuvent grandement bénéficier des fonctionnalités d'équilibrage de charge, de déploiement multirégional, de mise en cache 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 microfrontend, qui étendent les microservices aux composants frontend.

  L'extension des microservices est couramment utilisée avec les 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 avantages de l'utilisation de microfrontends :

  • 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.
  • Il peut favoriser des cycles de développement et de déploiement rapides sans affecter le reste des composants de l'interface utilisateur qui peuvent ê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 vous aident à :

  • 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 moins courante, cette approche 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 aborde les modèles de mise en réseau possibles pour activer une telle architecture. Apigee hybrid est une plate-forme permettant de créer et de gérer des proxys d'API dans un modèle de déploiement hybride. Pour en savoir plus, consultez Architecture faiblement couplée, y compris les architectures monolithiques et de microservices à plusieurs niveaux.

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:

• En fonction 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 en termes de disponibilité et de performances, vous devez concevoir des systèmes offrant une haute disponibilité, une faible latence et des débits appropriés. Du point de vue de la sécurité, la communication doit être précise et contrôlée. Dans l'idéal, 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égionGoogle Cloud géographiquement proche de l'environnement informatique privé dans lequel sont hébergés les composants de backend de votre application. Pour en savoir plus, consultez 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 potentiellement 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 versGoogle Cloud par rapport au trafic sortant de Google Cloud. Toutefois, vous devez connaître le volume de transfert de données sortantes prévu quittant Google Cloud. Si vous prévoyez d'utiliser cette architecture à long terme avec des volumes de transfert de données sortantes élevés, envisagez d'utiliser Cloud Interconnect. Cloud Interconnect peut vous aider à optimiser les performances de connectivité et peut réduire les frais de transfert de données sortantes pour le trafic qui remplit 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 surmonter les incohérences dans les protocoles, les API et les mécanismes d'authentification entre différents backends, nous vous recommandons, le cas échéant, de déployer une passerelle ou un proxy API en tant que façade unifiée. Cette passerelle ou ce proxy sert de point de contrôle centralisé et effectue les mesures suivantes :

  • Implémente des mesures de sécurité supplémentaires.
  • Protège les applications clientes et les autres services contre les modifications du code de backend.
  • Facilite les journaux d'audit pour la communication entre toutes les applications multi-environnements et leurs 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, en périphérie, dans d'autres clouds et dans des environnementsGoogle 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 des migrations de charges de travail par phases vers Google Cloud avec une interruption de service minimale, voire nulle, ce qui garantit une transition fluide pour les services distribués. Pour en savoir plus, consultez la présentation des groupes de points de terminaison du réseau de connectivité hybride.

• Parfois, l'utilisation conjointe d'une passerelle d'API ou d'un proxy et d'un équilibreur de charge d'application peut fournir une solution plus robuste pour gérer, sécuriser et distribuer le trafic d'API à grande échelle. L'utilisation de 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émenter une gestion avancée du trafic.
  • Utilisez Cloud Armor comme service de protection contre les attaques DDoS et de sécurité réseau pour protéger vos API.
  • Gérer un équilibrage de charge efficace sur les passerelles de 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 des API et le maillage de services pour sécuriser et contrôler la communication et l'exposition des services avec l'architecture des microservices.

  • Utilisez Cloud Service Mesh pour permettre la communication entre les services nécessaires au maintien de 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 aux 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 la section Modèle d'architecture 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 de charges de travail et d'applications 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.
• Le traitement des API en tant qu'interfaces de backend simplifie les intégrations, le développement de l'interface, les interactions de service et masque les complexités du système de backend. Pour relever ces défis, Apigee facilite le développement et la gestion des 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 les applications Web axées sur le contenu, plusieurs options sont disponibles, y compris les architectures monolithiques, sans serveur, basées sur des événements et de microservices. Pour sélectionner l'architecture la plus adaptée, évaluez minutieusement ces options en fonction des exigences actuelles et futures de votre application. Pour vous aider à prendre une décision architecturale qui correspond à vos objectifs commerciaux et techniques, consultez Comparaison de 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 conteneurisées avec Kubernetes comme 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 avez la possibilité de moderniser les charges de travail, puis de 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 pour utiliser la portabilité des charges de travail hybrides afin d'utiliser les meilleures ressources disponibles dans chaque environnement. Dans tous les cas, GKE Enterprise peut être une technologie clé. Pour en savoir plus, consultez Environnement hybride GKE Enterprise.

  • Dans un environnement Google Cloud pour les composants d'application migrés et modernisés.

    • Utilisez cette approche lorsque vous disposez d'anciens backends sur site qui ne sont pas compatibles avec la conteneurisation ou qui nécessitent beaucoup de temps et de ressources pour être modernisés à court terme.

    Pour en savoir plus sur la conception et la refactorisation d'une application monolithique en architecture de microservices afin de moderniser l'architecture de votre application Web, consultez Introduction aux 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 à divers 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 axées sur le contenu et les modalités efficaces, consultez Options de stockage de données pour les applications Web axées sur le contenu. Consultez également Présentation des options de votre base de données Google Cloud .