Comment l'association du multicloud et de l'open source vous permet de tirer parti des points forts de votre fournisseur actuel tout en profitant de la flexibilité promise par le cloud public.
L'open source, un atout pour exploiter pleinement la flexibilité du cloud
L'un des grands attraits du cloud tient à sa promesse de flexibilité quasi illimitée. Pourtant, si l'on ne peut pas changer aisément de fournisseur sans s'exposer à des coûts élevés, à des complications juridiques ou à des incompatibilités techniques, cette flexibilité s'en trouve sérieusement compromise.
Recourir à plusieurs fournisseurs cloud peut sembler une solution évidente, mais ce n'est pas si simple. Nous abordons ici la question du vendor lock-in pour les clients du cloud, expliquons pourquoi le multicloud ne suffit pas à lui seul à résoudre le problème et en quoi l'open source peut faire la différence.
Comment le vendor lock-in se manifeste dans le cloud
Si votre technologie n'est disponible que chez un seul fournisseur et que vous ne pouvez continuer à l'utiliser sans lui verser des frais de licence ou de maintenance, vous êtes en situation de vendor lock-in. Le passage au cloud devrait vous affranchir de ce type de contrainte, puisque vous êtes en grande partie libre de l'exploiter à vos propres conditions. Tous les grands fournisseurs cloud proposent par exemple une tarification à l'usage : en théorie, vous pouvez arrêter votre environnement, exporter vos données et vos machines virtuelles, et partir quand bon vous semble.
Par ailleurs, les services cloud sont généralement conçus pour faciliter la migration des données, dans les deux sens. Les fournisseurs ont mis au point des services et des outils pour vous aider à migrer vos bases de données et les applications qui les exploitent, aussi bien vers le cloud qu'entre différents clouds.
Changer de fournisseur dans le cloud reste pourtant loin d'être trivial. Prenons l'exemple du transfert de données : migrer des données entre serveurs qui utilisent le même moteur de base de données (migration homogène) est relativement simple. En revanche, un changement aussi mineur qu'un numéro de version peut faire surgir toute une série de problèmes à régler avant de basculer vers un autre moteur (migration hétérogène). Cela peut imposer une approche et une application entièrement différentes.
Il faut également tenir compte des applications conçues pour tirer parti des spécificités de votre fournisseur actuel. Reconfigurer une telle application pour qu'elle s'exécute nativement sur un autre cloud est une opération complexe. Et c'est là le cœur du problème : chaque fournisseur procède à sa manière, si bien que passer de l'un à l'autre représentera toujours un certain défi, sans parler du déficit de connaissances de votre équipe sur les technologies et les approches du nouveau fournisseur.
Pourquoi le multicloud ne suffit pas à lui seul
Une approche multicloud réduit votre dépendance à un fournisseur unique, mais ce n'est pas une solution miracle face au vendor lock-in. Faire passer une application ou un workload existant d'un déploiement on-premises à l'infrastructure d'un fournisseur cloud est relativement simple, et l'acheteur reste assez bien protégé contre le vendor lock-in. Lorsque vous payez un fournisseur cloud pour des serveurs, du réseau et du stockage, le coût du transfert de vos machines virtuelles vers un autre fournisseur se résume pour l'essentiel à apprendre une nouvelle API de provisioning.
Ce n'est plus le cas dès qu'on parle de services. Les fournisseurs de cloud public ont tendance à concevoir leurs services autour d'outils de gestion propriétaires qui ne fonctionnent qu'au sein de leur propre écosystème. Pour ne déployer qu'une seule application sur Amazon Web Services (AWS), vous serez par exemple amené à utiliser des services comme Kinesis, DynamoDB, ElastiCache, Simple Queue Services, TimeStream et Lambda — autant de services propriétaires uniquement disponibles chez AWS.
Compte tenu du coût de refactorisation d'une application développée pour une plateforme cloud spécifique afin de la porter vers une autre, déployer des services cloud reposant sur des combinaisons complexes de services propriétaires de haut niveau rend difficile la dissociation entre choix technologique et choix de fournisseur. En théorie, il est possible d'exécuter le même workload dans plusieurs clouds, mais cela revient à se contenter du plus petit dénominateur commun et à sacrifier le potentiel d'innovation qu'offre le cloud public.
Votre stratégie multicloud aura davantage de chances de réussir si vous concevez et construisez chaque application dans le cloud le mieux adapté. Cependant, c'est souvent l'opportunisme plutôt que l'analyse qui dicte le lieu de déploiement d'un workload. Il faut peser les forces relatives de chaque cloud et leur adéquation avec votre cas d'usage métier. Sans données fiables sur la performance d'un workload dans un cloud donné, son affectation tient davantage de la chance que d'une démarche éclairée.
Comment l'open source aide à prévenir le vendor lock-in
Les clients peuvent s'appuyer sur toute une gamme de plateformes et d'outils open source de cloud computing pour réduire leur dépendance aux plateformes propriétaires. L'open source dissocie efficacement le choix technologique du choix de fournisseur cloud. Les développeurs peuvent adapter le code source de ces plateformes et outils à leurs besoins lorsqu'ils déploient, provisionnent et gèrent des workloads et des environnements.
Kubernetes, le système d'orchestration de conteneurs qui automatise le déploiement, la mise à l'échelle et la gestion des logiciels, ainsi que le service mesh Istio, ont été passés en open source par Google, qui s'est imposé comme un acteur de référence et un contributeur majeur de la communauté open source.
De nombreux outils Google Cloud Platform (GCP) reposent ainsi sur des technologies open source, et GCP y ajoute une couche de gestion opérationnelle qui apporte une valeur supplémentaire et permet aux clients d'adopter rapidement la technologie. Google Kubernetes Engine (GKE) et des services comme Dataflow, Cloud Composer, Managed Service for Prometheus et Cloud Data Fusion sont conçus de telle sorte que vous pouvez reprendre la même logique métier et l'exécuter ailleurs en implémentant simplement le nouveau volet opérationnel.
Une plateforme comme Anthos de Google rend possible la modernisation d'applications hybrides multicloud, en vous permettant d'orchestrer et d'exécuter des clusters Kubernetes, voire des VM (en private preview), sur GCP, AWS, Azure, le cloud privé et le bare metal. Même si vous n'utilisez pas Kubernetes comme socle de l'ensemble de votre cloud, il reste utile pour orchestrer une partie des workloads exécutés dans un cloud public.
Pour assurer la pérennité des logiciels open source, les entreprises devraient encourager et inciter leurs collaborateurs à y contribuer. Un récent rapport de la CNCF révèle que 96 % des organisations utilisent désormais Kubernetes, et le nombre d'autres projets open source cloud-native a explosé au cours de l'année écoulée. Les logiciels open source peuvent faciliter une stratégie multicloud efficace et éviter aux entreprises d'être prises en otage par un cloud unique.
Cela étant, s'appuyer massivement sur des services open source implique un compromis : vous êtes responsable des opérations Day 2. Vous devez donc assurer la supervision, les mises à jour et la sécurisation, et tout ce travail supplémentaire risque de ne pas justifier les ressources et les processus additionnels qu'il impose.
Vous devrez également composer avec des mécanismes de support minimaux, le plus souvent sans aucun SLA, et vous retrouver livré à vous-même en cas d'incident en production. Et que se passe-t-il lorsque vous souhaitez ajouter des fonctionnalités à un service clé ? Vos ingénieurs devront dégager du temps pour contribuer à la communauté open source plutôt que d'enrichir les fonctionnalités centrales de votre produit. Comme pour le multicloud, miser uniquement sur l'open source pour éviter le vendor lock-in n'est pas la solution.
Et maintenant ?
Comment exploiter, dès lors, la véritable puissance du cloud sans subir les restrictions qu'un fournisseur pourrait imposer ? Travailler avec un partenaire qui maîtrise en profondeur l'ensemble des grands fournisseurs cloud peut vous aider à bâtir une stratégie qui tire le maximum de valeur métier du fournisseur retenu.
Les équipes DoiT possèdent non seulement une expérience approfondie pour aider les entreprises à tirer parti de plusieurs clouds afin d'atteindre leurs objectifs métier, mais elles ont aussi développé des outils open source qui rationalisent vos opérations cloud, lèvent des verrous techniques complexes et vous aident à réduire votre dépendance aux plateformes propriétaires. Avec la bonne approche, vous pouvez tirer parti des points forts de votre fournisseur actuel tout en profitant de la flexibilité promise par le cloud public.