J’ai déjà eu plusieurs fois des discussions sur le Cloud et le lock-in, mais c’est surtout l’annonce de Gaia-X qui m’a donné envie d’écrire cet article.
Avant de commencer, il faut énoncer une chose: ce qu’est vraiment Gaia-X n’est clair pour personne. Après m’être documenté et assisté à un talk sur le sujet, voici ce que j’ai cru comprendre.

Gaia-X serait donc un produit créé par un consortium d’entreprise (quelques Cloud providers, entreprises "clientes" de Cloud…​) dont l’objectif serait d’interfacer les Cloud entre eux dans le but de créer un "meta Cloud" européen. Il n’y a pas vraiment d’autres informations sur le sujet, les articles de la presse généraliste et technique ne faisant que répéter la communication officielle (qui elle même ne veut pas dire grand chose).

Pour l’instant, la seule fonctionnalité présentée de Gaia-X est un catalogue. L’utilisateur pourra rechercher dans ce catalogue des produits Cloud en fonction de différents critères, comme "Je veux un Cloud hébergé en France, je veux pouvoir faire du S3…​" ou des choses comme ça. Bref, c’est la version Cloud Native de la Redoute.

Mais qui va sincèrement choisir son Cloud Provider (et donc l’architecture de son projet) sur catalogue ? La documentation, la qualité et cohérence des produits proposés, la qualité du support, le tooling disponible, la facilité d’utilisation, le prix…​ sont autant de facteurs qui vont influer le choix, bien plus que des résultats de recherches répondants à des critères simples.
Je vois déjà les managers arriver un matin en disant "bon, on utilisera maintenant Tartempion pour nos projets, j’ai mis les critères de l’appel d’offre dans la moulinette et c’était la première réponse".

Ca parle aussi de certifications Gaia-X, donc peut être qu’on peut s’attendre à des appels d’offres demandant le tampon Gaia-X, comme pour les certifications ISO actuellement (histoire de rajouter un peu de bureaucratie).

Le but à terme serait aussi d’interconnecter les Cloud pour pouvoir passer facilement d’un Cloud à l’autre. Comment ? On ne sait pas. Une API commune peut être ?

En conclusion, peu d’informations pour l’instant. Mais la volonté d’interconnecter les Clouds semble là. Mais même sans parler de Gaia-X, est ce vraiment utile et possible ?

On pourrait se dire "ce serait quand même plus simple si tout le monde fournissait le même produit". Je ne crois pas du tout à cette approche. Je m’explique.

Il y a déjà un certain nombre de Cloud existants sur le marché. D’ailleurs, le mot Cloud veut tout et rien dire. On parle de quoi là ? De IaaS ? de PaaS ? De Cloud fournissant des services spécifiques (comme le Cloud InfluxDB, Sentry, Datadog…​) ? Est-il possible de faire rentrer des produits aussi différents dans le même catalogue, et surtout vouloir construire quelque chose permettant de passer de l’un à l’autre sans aucun effort ?

Prenons le monde de l’IaaS, que je connais bien. On retrouve entre les différents Cloud des produits qui de prime abord semblent assez proches: machines virtuelles, réseaux privés, load balancers, IP "Elastiques" ou "Flottantes" selon les Cloud …​ Mais le diable se cache dans les détails.

Quand on parle d’un load balancer, on parle de quoi ? Un load balancer TCP, UDP, HTTP ? Qui fait terminaison ou non ? Qui supporte le proxy protocol ? Et les healthchecks, on les définit comment ? Comment le load balancer détecte-il les machines backends, faut-il les ajouter une par une, il y a t-il la notion de groupes de machines ? Je pourrai continuer comme ça pendant longtemps, et faire cela sur tous les produits.

Chaque Cloud Provider a fait, et va faire des choix. En fonction de son existant (en effet, un Cloud ce n’est pas selon moi des produits sans cohérences entre eux, généralement on construit sur les produits précédents), de ses compétences en interne, des outils choisis pour réaliser telle tâche, voir du matériel physique utilisé.
Si demain on décidait de définir une API commune à tout le monde, on choisit quoi ? Celle du plus gros Cloud Provider, et les autres réimplémentent leurs produits ? Ou bien on construit une API géante, supportant tous les produits de tout le monde, avec toutes les variations possible, mais qui sera de ce fait une usine à gaz inutilisable ?

J’ai aussi déjà eu des discussions où l’on me disait "ce serait bien que tout le monde soit sur Openstack, au moins on passerait facilement d’un Cloud à un autre". C’est selon moi le meilleur moyen de tuer l’innovation.

Imaginons que vous êtes CTO d’un Cloud tournant sur Openstack (ou autre produit de plateforme Cloud, ce n’est pas important). Déjà, il faut savoir que vous n’utiliserez probablement qu’une petite partie du code du produit (vu que c’est un produit très générique fait pour tourner dans pleins de contextes), et que vous aurez probablement à maintenir un fork interne à vie car vous aurez forcément des problèmes spécifique.
Vos clients utilisent donc le tooling Openstack (Terraform, Ansible…​) pour déployer de l’infrastructure chez vous.

