Directement issu du modèle des géants du web, l'ingénierie de plateforme était considérée comme une discipline futuriste jusqu'à il y a quelques années à peine. Aujourd'hui, selon Gartner, 80 % des entreprises auront adopté cette pratique d'ici 2026. L'ingénierie de plateforme signifie différentes choses pour différentes personnes, et il n'existe pas de chemin unique qui prescrive exactement comment bien faire les choses. Mais les principaux objectifs sont universellement compris. D'une part, l'ingénierie de plateforme vise à augmenter la productivité des développeurs en supprimant les goulets d'étranglement et en ajoutant des fonctionnalités en libre-service. D'autre part, elle vise à standardiser les contrôles centraux comme la sécurité et la conformité, afin de maîtriser les coûts et la complexité. 

L'augmentation de la vitesse des développeurs est une victoire claire pour l'ingénierie de plateforme. Les conteneurs, les microservices, Kubernetes, CI/CD et les flux de travail de développement moderne ont indéniablement rendu le développement de logiciels plus rapide, plus productif et plus automatisé pour les équipes distribuées. Mais quid de la partie "contrôle central" de l'ingénierie de plateforme ? Il n'est pas encore facile de déclarer victoire. Nous sommes en plein milieu d'une réaction contre le coût élevé et la complexité du modèle d'exploitation du cloud. Et aujourd'hui, ce côté contrôle central de l'ingénierie de plateforme n'est pas seulement un problème pour les équipes d'ingénierie de plateforme, c'est un problème pour les directeurs financiers, alors que les factures de cloud explosent et que les entreprises ressentent une pression sévère pour trouver des économies. Le cloud et Kubernetes sont là pour rester, mais résoudre un plan de contrôle central défaillant est un dilemme à plusieurs millions d'euros auquel de nombreuses entreprises sont confrontées aujourd'hui. C'est pourquoi un projet open source baptisé vCluster connaît une percée fulgurante. vCluster s'attaque au cœur du modèle d'exploitation Kubernetes, l'abstraction des clusters, pour offrir une gamme d'avantages aux entreprises exploitant K8’s. vCluster ne réduit pas seulement considérablement la surcharge de ressources, ce qui peut se traduire par des économies de coûts significatives, mais apporte également plus d'agilité et de contrôle central aux équipes d'ingénierie de plateforme. 

La voie de l'open source vers l'opportunité 

Les co-créateurs de vCluster (et cofondateurs de Loft Labs), Lukas Gentele et Fabian Kramm, se sont rencontrés à l'université de Mannheim, où, en tant qu'étudiants en informatique, ils ont suivi un parcours technologique similaire, passant de Java et des bases de données orientées graphe comme Neo4j à des technologies axées sur le web comme PHP et JavaScript, puis se plongeant dans le langage Go lorsque Docker et Kubernetes ont pris leur essor. Lorsque Lukas Gentele a lancé une société de conseil en informatique alors qu'il était encore à l'université, Fabian Kramm fut sa première embauche. Au sein de cette entreprise de services informatiques, Lukas Gentele et Fabian Kramm ont créé un projet appelé DevSpace - essentiellement une alternative à Docker Compose axée sur la simplification des flux de travail Kubernetes - et l'ont mis sur GitHub. Ce fut leur première expérience de développement et de maintenance d'un projet open source. Ils avaient tous deux contribué et apporté des correctifs à des projets open source, mais n'avaient jamais possédé ou dirigé un projet en tant que mainteneurs. Voir la magie de l'open source, le distribuer, voir des gens l'utiliser, l'apprécier et y contribuer - ils étaient accrochés. 

Après avoir obtenu leur diplôme universitaire, les deux ont entrepris de créer un produit PaaS (ce que Gentele décrit comme "un Heroku pour Kubernetes"), puis postulé à Y Combinator; ils ont été refusés, mais invités à postuler à nouveau, puis ont transformé cela en une participation au programme d'accélérateur SkyDeck de l'Université de Californie à Berkeley. Finalement, ils ont conclu que le PaaS était une entreprise très difficile à gérer. Ils n'étaient pas les premiers à se heurter à ce mur - comme l'ont démontré les difficultés de Cloud Foundry, Heroku et les fondateurs de Docker à monétiser dotCloud. "Nous avons réalisé que nous avions beaucoup d'utilisateurs gratuits pour notre PaaS, mais peu de volonté de payer", a expliqué M. Gentele. "OK, alors qu'avons-nous appris ? Nous avons appris que gérer de grands clusters Kubernetes et partager ces clusters avec des utilisateurs était extrêmement compliqué et coûteux, et qu'il y avait une bien meilleure façon de le faire, qui représentait une opportunité bien plus grande que le PaaS. Une idée qui pourrait être utile à quiconque gère des clusters Kubernetes."   

