Peut-on s’extraire, même progressivement, de VMware ? Pour Ludovic PIOT, oui, c’est parfaitement envisageable, et sans opter pour un de ses équivalents. Il faut pour cela considérer les VM comme un type de workloads parmi d’autres, que Kubernetes pilote en tant que socle unique de l’infrastructure. Le choix de Kubernetes est d’ailleurs très pertinent si l’on tient compte de l’évolution des pratiques de développement et des cas d’usage.

Comment Kubernetes peut-il être considéré comme le socle unique de l’infrastructure ?

Ludovic PIOT : Les machines virtuelles sont regardées comme un sujet d’infrastructure. Les conteneurs, eux, ont une adhérence forte à l’applicatif. Mais Kubernetes est avant tout un orchestrateur de ressources IT, qui sait gérer à la fois conteneurs et VM.

Moderniser les plateformes IT avec Kubernetes est une manière d’embrasser une approche produit dans la mise à disposition d’une plateforme IT polyvalente et évolutive. C’est aussi un levier de modernisation des modes de consommation de l’infrastructure, une modification des topologies pour de nouvelles stratégies d’hybridation et le tremplin vers des cas d’usage variés.

VMware a introduit de la flexibilité dans les datacenters, une réduction des coûts, la rationalisation des matériels, et a répondu au besoin d’isolation des applications et de simplification des tests et des développements. Il n’en demeure pas moins que la construction des VM, leur mise à jour et leur gestion empruntent encore fréquemment au bon vieux modèle de l’administrateur qui gère ses serveurs et aux utilisateurs qui les lui commandent en créant un ticket.

Kubernetes sait virtualiser à travers l’hyperviseur KVM, principal concurrent à ESXi et que l’on retrouve dans nombre de solutions rivalisant avec VMware (OpenStack, ProxMox, Huawei DCS, HPE Morpheus VM Essentials Software, etc.) et orchestrer de la VM, via la solution KubeVirt, aussi aisément qu’il gère des conteneurs. Toutes les raisons sont là pour considérer Kubernetes comme l’orchestrateur socle de ses plateformes IT si l’on entend vraiment les moderniser. Et plusieurs de nos clients ont déjà fait ce choix.

En quoi Kubernetes se distingue-t-il des concurrents « naturels » de VMware tels que Proxmox ou Openstack ?

Opter pour l’environnement Kubernetes pour exécuter des VM est un changement de modèle au cœur des pratiques. On ne manipule pas du Kubernetes comme on manipule du VMware ou ses concurrents directs. Si l’interface Web reste disponible pour des manipulations épisodiques, le paradigme nominal d’administration passe par des fichiers de configuration, gérés en mode GitOps, qui servent de directives permanentes aux boucles de réconciliation de l’orchestrateur Kubernetes. Ce peut être délicat mais c’est également un bond gigantesque dans l’autonomie des équipes utilisatrices de la plateforme, et l’expertise des ingénieurs qui l’administrent, dont le rôle devient de fait plus stratégique, plus « produit ».

Techniquement, les avantages reposent sur plusieurs points, bien compris de nos clients : d’une part, pour toutes les fonctionnalités avancées du réseau comme la microsegmentation ou la virtualisation multicouche, les options classiques n’atteignent pas les capacités de VMware NSX-T. Elles sont en revanche natives dans le monde Kubernetes. C’est, j’en suis convaincu, la meilleure stack de virtualisation réseau du marché et celle qui fait clairement pencher la balance en faveur de Kubernetes.

D’autre part, quitte à devoir gérer différents workloads, autant qu’ils le soient dans un environnement unique. La standardisation de la gestion des plateformes rend secondaire la technologie d’abstraction utilisée, simplifie considérablement la gestion et prépare l’avenir de l’entreprise.

Enfin, rappelons-le, Kubernetes adresse aussi bien les grands candidats traditionnels propriétaires ou Open source du stockage que peuvent le faire tous les concurrents de VMware.

Quelles sont les typologies d’organisation lancées dans cette transition et où se cachent les points d’achoppement pour ces entreprises ?

Beaucoup d’entre elles disposent déjà d’une empreinte conteneur avérée et en sont satisfaites. Elles ont choisi d’aller plus loin, une fois le réseau, le stockage et les conteneurs maîtrisés, en ajoutant la brique VM dans Kubernetes. En d’autres termes, le sujet est pris en main par des organisations relativement préparées à la conteneurisation et titulaires d’un socle de compétences couvrant les domaines de l’infrastructure as code, de la culture GitOps, de l’automatisation, etc. La transition côté VM est alors parfaitement transparente au point de vue de la charge applicative.

Reste, on le sait, que le diable se cache dans les détails. Il peut arriver que les éditeurs refusent d’assurer le support d’un progiciel qui ne serait pas hébergé sur VMware ou qu’un produit antédiluvien n’ait pas été mis à jour pour intégrer un support sur KVM. Ces cas se rencontrent et demandent un arbitrage. Même dans les situations présentant jusqu’à 40 % d’un portfolio applicatif non supporté, les entreprises choisissent de poursuivre leur transition parce qu’elles ont compris tout l’enjeu derrière cette modernisation. Aujourd’hui, rares sont les éditeurs à ne pas afficher formellement le support de KVM par leurs solutions. L’efficacité de l’hyperviseur Open source est la raison pour laquelle la plupart des solutions de virtualisation l’exploitent d’ailleurs.

Comment alors s’orienter dans cette prise de décision complexe ?

Stordata propose un accompagnement à la réflexion aux entreprises souhaitant quitter la solution VMware. Si elles ont commencé à déblayer le sujet autour des solutions de remplacement les plus connues, elles sont très peu au fait des autres possibilités. Cela s’explique par le fait que l’immense galaxie Kubernetes est mal représentée au sein des articles traitant de la question VMware. En cause, les difficultés à distinguer le rôle des multiples briques et extensions qui la composent et la grande variété des acteurs en présence participant à cet univers.

Nous constatons pourtant que le seul fait d’ouvrir la discussion sur Kubernetes engendre des réflexions portant sur des sujets devenus importants, voire stratégiques dans l’entreprise : la problématique du vendor lock-in (particulièrement remise sur le devant de la scène depuis le rachat de VMware) ou à tout le moins, de dépendance à un support et aux mises à jour, le manque de solutions souveraines ou encore la montée en compétence des équipes dans une démarche de plateformisation.

Pour les unes, le choix portera toutefois sur une solution VMware like, parce qu’elles ne disposent pas de la maturité technologique ou de l’organisation interne nécessaires pour accueillir Kubernetes ou tout simplement parce qu’elles n’en ont pas un besoin immédiat.

Pour d’autres, en revanche, le moment peut être venu de faire entrer plus de souveraineté, brique après brique, dans leurs systèmes. Si les solutions européennes ne sont pas légion, l’acteur allemand SUSE propose une distribution Kubernetes orientée virtualisation remarquable avec SUSE Virtualisation (basée sur KubeVirt et Harvester), concurrent frontal de Red Hat OpenShift Virt.