Vendor lock, le Cloud également

C’est avant tout un peu une règle de bon sens. Il n’est pas raisonnable dans le SI d’entreprise de ne travailler qu’avec un seul fournisseur de matériel. Ou un seul éditeur logiciel ou même un seul partenaire de maintenance. Lorsque je dis que ce n’est pas raisonnable, je ne dis pas que cela n’existe pas… Et on peut décliner sur le Cloud ce qu’il existe On Premises. Il existe de nombreux fournisseurs, quelques acteurs majeurs mais aussi, d’autres, plus confidentiels. Et il est naturel de vouloir répartir ses services entre ces différents acteurs. Evident sur le papier, un peu moins dans la réalisation.

Quelques étapes pour démarrer

Que l’on soit déjà dans le Cloud, que cela soit en cours ou que ce soit un projet de migration, il y a quelques grandes étapes pour démarrer.
Et choisir son fournisseur de Cloud se fait en plusieurs phases. Tout d’abord, le choix se porte sur un partenaire. Parce qu’il faut bien commencer quelque part. Démarrer est tout de même une opération longue, il y a un peu de complexité, et des inquiétudes légitimes s’agissant de quelque chose de très différent, quelque chose de nouveau.

Cela se fera donc presque naturellement chez un seul fournisseur, un peu « pour voir », sans s’engager plus dès le départ (sans démarrer multi cloud).
A court / moyen termes, Cloud ou pas Cloud, se posera inévitablement la question de la dépendance. Il ne faut pas que son SI repose sur un seul partenaire. Pour tout un tas de raisons valables.

Les raisons …

Lorsque l’on se demande vraiment pour quelles raisons d’ailleurs, il y a des réponses qui sont plutôt évidentes.

• Se prémunir contre la défaillance partielle ou totale d’un fournisseur

La défaillance est un terme général qui couvre des sujets tels que la sécurité, l’attaque massive qui paralyserait le datacenter Cloud, à des situations plus classiques comme une fermeture de site ou l’arrêt d’un type de services indispensables au bon fonctionnement de l’entreprise.

• Profiter des tarifs les plus intéressants

Il y a (parfois) des économies importantes à faire. Utiliser SQL sera forcément moins coûteux sur Azure, Microsoft proposant avec les services autour de ce produit une solution maison. Mais il ne faut pas réduire cette question des coûts à ce type d’exemple. Durée d’engagements ou options de paiement sont à prendre en compte.

• Une présence géographique avantageuse pour l’entreprise

Proposer un Datacenter dans une région qui n’est pas couverte par d’autres pour améliorer la qualité est une raison valable pour avoir à s’entourer de plusieurs fournisseurs.

• Donner du poids à ses négociations tarifaires, mettre en concurrence

C’est tout du moins ce que j’entends ici et là. Sans savoir réellement à quel niveau se situent les marges de négociation. J’imagine que c’est un sujet à prendre en compte, je ne sais pas le quantifier.

• Utiliser des services exclusifs à tel ou tel Cloud

Il en reste quelques-uns même si avec le temps, il y a une tendance à l’uniformisation. On trouve de plus en plus de services communs à l’ensemble.

• Spécialiser ses fournisseurs là où ils sont les meilleurs

Un pour le stockage et la base de données par exemple, parce que ce sont des services très performants qui sont offerts. Un autre pour le traitement de la données / IA. Tirer parti des forces de chacun !

• Les besoins réglementaires de normes ou certifications

RGPD, normes ISO, NIST…etc. Tous ne sont pas équivalents et la conformité est un sujet multi Cloud.

De bonnes raisons sans doute, à différents niveaux. Il y en a beaucoup d’autres.

Qu’en est-il dans la réalité ? Que se passe-t-il réellement sur le terrain ? Les entreprises répartissent et « s’attachent » 50 / 50 avec 2 fournisseurs ? 33 / 33 / 33 avec trois ?
Et bien c’est un peu plus compliqué. J’irais même jusqu’à dire que je ne connais pas d’entreprise dans ce cas. Cela existe sûrement, mais ce n’est pas la norme, loin de là. Parce que du souhait à la réalisation, c’est un peu le grand écart.

Le partenaire de départ

Si le Cloud multi fournisseurs est une vraie réalité, l’équilibre est bien différent. Il y a le « Cloudeur historique », celui avec lequel on a démarré, celui avec lequel les premiers déploiements se sont déroulés, auquel on reste assez fortement attaché.

Pour des raisons techniques et relationnelles essentiellement. Il y a, à mon sens, plusieurs explications qui font qu’il est difficile de trop s’écarter de son partenaire de départ.

En voici quelques-unes.