Les flottes sont la mauvaise abstraction   

Aux premiers jours de l'orchestration des conteneurs, le marché s'est habitué à l'idée de traiter les serveurs comme du "bétail" (du matériel interchangeable pouvant être remplacé), par opposition à des "animaux de compagnie" (chaque serveur étant traité avec soin), comme concept central pour transformer les serveurs en clusters. Pendant des années, il y a eu un débat architectural sur la question de savoir s'il fallait créer une flotte de petits clusters ou un seul cluster massif. "Kubernetes lui-même a été conçu pour fonctionner à grande échelle", a rappelé M. Gentele. "Il n'est pas conçu pour fonctionner comme un cluster de cinq nœuds. Si vous avez ces petits clusters, vous obtenez beaucoup de duplication et d'inefficacité." Mais à mesure que les principaux fournisseurs de cloud ont déployé leurs offres Kubernetes, de petits clusters mono-utilisateurs et des flottes de clusters multiples sont devenus les unités d'abstraction vendues au marché des entreprises, complétés par des solutions de "gestion de flotte" pour coordonner toutes les pièces mobiles et maintenir les services synchronisés dans l'approche "clusters de mini clusters". Lukas Gentele attribue une grande partie des dépassements de coûts actuels du cloud à ce péché originel des fournisseurs de cloud. 

La première conséquence de l'approche par flotte est la pénalité des composants d'infrastructure lourds payés plusieurs fois. Les équipes de plateforme veulent standardiser les services de base comme Istio et Open Policy Agent - des services conçus pour fonctionner à grande échelle, donc si vous en exécutez beaucoup à petite échelle, c'est vraiment inefficace. Dans l'approche par flotte, ces services sont toujours installés dans chaque cluster, ce qui crée une duplication massive des services de base à mesure que toute la pile de la plateforme est répliquée dans plusieurs petits clusters. L'autre conséquence majeure est que ces clusters fonctionnent tout le temps. Personne ne les éteint. Il n'y a pas de moyen facile d'éteindre un cluster entier sur les principales offres de cloud d'un simple clic. Au contraire, c'est un processus manuel qui nécessite la mise en place d'une politique, et 30 minutes pour démarrer toute la pile de services de la plateforme utilisés pour connecter, gérer, sécuriser et surveiller le cluster. Il est également difficile de dire quand un cluster est vraiment "inactif" lorsque tous ces services de la plateforme - composants de sécurité, agents de politique, conformité, sauvegarde, surveillance et journalisation - continuent de fonctionner en arrière-plan. 

vCluster : Addition par soustraction 

Lukas Gentele et Fabian Kramm ont eu l'idée que l'approche par flotte de clusters pourrait être grandement améliorée, et que la multi-location Kubernetes pourrait être redéfinie au-delà des approches traditionnelles par espace de noms. En 2023, ils ont lancé vCluster et introduit le concept de "clusters virtuels", une abstraction permettant de créer des clusters Kubernetes virtuels légers. De la même manière que les VPN créent un réseau virtuel sur une infrastructure physique, les clusters virtuels créent des environnements Kubernetes isolés sur un cluster Kubernetes physique partagé. vCluster est une distribution Kubernetes certifiée, donc les clusters virtuels se comportent exactement de la même manière que tout autre cluster Kubernetes - à une différence importante près. Alors que chaque cluster virtuel gère ses propres espaces de noms, pods et services, il ne réplique pas la pile de la plateforme. Au lieu de cela, il partage les composants lourds de la plateforme, tels qu'Istio ou Open Policy Agent, exécutés par le cluster physique sous-jacent. Avec cette pile de plateforme partagée, les clusters virtuels ne traînent plus l'albatros de la réplication des services de plateforme. 

