Réussir le multicloud, c'est adapter son architecture aux exigences propres à votre portefeuille de workloads applicatifs. Découvrez les modèles de déploiement distribués et redondants pour y parvenir.
Réussir votre multicloud grâce au bon modèle de déploiement
Une stratégie multicloud bien pensée aide les entreprises à atteindre leurs objectifs métier. Mais se repérer dans le multicloud exige une approche architecturale fine pour assurer la cohésion entre les différents services cloud. Vous devez adapter votre architecture aux exigences propres à votre portefeuille de workloads applicatifs ; heureusement, quelques modèles éprouvés peuvent vous y aider.
Ces modèles reposent soit sur un déploiement distribué, soit sur un déploiement redondant :
- Les modèles de déploiement distribués exécutent les applications dans l'environnement informatique le plus adapté, en tirant parti des propriétés et caractéristiques spécifiques de chacun.
- Les modèles de déploiement redondants consistent à déployer les mêmes applications dans plusieurs environnements informatiques afin d'augmenter la capacité ou la résilience.
Modèles de déploiement distribués
Les modèles distribués cherchent l'équilibre entre la gestion des contraintes héritées des applications existantes et l'exploitation du potentiel propre à chaque environnement informatique. Pour choisir le bon modèle, vous devez prendre en compte des facteurs tels que l'agilité, le potentiel d'évolutivité, la sécurité et la fiabilité.
Hybride en couches
Avec un modèle de déploiement hybride en couches, vous déployez d'abord les applications frontend existantes vers le cloud public, au cas par cas, et vous réutilisez les applications backend existantes, qui restent dans leur environnement informatique privé. Vous finirez peut-être toutefois par migrer aussi les backends vers le cloud public, car la part des applications déployées dans le cloud augmentera avec le temps.
Donner la priorité aux applications frontend a du sens : les frontends dépendent des backends, mais l'inverse n'est pas vrai. Avec peu de dépendances, les frontends sont en général plus faciles à isoler et à migrer que les backends. Les déployer dans le cloud public est pertinent : ils évoluent plus souvent que les backends et tireront parti de la flexibilité du cloud. Le cloud simplifie la mise en place d'un processus d'intégration continue/déploiement continu (CI/CD) pour des mises à jour automatisées et efficaces, et des fonctionnalités telles que l'équilibrage de charge, les déploiements multirégionaux et l'autoscaling améliorent les performances.
Pour les backends qui gèrent des données soumises à des exigences de conformité strictes, les conserver dans un environnement informatique privé peut être une décision avisée. De nombreux pays imposent la localisation des données, ce qui oblige les entreprises à les stocker et les traiter localement. Le Règlement général sur la protection des données (RGPD) de l'UE, par exemple, comporte des dispositions strictes sur le stockage des données personnelles, qu'une solution on-premises permet souvent de mieux respecter.
Multicloud partitionné
Le modèle multicloud partitionné vous permet de déplacer des workloads entre les environnements de cloud public de différents fournisseurs. La portabilité des workloads est essentielle pour disposer de la flexibilité nécessaire au déploiement des applications dans l'environnement le plus adapté. Vous devrez abstraire les différences entre environnements afin de pouvoir déplacer vos workloads de l'un à l'autre.
Les modèles multicloud partitionnés vous évitent le verrouillage fournisseur, puisque vous n'êtes pas lié à un seul prestataire cloud. La possibilité de basculer les workloads vers un autre environnement selon les besoins protège du risque d'indisponibilité en cas de panne, et permet de retenir les fonctionnalités les plus pertinentes chez chaque fournisseur.
Maintenir cette portabilité vous permet aussi d'optimiser vos opérations à mesure que vous déplacez les workloads d'un environnement à l'autre. Elle a toutefois ses limites : elle exige un travail supplémentaire de développement, de test et d'exploitation. Concevoir pour la portabilité peut aussi réduire l'utilité de la plateforme cloud retenue à son plus petit dénominateur commun, et empêcher les workloads de tirer parti des services entièrement managés du fournisseur. Les coûts d'egress peuvent également vite s'envoler.
La conteneurisation facilite la portabilité des workloads, et Kubernetes va plus loin en aidant les entreprises à éviter le verrouillage fournisseur.
Hybride et multicloud pour l'analytique et le ML
Avec ce modèle, les systèmes transactionnels restent on-premises, tandis que les workloads analytiques sont déployés dans le cloud et renvoient les données si besoin. Les systèmes transactionnels assurent les opérations quotidiennes pour des fonctions telles que la finance, la communication ou les ventes. Les workloads analytiques regroupent les applications qui traitent ou visualisent les données pour générer des insights utiles à la prise de décision. Ce modèle exploite la séparation entre ces systèmes pour exécuter chaque type de workload dans un environnement distinct.
En exécutant les workloads analytiques dans le cloud, vous pouvez faire évoluer dynamiquement les ressources de calcul pour traiter rapidement de gros volumes de données, sans risque de surprovisionnement. Les principaux fournisseurs cloud proposent par ailleurs des services complets pour gérer les données, de leur acquisition jusqu'à la fin de leur cycle de vie.
Hybride en périphérie (edge)
Une connectivité continue est indispensable pour exécuter des workloads dans le cloud, mais elle n'est pas toujours envisageable. Des sites tels que les navires, les supermarchés ou certaines usines ne disposent pas toujours d'un accès Internet fiable, alors qu'ils constituent des terrains clés pour l'Internet des Objets (IoT), où les capteurs et puces embarqués ont besoin de connectivité pour transmettre et recevoir des données précieuses. C'est là qu'intervient le modèle hybride en périphérie : il exécute localement, en bordure du réseau, les workloads critiques pour le délai et l'activité, et confie tous les autres au cloud.
Exécuter localement les workloads critiques favorise une faible latence et l'autonomie. Les transactions importantes peuvent ainsi se poursuivre, même quand la connectivité Internet fait défaut. Avec ce modèle, vous profitez tout de même du cloud pour une part importante de vos workloads. Pour qu'il fonctionne efficacement, il est essentiel de minimiser les dépendances entre les systèmes exécutés en périphérie et ceux exécutés dans l'environnement cloud.
Modèles de déploiement redondants
Les modèles de déploiement redondants consistent à déployer les mêmes applications dans plusieurs environnements informatiques afin d'augmenter la capacité ou la résilience.
Environnement hybride
Un modèle d'environnement hybride peut être redondant ou distribué. Il s'appuie sur les environnements de cloud public pour le développement, les tests et l'UAT, tout en exécutant les workloads de production dans des centres de données privés. Les contraintes réglementaires et de conformité peuvent compliquer la migration des environnements de production et de leurs données vers le cloud, sans pour autant freiner celle des autres environnements.
Utiliser le cloud public pour le développement et les tests fonctionnels permet de provisionner et de démanteler les environnements à la demande. Vous pouvez aussi maîtriser les coûts en arrêtant les instances de machines virtuelles inutilisées ou en ne provisionnant des environnements qu'en cas de besoin.
Continuité d'activité hybride et multicloud
La planification de la reprise après sinistre (Disaster Recovery, DR) est indispensable pour rétablir les systèmes compromis par des catastrophes naturelles ou d'origine humaine. Un élément clé consiste à effectuer fréquemment des sauvegardes de données dans différentes zones géographiques afin de minimiser le point de reprise (RPO). Maintenir des systèmes de secours (cold, warm ou hot, selon leur latence) sur un second site contribue également à réduire le délai de reprise (RTO).
Une approche plus économique consiste toutefois à utiliser le cloud public comme environnement de DR : c'est tout l'intérêt du modèle hybride de continuité d'activité. Ce modèle peut même raccourcir le délai de reprise réel en cas de déclenchement de la DR, puisque l'environnement de DR peut être instancié plus rapidement grâce à l'infrastructure as code.
Cloud bursting
Gérer des workloads en pics dans des environnements on-premises peut vite faire dériver les coûts, car il faut surprovisionner les ressources pour absorber les périodes de forte intensité. Le modèle de déploiement par bursting s'appuie sur un environnement informatique privé pour les charges de base et ne déborde vers le cloud qu'au moment de monter en charge. Pour cette raison, il convient mieux aux workloads par lots qu'aux workloads interactifs. La portabilité des workloads y est essentielle.
L'un de ses principaux avantages est de permettre de réutiliser vos investissements actuels dans les environnements on-premises. Vous pourriez même mieux exploiter vos environnements informatiques privés, puisque vous n'avez plus à surprovisionner les ressources pour absorber les pics de demande.
Et après ?
Construire une solution hybride ou multicloud implique des décisions complexes, à commencer par la conception de l'architecture adaptée. Vous devrez évaluer la culture de votre entreprise, vos pratiques DevOps et votre stack technique avant de trancher. Aucune solution technologique unique ne répondra à vos exigences spécifiques, mais la réponse réside sans doute dans une déclinaison des modèles de déploiement distribués et redondants évoqués ici. Un partenaire cloud expert saura vous orienter vers la meilleure approche pour mettre le multicloud au service de vos objectifs métier.