• Les charges de travail existantes sont en place, elles répondent parfaitement aux besoins actuels et les besoins futurs sont couverts par les évolutions apportées par le fournisseur.

A ce sujet, il est toujours plus facile d’organiser sa veille technologique sur un produit ou service connu. Faire évoluer ce qui est déjà en place, c’est une charge beaucoup moins importante que de repartir de zéro. Car d’une part, l’existant rassure, et d’autre part, c’est également un modèle de déploiement pour des besoins à venir. Cerise sur le gâteau, les équipes techniques déploient As code, la solution est industrielle et reproductible.

• Les équipes techniques (toujours) même si elles couvrent différentes technologies ont dans la grande majorité des cas une « préférence », une compétence plus poussée sur un fournisseur.

Même si bien connaître l’un des Cloudeurs, bien comprendre le fonctionnement de ses services ouvre la voie à d’autres fournisseurs, les automatismes sont un peu moins présents lorsque l’on bascule sur une nouvelle technologie. Rien d’insurmontable pour les équipes en place, mais tout de même. Dès qu’il faudra renforcer une équipe avec une expertise plus fine, s’entourer d’une collaboratrice / un collaborateur plus spécialisée/é va forcément être plus compliqué. Le marché de l’expertise est en tension, attirer des expertes/experts pour chaque technologie, voilà une vraie difficulté.

• Les équipes applicatives ont également leur mot à dire.

Principalement parce qu’elles échangent entre-elles et se sentiront rassurées par le fait qu’elles vont être déployées comme la majorité des autres applications. Il faut prendre en compte ce point. Ou alors trouver des équipes qui sont prêtes à tenter l’aventure d’un passage du fournisseur historique vers un nouveau fournisseur.

• Le partenaire, qui, s’il accompagne bien son client va lui proposer / suggérer de continuer à transformer son informatique.

Il va l’accompagner dans cette transformation par le déploiement de nouveaux services. Il connait bien son client et son environnement, il va légitimement étendre les cas d’usages. Il vient avec son expertise, ses retours d’expériences, et sa puissance commerciale. Il accompagne le développement.

• Dernier point qui à mon sens est un point majeur, ce que j’appelle les services liés.

Cette possibilité de faire évoluer sa ressource et de lui ajouter en 1 ou 2 clics tout un tas de services complémentaires qui donnent encore plus de valeur à l’ensemble. Une machine virtuelle IaaS se verra attachée à un service de sauvegarde / restauration, puis à de l’update management, du log avancé et de la gestion automatique des configurations. Tout un éco système extensible et parfaitement intégré ! Et je ne parle ici que d’une ressource IaaS basique. S’écarter du fournisseur qui fournit cette VM pour lui attacher des services d’un autre fournisseur, je ne crois pas que ce soit quelque chose qui se fait. Même si l’arrivée de services de gestion centralisés multi cloud pourraient changer la donne. J‘ai même la conviction que si les choses doivent significativement bouger, cela se fera par ce biais.

Pourtant, il y a de bonnes opportunités à saisir pour mieux répartir ses charges de travail. Aux premiers rangs desquelles les fusions ou acquisitions. C’est dans ces moments que l’on pourrait trouver de belles opportunités. Un parc existant et une équipe existante.

Quelques réflexions

Voilà qui vient gommer un grand nombre des difficultés. Il y aura certainement quelques ajustements à faire, mais sauf à ne pas vouloir conserver ce multi cloud, c’est un moyen « naturel » d’échapper au vendor lock. Et d’introduire le sujet de la gestion centralisée dont il a été question un peu plus haut. C’est une belle ouverture, de belles pistes de travail pour uniformiser ses outils de gestion par exemple.

Il faudra aussi profiter de cet avantage pour … recruter. S’il a été dit plus haut que les équipes techniques avaient une technologie de référence, proposer aux candidats de rejoindre des équipes à l’expertise différente est dans bien des cas un avantage.

Pour terminer, le multi cloud, oui, mais finalement, dans une réflexion générale, une répartition équitable n’est peut-être pas la meilleure des solutions.

Je crois plus au modèle d’un partenaire majeur, un socle majoritaire et des partenaires périphériques choisis pour leur valeur complémentaire. Pas pour mettre en concurrence des services déjà existants, mais plutôt pour explorer des pistes nouvelles.

Un bon point de départ en 3 étapes

• Son fournisseur historique peut être un socle commun pour le service d’information de l’entreprise.

• Plutôt que de chercher à mettre en concurrence des services communs aux différents fournisseurs de Cloud, il serait plus intéressant de venir compléter son offre par des services complémentaires.
• Renforcer ses équipes avec des compétences fines est obligatoire pour accueillir un nouveau Cloudeur.