Chaque pitch de plateforme de gestion cloud hybride commence au même endroit : un schéma avec vos serveurs on-premise à gauche, un cloud public à droite, et une flèche entre les deux étiquetée migration. La flèche, c'est le produit. C'est aussi la raison pour laquelle la plupart de ces projets s'enlisent, parce que la flèche coûte dix-huit mois et que la valeur n'arrive qu'à la fin. La question la plus utile est : que pourriez-vous gérer depuis un seul endroit dès demain, sans rien déplacer et sans rien réécrire ?
L'hybride n'est pas un choix d'architecture que la plupart des équipes ont fait exprès. C'est ce que l'on obtient après dix ans : une baie de matériel maison qui fait encore tourner la chose que personne ne peut facilement déplacer, un ERP que personne ne veut toucher, des workloads chez un hyperscaler parce qu'un client l'a demandé, du compute moins cher quelque part en Europe parce que quelqu'un a fait le calcul, et quelques serveurs en colocation qui datent d'avant la moitié de l'équipe actuelle. Personne n'a conçu ça. Tout le monde doit le faire tourner.
Pourquoi l'hybride signifie généralement deux équipes
Le coût pratique de l'hybride est organisationnel. Les ressources cloud se gèrent dans un navigateur avec des tokens API et des tags ; le parc physique se gère avec SSH, un outil de configuration et la mémoire institutionnelle. Deux chaînes d'outils, deux modèles mentaux, deux jeux de runbooks, et généralement deux groupes de personnes qui décrivent le travail de l'autre comme le côté legacy ou le côté cher. L'inventaire devient une fusion d'exports. La revue d'accès devient deux revues d'accès. Les incidents qui traversent la frontière deviennent une dispute sur qui en est responsable.
La réponse standard des éditeurs est de faire ressembler un côté à l'autre : installer une stack de cloud privé sur votre matériel, ou tout basculer vers le cloud public et en finir. Les deux sont des stratégies légitimes, et les deux sont énormes. Elles partagent aussi une hypothèse qui mérite d'être remise en question - que l'unification doit se produire au niveau de la couche infrastructure. Ce n'est pas le cas. L'essentiel de ce qu'une équipe a réellement besoin d'unifier vit un étage au-dessus : inventaire, accès, historique des changements, coût, et la capacité d'agir.
Ce qu'une plateforme de gestion cloud hybride ne doit pas faire
Une plateforme de gestion cloud hybride mérite sa place par ce qu'elle refuse d'exiger. Elle ne doit pas exiger que vous déplaciez un workload avant de devenir utile. Elle ne doit pas exiger un agent sur chaque machine pour vous montrer votre parc cloud, ni un compte cloud pour vous montrer vos baies. Elle ne doit pas devenir une nouvelle dépendance sur votre chemin critique - si elle tombe, vos systèmes continuent de tourner et vous perdez de la visibilité, pas de la disponibilité. Et elle ne doit pas prendre votre infrastructure en otage dans son propre format.
C'est pourquoi nous avons construit Sencai en mode import-first. Vous connectez un compte fournisseur avec des credentials scopés, et vos instances, réseaux et stockages existants apparaissent tels qu'ils sont, pas comme des choses à recréer. Personne qui évalue une plateforme d'infrastructure n'a une infrastructure vide, et un produit qui ne montre sa valeur qu'une fois que vous avez reconstruit quelque chose à l'intérieur a organisé l'échec de sa propre démo. La première session devrait vous montrer votre parc, y compris les parties que vous aviez discrètement oubliées.
Partez de ce qui existe déjà
Côté cloud, cela signifie onze fournisseurs derrière une seule interface : Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode d'Akamai et Oracle Cloud. Pas une abstraction au plus petit dénominateur commun qui masque tout ce qui est intéressant - les réseaux, les règles de pare-feu et les enregistrements DNS sont créés et modifiés directement chez le fournisseur, donc ce que vous voyez est ce que le fournisseur a réellement, et tout ce que vous configurez continue de fonctionner si vous arrêtez de nous utiliser demain matin.
Côté physique, un agent hôte fait entrer vos propres serveurs dans le même inventaire : une machine dans votre propre baie, dans une cage de colocation, ou une machine chez un fournisseur avec lequel nous n'intégrons pas directement. Il se place aux côtés des ressources cloud plutôt que dans une section séparée, parce que tout l'enjeu est que « qu'est-ce qu'on fait tourner » ait une seule réponse. Pour les équipes dont les contraintes excluent totalement un plan de contrôle hébergé, il existe une édition on-premise sous licence annuelle avec support.
La moitié on-premise n'est pas du legacy
Il existe sur ce marché une hypothèse paresseuse selon laquelle le matériel possédé est un état transitoire vers quelque chose de mieux. Parfois, c'est vrai. Souvent, c'est la bonne réponse : des workloads lourds et prévisibles dont vous possédez l'amortissement, des données que la réglementation ou un contrat maintiennent dans un bâtiment précis, des exigences de latence qu'aucune région ne peut satisfaire, et du matériel qui a encore des années de vie utile devant lui. Traiter ce parc comme un citoyen de seconde classe dans votre outillage n'accélère pas sa mise à la retraite. Cela signifie juste qu'il est moins bien surveillé.
Un seul plan de contrôle sur les deux moitiés change de petites choses qui s'additionnent. La dépense est suivie sur tous les fournisseurs avec des plafonds, donc la question de ce que coûte un environnement a une seule réponse au lieu de cinq exports. Les rôles et les invitations sont par organisation, donc la revue d'accès est une seule revue. Et chaque changement, cloud comme on-premise, atterrit dans la même piste d'audit en append-only et chaînée par hachage, exportée avec le hash de chaque entrée et celui de son prédécesseur, pour qu'un auditeur puisse vérifier la séquence de façon indépendante.
Ce que vous apporte un seul plan de contrôle
Pour être honnête, rien de tout cela ne rend l'hybride simple. Deux modèles d'hébergement ont toujours deux profils de panne, deux processus d'achat et deux structures de coût, et aucune interface ne change ça. Ce qui disparaît, c'est la taxe que vous payez pour la frontière : les inventaires dupliqués, la seconde revue d'accès, l'incident où personne ne peut dire ce que faisait le côté on-premise au même moment. Cette taxe est payée par votre plus petite équipe, en continu, et c'est pourquoi l'hybride paraît pire qu'il ne l'est réellement.
Le test que nous poserions à n'importe quelle plateforme de gestion cloud hybride, la nôtre incluse, est donc court. Pouvez-vous voir tout ce que vous faites tourner, loué et possédé, dans une seule liste, en moins d'une heure, sans rien migrer ? Pouvez-vous dire qui a changé quoi le mois dernier, des deux côtés de la frontière ? Pouvez-vous répondre à ce que ça coûte sans ouvrir cinq consoles ? Si oui, l'hybride redevient juste de l'infrastructure. Si non, vous n'avez pas une plateforme, vous avez une console de plus.