Et pourtant, chaque vCluster a son propre serveur API et son plan de contrôle, offrant une isolation forte aux développeurs et donnant aux équipes de plateforme la possibilité de créer leurs propres politiques personnalisées pour la sécurité et la gouvernance. Ils peuvent créer leurs propres espaces de noms, déployer leurs propres ressources personnalisées pour protéger les données du cluster en utilisant leurs propres systèmes de sauvegarde et appliquer leurs propres politiques de contrôle d'accès aux utilisateurs. En même temps, vCluster offre aux équipes de plateforme une bien plus grande vitesse et agilité qu'un cluster physique. Un cluster virtuel peut être lancé en une fraction du temps nécessaire pour lancer un cluster physique. Un redémarrage d'un vCluster prend environ six secondes, contre 30 ou 45 minutes pour redémarrer un cluster Kubernetes physique qui exécute des services de plateforme lourds comme Istio en arrière-plan."Kubernetes est formidable d'un point de vue API, d'un point de vue outil, d'un point de vue standardisation - mais l'architecture que les fournisseurs de cloud ont préconisée pour exécuter des clusters de petits clusters a ramené l'industrie au serveur physique en termes de coût et de lourdeur", a souligné Lukas Gentele. "Dans les années 90, quelqu'un devait en fait physiquement entrer dans un centre de données, brancher un serveur, émettre des informations d'identification et prendre d'autres mesures manuelles", a-t-il déclaré. "Nous sommes dans une situation similaire avec Kubernetes aujourd'hui. De nombreuses entreprises exécutent l'ensemble de leur pile d'applications dans chaque cluster, ce qui crée beaucoup de duplication." 

vClusters rend le cluster Kubernetes plus léger et éphémère, de la même manière que les machines virtuelles l'ont fait pour les serveurs physiques et que les conteneurs l'ont fait pour les charges de travail en général. "Faire tourner de petits clusters Kubernetes mono-utilisateurs était une très mauvaise idée en premier lieu, car c'est très coûteux et très difficile à gérer", a déclaré Gentele. "Vous allez vous retrouver avec des centaines de clusters. Et puis vous devez maintenir des choses comme le contrôleur d'ingress, le gestionnaire de certificats, Prometheus et les métriques à travers tous ces clusters. C'est beaucoup de travail, et c'est vraiment difficile à garder en synchronisation." 

vCluster en chiffres 

vCluster a plus de 6 000 étoiles sur GitHub et plus de 120 contributeurs. Le projet a attiré l'attention d'experts Kubernetes tels que Darren Shepherd, ancien CTO et cofondateur de Rancher, qui plaide pour l'utilisation de clusters virtuels. Des équipes d'Adobe, CoreWeave et Codefresh ont parlé de leur utilisation de vCluster lors d'événements comme KubeCon. La startup Loft Labs de Lukas Gentele et Fabian Kramm a récemment été financée pour étendre les capacités d'entreprise autour de vCluster. La série A de 24 millions de dollars a été dirigée par Khosla Ventures, connu pour être le premier investisseur institutionnel dans des entreprises comme GitLab et OpenAI. L'offre commerciale de la start-up basée sur vCluster a suscité un enthousiasme particulier pour son "mode sommeil", qui éteint automatiquement les clusters virtuels inactifs. En général, les entreprises qui lancent des clusters les voient fonctionner en permanence. Le produit de Loft Labs mesure l'activité des clusters virtuels en surveillant les requêtes API entrantes, utilisant le mode sommeil pour réduire automatiquement les clusters virtuels lorsqu'ils ne sont pas utilisés, afin d'économiser les ressources cloud et les coûts globaux.   

vCluster peut aider à gérer l'infrastructure cloud de manière plus efficace et à réduire les coûts cloud, mais il offre également aux entreprises une voie plus claire pour gagner en contrôle central et en vitesse de développement. En plus d'étendre les ressources des clusters physiques, vCluster fournit à chaque cluster virtuel son propre serveur API et plan de contrôle séparé, offrant aux équipes de plateforme à la fois plus de flexibilité et plus de contrôle sur la gestion, la sécurité, les allocations de ressources et la mise à l'échelle de leurs clusters Kubernetes.