Mais vous avez maintenant une super idée de produit ! Vous allez rajouter rajouter de nouveaux endpoints dans l’API, et pourquoi pas modifier un peu l’API des machines virtuelles pour rajouter plus d’options.
Mais il se pose maintenant un problème: vous n’êtes dorénavant plus un Cloud proposant de l’Openstack, mais un Openstack légèrement modifié. Vous n’êtes plus compatible avec le tooling (et les mainteneurs refusent de faire une exception pour vous).

On parle beaucoup de vendor lock-in, dans le sens "l’entreprise proposant un service verrouille le client". Mais attention à l’effet inverse où c’est l’entreprise qui se fait lock-in. Et c’est le risque de notre meta-Cloud européen.

Maîtriser à 100 % sa stack technique est ce qui permet selon moi de développer des produits de qualité rapidement.

Le vendor lock-in existe-il ? Oui.

Quand vous déployez votre infrastructure ou applications chez un Cloud A, il faudra un peu de travail pour passer sur le Cloud B. Selon les Cloud ça peut se faire assez bien, parfois ça peut être compliqué.

Par exemple, migrer des machines virtuelles d’un Cloud à un autre, ce n’est selon moi pas compliqué. La plupart des Cloud permettent d’ailleurs de pousser vos propres images de machines virtuelles, donc il est facile d’utiliser la même image de base sur de nombreux Cloud.

Par contre, si vous utilisez des services très spécifiques d’AWS, Google Cloud ou autre (base de données présentes que chez eux par exemple), là ça peut être un peu plus compliqué. Mais ce n’est pas la faute du Cloud Provider, qui est selon moi tout à fait en droit de proposer un service non présent chez la concurrence. C’est de la votre.

Il y a des moments dans la vie d’un projet où il faut faire des choix. Des choix de technologies, de langages, d’hébergement. Ces choix auront une conséquence sur l’avenir du projet.
Vous pouvez partir "all-in" sur un Cloud, utiliser tous ses services dont ceux pouvant éventuellement vous verrouiller, ou bien n’utiliser qu’une partie des services, ou bien partir sur plusieurs Cloud différents dès le début…​
Vous pouvez essayer de concevoir vos applications pour être indépendantes de la plateforme d’exécution, et qu’elles puissent être déployées dans différents contextes (PaaS, machines virtuelles, Kubernetes …​), ou bien utiliser des produits qui vous feront peut être gagner du temps mais vous enfermeront dans un écosystème.

Il n’y a pas un bon choix et un mauvais choix, c’est des choix que vous devez faire selon votre contexte et dont vous serez responsable. A vous de définir votre limite dans le lock-in et de choisir en conséquence. Choix qui, soit dit en passant, demandent de bonnes connaissances pour juger les pour et les contre, et c’est peut être ça qui manque un peu dans certaines entreprises, surtout si la personne qui prend la décision ne fait que prendre le Cloud proposé par la SSII du coin.

Est-ce une raison pour se passer totalement de standards ? Non.

Il y a déjà des protocoles standards qu’on utilise tous les jours. A nous de construire sur ces standards. Des standards pour communiquer avec des bus de messages, des standards pour le format d’une métrique, ou bien des standards pour décrire une API tout en pouvant générer des clients et de la documentation, des standards décrivant des langages de requêtage de base de données…​
Construisez vos applications sur ces standards, et ne vous enfermez pas sur des technologies propriétaires. Demandez vous toujours quelle serait la difficulté de redéployer vos applications sur un autre Cloud Provider, ou de passer d’un produit fournit par le Cloud à un produit hébergé en interne. C’est de cette façon que vous éviterez le lock-in.

Est ce que créer le CORBA du Cloud européen permettra de concurrencer les GAFAM sur ce domaine ? Je ne pense pas.

Il est vrai que les Cloud américains fournissent généralement plus de produits que les Cloud européens, mais je pense que le retard s’amenuise peu à peu, surtout si l’on compare les moyens disponibles de chaque côté.
Je pense que tous les acteurs européens ne demandent qu’à faire leurs preuves. Que des entreprises partent sur des produits américains, très bien, je n’aime pas d’ailleurs le marketing visant presque à culpabiliser les gens allant sur des GAFAM. Être européen ne fait pas tout, et non les clients ne font pas utiliser un produit mal ficelé juste par ce qu’il est européen.

Mais je pense qu’aujourd’hui on trouve des produits et entreprises de qualité en Europe, et qui n’ont selon moi pas que ça à faire que de participer à des consortium aux objectifs peu clairs. Et ces acteurs ne demandent qu’une chose: qu’on leur laisse leur chance.
Testez ces plateformes, faites des retours, dites ce qui va et ce qui ne va pas. Essayez de pousser les décideurs à investiguer d’autres choix que les GAFAM sélectionnés par défaut. C’est comme cela qu’un écosystème européen se construira.