Cloud hybride et multi-cloud

Deux problèmes, deux solutions différentes

Une banque régionale garde son registre central sur un mainframe dans son propre centre de données, parce que déplacer 40 ans d'historique de transactions et une piste d'audit exigée par un régulateur strict ne se fait pas à la légère. Mais la banque veut aussi que sa nouvelle application mobile tourne sur une infrastructure capable d'absorber un pic de trafic des fêtes sans acheter des serveurs utilisés 3 jours par an. C'est un premier problème : connecter une infrastructure qu'on ne peut pas quitter à une infrastructure qu'on veut ajouter.

Une autre entreprise, une application sociale en forte croissance, s'est déjà engagée sur un contrat pluriannuel de plusieurs milliards de dollars avec un seul fournisseur cloud, et voit ce contrat unique dominer son budget d'infrastructure. Perdre son pouvoir de négociation, et se retrouver à un litige contractuel d'une renégociation douloureuse, est un problème différent : dépendre d'un seul fournisseur pour tout.

Les modèles de déploiement de la leçon précédente ne nomment aucune des 2 solutions à eux seuls. Le cloud hybride et le multi-cloud sont ce que les organisations construisent quand le cloud public, privé et communautaire résolvent chacun une partie du problème, sans qu'aucun ne le résolve en entier.

Cloud hybride : 2 infrastructures, reliées entre elles

Le NIST définit un cloud hybride comme une composition de 2 infrastructures cloud distinctes ou plus, privée, communautaire ou publique, qui restent des entités uniques, mais sont reliées par une technologie standardisée ou propriétaire qui permet la portabilité des données et des applications. Lisez cette définition attentivement : les éléments restent séparés. Le mainframe de la banque ne devient pas une partie d'AWS, et AWS ne devient pas une partie du centre de données de la banque. Ce qui les relie est une couche, construite spécifiquement pour déplacer données et charges de travail entre les deux, qui rend la frontière aussi invisible que possible pour les personnes qui l'utilisent.

Cette couche de connexion est une véritable catégorie de produits, et plusieurs fournisseurs vendent exactement cela. AWS Outposts étend le matériel, les API et les services AWS jusque dans le centre de données propre d'une entreprise, pour qu'une équipe utilise les mêmes outils sur site et dans le cloud public sans apprendre 2 plateformes différentes. Azure Arc et Azure Stack HCI de Microsoft font l'équivalent pour Azure : gérer des serveurs sur site, des clusters Kubernetes et des bases de données comme s'il s'agissait de ressources Azure, quel que soit leur emplacement physique. Dans les deux cas, l'objectif est la portabilité, déplacer une application ou un jeu de données à travers la frontière sans le reconstruire.

Retour à la banque : le registre reste sur le mainframe qu'elle ne peut pas déplacer, et l'application mobile tourne dans le cloud public où elle peut absorber un pic de trafic du jour au lendemain. Le cloud hybride est ce qui permet aux 2 moitiés de fonctionner comme un seul système plutôt que 2 systèmes sans rapport, en partageant l'identité, la supervision, et parfois les données, à travers la frontière qui les sépare.

Multi-cloud : plus d'un fournisseur public

Le multi-cloud signifie quelque chose de plus étroit que ce que son nom suggère : utiliser des services de cloud public d'au moins 2 fournisseurs séparés, AWS et Google Cloud par exemple, plutôt que de tout confier à un seul. La propre définition de Google Cloud reste simple : une organisation utilise des services de cloud computing d'au moins 2 fournisseurs publics pour faire tourner ses applications.

L'application sociale du début est un cas réel, pas une hypothèse. Snap Inc, l'entreprise derrière Snapchat, s'est engagée à dépenser au moins 2 milliards de dollars chez Google Cloud sur 5 ans à partir de 2017, un contrat si important que le dossier d'introduction en bourse de Snap l'a lui-même désigné comme un risque financier majeur. La réponse de Snap a été d'ajouter un second engagement, séparé : au moins 1 milliard de dollars chez AWS d'ici fin 2021, pour ce que son dossier appelait un soutien d'infrastructure redondant. L'infrastructure de Snap fonctionne aujourd'hui sous forme de microservices répartis entre les 2 fournisseurs, si bien qu'aucun fournisseur ne peut à lui seul dicter les prix, subir une panne, ou imposer les termes d'un renouvellement de contrat.

La dépendance à un fournisseur est la principale raison qui pousse les organisations vers le multi-cloud, mais ce n'est pas la seule. Certains services sont réellement plus solides chez un fournisseur, donc une équipe peut faire tourner son entrepôt de données chez un fournisseur et son pipeline de machine learning chez un autre pour profiter de l'offre la plus forte de chacun. Les règles de résidence des données de certains pays exigent que certaines données restent à l'intérieur des frontières du pays, et la région la plus rapide d'un fournisseur là-bas n'est pas toujours celle que l'entreprise utilise déjà partout ailleurs.

La frontière : hybride ou multi-cloud, et pourquoi "les deux" est fréquent

Le cloud hybride et le multi-cloud répondent à des questions différentes, et un scénario n'en teste généralement qu'une à la fois.

Une entreprise peut être les 2 à la fois, et l'est de plus en plus. Imaginez à nouveau un réseau hospitalier : les dossiers patients restent sur du matériel privé sur site pour des raisons de conformité, la moitié hybride, tandis que son système de facturation tourne sur AWS et son service de télémédecine vidéo tourne sur un fournisseur différent choisi pour une latence plus faible dans certaines régions, la moitié multi-cloud. Rien dans les définitions n'oblige une entreprise à choisir un seul camp.

Un piège à nommer directement : faire tourner des charges de travail dans 2 régions différentes du même fournisseur, 2 régions AWS par exemple, n'est pas du multi-cloud. Le multi-cloud signifie précisément des fournisseurs séparés. Faire tourner des charges de travail dans plusieurs régions d'un même fournisseur est une technique de résilience à l'intérieur d'un seul cloud, un concept différent couvert plus loin dans ce cours.

Une seconde méprise : le multi-cloud ne garantit pas automatiquement qu'une application survit à la panne d'un fournisseur. Répartir des charges de travail sans rapport entre 2 fournisseurs, l'application d'une équipe sur AWS, l'application d'une autre équipe sur Azure, réduit le risque contractuel et tarifaire, mais si une seule application ne tourne que chez l'un de ces fournisseurs, cette application tombe quand même en panne quand ce fournisseur tombe en panne. Une véritable résilience multi-fournisseurs suppose de concevoir activement une charge de travail pour tourner sur plusieurs clouds à la fois, ce qui est plus difficile et plus rare que ne le suggèrent les chiffres d'adoption du multi-cloud.

Ce que vous emportez avec vous

Posez 2 questions, pas une seule, avant d'étiqueter une configuration. Inclut-elle une partie privée ou sur site connectée à un cloud public ? Si oui, c'est la moitié hybride. Implique-t-elle plus d'un fournisseur public séparé ? Si oui, c'est la moitié multi-cloud. Une configuration peut répondre oui aux 2, à une seule, ou à aucune, et l'étiquette ne compte que parce qu'elle révèle le problème que l'organisation cherchait réellement à résoudre : garder ce qu'elle ne peut pas déplacer, ou refuser de dépendre de quelqu'un dont elle peut se passer. Le prochain sujet laisse les modèles de déploiement de côté et aborde la question à laquelle chacun de ces choix finit par se heurter : ce que ça coûte réellement.