Avec le modèle d'architecture hybride d'environnement, vous conservez l'environnement de production d'une charge de travail dans le centre de données existant. Vous utilisez ensuite le cloud public pour vos environnements de développement et de test, ou d'autres environnements. Ce modèle repose sur le déploiement redondant des mêmes applications dans plusieurs environnements informatiques. L'objectif du déploiement est d'accroître la capacité, l'agilité et la résilience.
En évaluant les charges de travail à migrer, vous remarquerez peut-être des cas où l'exécution d'une application spécifique dans le cloud public pose certains défis :
- Des contraintes juridictionnelles ou réglementaires peuvent nécessiter que vous conserviez des données dans un pays spécifique.
- Des conditions de licence tierces peuvent vous empêcher d'utiliser certains logiciels dans un environnement cloud.
- Une application peut nécessiter un accès à des périphériques matériels disponibles seulement en local.
Dans de tels cas, vous devez tenir compte non seulement de l'environnement de production, mais également de tous les environnements impliqués dans le cycle de vie d'une application, y compris les systèmes de développement, de test et de préproduction. Ces restrictions s'appliquent souvent à l'environnement de production et à ses données. Elles peuvent ne pas s'appliquer aux autres environnements qui n'utilisent pas les données réelles. Vérifiez auprès du service de conformité de votre organisation ou de l'équipe équivalente.
Le schéma suivant illustre un modèle d'architecture hybride d'environnement typique.
Le fait de faire fonctionner des systèmes de développement et de test dans des environnements différents de ceux des systèmes de production peut sembler risqué et aller à l'encontre des bonnes pratiques existantes ou des tentatives visant à minimiser les différences entre de tels environnements. Bien que ces préoccupations soient justifiées, elles ne s'appliquent pas si vous faites une distinction entre les étapes des processus de développement et de test :
Même si les processus de développement, de test et de déploiement diffèrent d'une application à l'autre, ils impliquent généralement des variantes des étapes suivantes :
- Développement : créer une version finale
- Tests fonctionnels ou tests d'acceptation utilisateur : vérifier que la version finale répond aux exigences fonctionnelles
- Tests de performance et de fiabilité : vérifier que la version finale répond aux exigences non fonctionnelles Il s'agit également de tests de charge.
- Tests de préproduction ou de déploiement : vérifier que la procédure de déploiement fonctionne
- Production : publier des applications nouvelles ou mises à jour
L'exécution de plusieurs de ces étapes dans un seul environnement est rarement pratique. Chaque étape nécessite donc généralement un ou plusieurs environnements dédiés.
L'objectif principal d'un environnement de test est d'exécuter des tests fonctionnels. L'objectif principal d'un environnement de préproduction est de vérifier que les procédures de déploiement de votre application fonctionnent comme prévu. Dès lors qu'une version atteint un environnement de préproduction, vos tests fonctionnels devraient être terminés. La préproduction est la dernière étape avant le déploiement de logiciels dans votre déploiement de production.
Pour que les résultats de test soient significatifs et s'appliquent au déploiement de production, les environnements que vous utilisez tout au long du cycle de vie d'une application doivent tous respecter les règles suivantes, dans la mesure du possible :
- Tous les environnements sont équivalents du point de vue fonctionnel. En d'autres termes, l'architecture, les API ainsi que les versions des systèmes d'exploitation et des bibliothèques sont équivalentes, et les systèmes se comportent de la même manière dans tous les environnements. Cette équivalence permet d'éviter des situations où les applications fonctionneraient dans un environnement, mais échoueraient dans un autre, ou dans lesquelles les défaillances ne seraient pas reproductibles.
- Les environnements utilisés pour les tests de performance et de fiabilité, la préproduction et la production sont équivalents d'un point de vue non fonctionnel. Autrement dit, leurs performances, leur échelle et leur configuration, ainsi que la manière dont ils sont utilisés et gérés, sont identiques ou ne diffèrent que de manière peu significative. Les tests de performance et de préproduction deviendraient autrement dénués de sens.
En général, ce n'est pas un problème si les environnements utilisés pour le développement et les tests fonctionnels diffèrent des autres environnements du point de vue non fonctionnel.
Comme illustré dans le schéma suivant, les environnements de test et de développement sont basés sur Google Cloud. Une base de données gérée, comme Cloud SQL, peut être utilisée comme option de développement et de test dans Google Cloud. Le développement et les tests peuvent utiliser le même moteur et la même version de base de données dans l'environnement sur site, un moteur et une version équivalents du point de vue fonctionnel, ou une nouvelle version déployée dans l'environnement de production après la phase de test. Toutefois, étant donné que l'infrastructure sous-jacente des deux environnements n'est pas identique, cette approche de test de charge de performance n'est pas valide.
Les scénarios suivants peuvent s'adapter au modèle hybride d'environnement :
- Parvenez à une équivalence fonctionnelle entre tous les environnements en utilisant Kubernetes en tant que couche d'exécution commune, le cas échéant.
Google Kubernetes Engine (GKE) peut être une technologie clé pour cette approche.
- Assurez la portabilité des charges de travail et éliminez les différences entre les environnements informatiques. Avec un maillage de services Zero Trust, vous pouvez contrôler et maintenir la séparation de communication requise entre les différents environnements.
- Exécutez les environnements de développement et de tests fonctionnels dans le cloud public. Ces environnements sont équivalents aux environnements restants du point de vue fonctionnel, mais peuvent différer les uns des autres sur certains aspects non fonctionnels, tels que les performances. Ce concept est illustré dans le schéma précédent.
- Exécutez les environnements des tests de production, préproduction, performance (test de charge) et fiabilité dans l'environnement informatique privé, en veillant à avoir une équivalence des points de vue fonctionnel et non fonctionnel.
Considérations de conception
- Besoins de l'entreprise : chaque stratégie de déploiement et de lancement pour les applications a ses propres avantages et inconvénients. Pour vous assurer que l'approche que vous sélectionnez correspond à vos exigences spécifiques, basez vos sélections sur une évaluation approfondie de vos besoins et contraintes commerciaux.
- Différences d'environnement : dans le cadre de ce modèle, l'objectif principal de l'utilisation de cet environnement cloud est le développement et les tests. L'état final consiste à héberger l'application testée dans l'environnement sur site privé (production). Pour éviter de développer et de tester une fonctionnalité susceptible d'opérer comme prévu dans l'environnement cloud et d'échouer dans l'environnement de production (sur site), l'équipe technique doit connaître et comprendre les architectures et les fonctionnalités des deux environnements. Cela inclut les dépendances vis-à-vis d'autres applications et de l'infrastructure matérielle, par exemple les systèmes de sécurité qui effectuent l'inspection du trafic.
- Gouvernance : pour contrôler ce que votre entreprise est autorisée à développer dans le cloud et les données qu'elle peut utiliser pour les tests, utilisez un processus d'approbation et de gouvernance. Ce processus peut également aider votre entreprise à s'assurer qu'elle n'utilise pas de fonctionnalités cloud dans ses environnements de développement et de test qui n'existent pas dans son environnement de production sur site.
- Critères de réussite : des critères de réussite des tests clairs, prédéfinis et mesurables doivent être définis et correspondre aux normes d'assurance qualité des logiciels de votre organisation. Appliquez ces normes à toutes les applications que vous développez et testez.
- Redondance : bien que les environnements de développement et de test ne nécessitent peut-être pas autant de fiabilité que l'environnement de production, ils ont toujours besoin de capacités redondantes et de la possibilité de tester différents scénarios d'échec. Vos exigences en matière de scénarios d'échec peuvent vous inciter à inclure la redondance dans votre environnement de développement et de test.
Avantages
L'exécution de charges de travail de développement et de tests fonctionnels dans le cloud public présente plusieurs avantages :
- Vous pouvez démarrer et arrêter automatiquement des environnements selon vos besoins.
Par exemple, vous pouvez configurer un environnement complet pour chaque requête commit ou pull, autoriser l'exécution des tests, puis le détruire. Cette approche offre également les avantages suivants :
- Vous pouvez réduire vos coûts en arrêtant les instances de machine virtuelle (VM) lorsqu'elles sont inactives ou en ne provisionnant des environnements qu'à la demande.
- Vous pouvez accélérer le développement et les tests en démarrant des environnements éphémères pour chaque requête pull. Cela réduit également les coûts de maintenance et les incohérences dans l'environnement de compilation.
- En exécutant ces environnements dans le cloud public, vous pourrez vous familiariser avec le cloud et les outils associés, et les utiliser avec une confiance accrue, ce qui pourrait faciliter la migration d'autres charges de travail. Cette approche est particulièrement utile si vous décidez d'explorer la portabilité de charge de travail à l'aide de conteneurs et de Kubernetes (par exemple, en utilisant GKE dans les environnements).
Bonnes pratiques
Pour mettre correctement en œuvre le modèle d'architecture hybride d'environnement, tenez compte des recommandations suivantes :
- Définissez les exigences de communication de votre application, y compris la conception optimale du réseau et de la sécurité. Utilisez ensuite le modèle de réseau en miroir pour vous aider à concevoir votre architecture réseau afin d'empêcher les communications directes entre les systèmes de différents environnements. Si une communication est requise entre les environnements, elle doit être contrôlée.
La stratégie de déploiement et de test d'application que vous choisissez doit correspondre à vos objectifs et exigences commerciaux. Cela peut impliquer de déployer des modifications sans temps d'arrêt ou d'implémenter progressivement des fonctionnalités dans un environnement ou un groupe d'utilisateurs spécifique avant une publication plus large.
Pour rendre les charges de travail portables et éliminer les différences entre les environnements, vous pouvez utiliser des conteneurs avec Kubernetes. Pour en savoir plus, consultez l'architecture de référence de l'environnement hybride GKE.
Mettez en place une chaîne d'outils commune qui fonctionne dans plusieurs environnements informatiques pour déployer, configurer et utiliser des charges de travail. L'utilisation de Kubernetes vous offre cette cohérence.
Assurez-vous que les processus CI/CD sont cohérents dans tous les environnements informatiques et que le même ensemble de fichiers binaires, de paquets ou de conteneurs est déployé dans ces environnements.
Avec Kubernetes, utilisez un système de CI tel que Tekton pour mettre en œuvre un pipeline de déploiement qui se déploie sur des clusters et fonctionne dans différents environnements. Pour en savoir plus, consultez la page sur les solutions DevOps sur Google Cloud.
Pour vous aider à publier en continu des applications sécurisées et fiables, incorporez la sécurité en tant que partie intégrante du ptocessus DevOps (DevSecOps). Pour en savoir plus, consultez la page Déployer et sécuriser votre application accessible sur Internet en moins d'une heure à l'aide du kit d'outils Dev(Sec)Ops.
Utilisez les mêmes outils pour la journalisation et la surveillance dans Google Cloud et les environnements cloud existants. Envisagez d'utiliser des systèmes de surveillance Open Source. Pour en savoir plus, consultez la page Modèles de surveillance et de journalisation hybrides et multicloud.
Si différentes équipes gèrent les charges de travail de test et de production, il peut être acceptable dans ce cas d'utiliser des outils distincts. Toutefois, l'utilisation des mêmes outils avec des autorisations d'affichage différentes peut vous aider à réduire les efforts et la complexité de la formation.
Lorsque vous choisissez des services de base de données, de stockage et de messagerie pour les tests fonctionnels , utilisez des produits ayant un équivalent géré sur Google Cloud. Le recours à des services gérés permet de réduire les tâches administratives liées à la maintenance des environnements de développement et de test.
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é, différentes options sont disponibles en fonction de la solution de connectivité hybride sélectionnée. Ces options incluent les tunnels VPN, VPN haute disponibilité via Cloud Interconnect et MACsec pour Cloud Interconnect.
Le tableau suivant indique les Google Cloud produits compatibles avec les produits OSS courants.
| Produit OSS | Compatible avec le Google Cloud produit |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Managed Service pour Apache Spark |
| MySQL, PostgreSQL | Cloud SQL |
| Redis Cluster, Redis, Memcached | Memorystore |
| Système de fichiers réseau (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE |