Avec le modèle d'architecture environnement hybride, vous conservez l'environnement de production d'une charge de travail dans le centre de données existant. Vous utiliserez 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 de ce déploiement est d'améliorer 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 ne s'appliquent peut-être pas à d'autres environnements qui n'utilisent pas les données réelles. Contactez le service de conformité de votre organisation ou l'équipe équivalente.
Le schéma suivant illustre un modèle d'environnement hybride typique.
Le fait de faire fonctionner des systèmes de développement et de test dans des environnements différents de ceux de vos systèmes de production peut sembler risqué et aller à l'encontre des bonnes pratiques existantes ou des tentatives visant à minimiser les différences entre vos 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 Ils sont également appelés "tests de charge".
- Tests de préproduction ou de déploiement : vérifier que la procédure de déploiement fonctionne
- Production : publication d'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 vos procédures de déploiement d'applications fonctionnent comme prévu. Dès lors qu'une version atteint un environnement de préproduction, les tests fonctionnels devraient être terminés. La préproduction est la dernière étape avant le déploiement du logiciel pour 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 créés sur Google Cloud. Une base de données gérée, comme Cloud SQL, peut être utilisée comme option pour le développement et les tests dans Google Cloud. Le développement et les tests peuvent utiliser le même moteur de base de données et la même version dans l'environnement sur site, ceux fonctionnellement équivalents, ou une nouvelle version déployée dans l'environnement de production après la phase de test. Toutefois, comme l'infrastructure sous-jacente des deux environnements n'est pas identique, cette approche des tests de charge de performances n'est pas valide.
Les scénarios suivants peuvent bien s'adapter au modèle d'environnement hybride :
- Parvenez à une équivalence fonctionnelle entre tous les environnements en vous appuyant sur
Kubernetes en tant que couche d'exécution commune, le cas échéant et dans la mesure du possible.
L'édition Enterprise de 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 zéro confiance, vous pouvez contrôler et maintenir la séparation des communications 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 choisissez répond à vos exigences spécifiques, basez vos sélections sur une évaluation approfondie des besoins et des contraintes de votre entreprise.
- 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 privé sur site (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 d'autres applications et de l'infrastructure matérielle (par exemple, les systèmes de sécurité qui effectuent l'inspection du trafic).
- Gestion : 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 dans vos environnements de développement et de test aucune fonctionnalité cloud qui n'existe pas dans votre environnement de production sur site.
- Critères de réussite : les critères de réussite des tests doivent être clairs, prédéfinis et mesurables, et conformes aux normes d'assurance qualité logicielle 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 pas autant de fiabilité que l'environnement de production, ils ont tout de même besoin de fonctionnalités redondantes et de la possibilité de tester différents scénarios de défaillance. Vos exigences de scénario de défaillance peuvent conduire la conception à 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 les coûts en arrêtant les instances de machines virtuelles (VM) lorsqu'elles sont inactives ou en provisionnant des environnements uniquement à la demande.
- Vous pouvez accélérer le développement et les tests en démarrant des environnements éphémères pour chaque demande d'extraction. Cela réduit également les coûts de maintenance et réduit 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 Enterprise 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 de façon à empêcher les communications directes entre les systèmes de différents environnements. Si la 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 être alignée sur vos objectifs et vos exigences commerciaux. Cela peut impliquer le déploiement de modifications sans temps d'arrêt, ou la mise en œuvre progressive de fonctionnalités dans un environnement ou un groupe d'utilisateurs spécifique avant une publication à plus grande échelle. Pour en savoir plus, consultez la page Stratégies de déploiement et de test des applications.
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 Enterprise.
Définissez 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 donnera 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 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 Fournir et sécuriser votre application accessible via Internet en moins d'une heure à l'aide du kit de développement Dev(Sec)Ops.
Utilisez les mêmes outils pour la journalisation et la surveillance dans les environnements Google Cloud et cloud existants. Envisagez d'utiliser des systèmes de surveillance Open Source. Pour en savoir plus, consultez 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 d'utiliser des outils distincts. Toutefois, l'utilisation des mêmes outils avec des autorisations d'affichage différentes peut vous aider à réduire vos efforts de formation et la complexité.
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, HA VPN via Cloud Interconnect et MACsec pour Cloud Interconnect.
Le tableau suivant présente les produits Google Cloud compatibles avec les produits OSS courants.
| Produit OSS | Compatible avec les produits Google Cloud |
|---|---|
| Apache HBase | Bigtable |
| Apache Beam | Dataflow |
| CDAP | Cloud Data Fusion |
| Apache Hadoop | Dataproc |
| MySQL, PostgreSQL | Cloud SQL |
| Redis Cluster, Redis, Memcached | Memorystore |
| Système de fichiers réseau (NFS) | Filestore |
| JMS, Kafka | Pub/Sub |
| Kubernetes | GKE Enterprise |