Sont-elles plus adaptées au cloud hybride ou trop orientées développeurs ? Les nouvelles versions dopées à Kubernetes et Pivotal divisent les observateurs. Elles seront livrées en mai.
En mai prochain, VMware mettra enfin sur le marché la nouvelle génération Tanzu de ses solutions de virtualisation d’infrastructures. Pour l’éditeur, il s’agit d’une évolution majeure de ses produits puisqu’ils intégreront désormais le moteur open source Kubernetes et l’environnement de développement PKS. Le premier sert à déployer des applications au format container, en plus des machines virtuelles jusqu’ici utilisées dans les datacenters. Le second, issu de la réintégration de la société sœur Pivotal, est un PaaS qui permet aux développeurs d’écrire, de tester, et de mettre en production des applications web.
À l’heure du cloud hybride, VMware a jugé essentiel de donner aux applications la capacité de s’exécuter depuis n’importe quel hébergeur, dans un format nativement prévu pour éponger les montées en charge. Et comme tout cela fonctionne mieux avec des containers qu’avec des machines virtuelles, il était finalement plus simple d’intégrer Kubernetes que de tenter l’aventure avec de énièmes technologies propriétaires.
« Nous voulons donner aux développeurs les moyens de livrer leurs applications sur n’importe quelle infrastructure, dans n’importe quel cloud. Nous voulons aider les DSI à gagner les compétences nécessaires pour encadrer la déferlante d’applications modernes. Bref, nous voulons supprimer tous les obstacles à l’adoption de Kubernetes », a déclaré Pat Gelsinger lors de l’événement VMware Modern Apps qui s’est tenu en ligne en fin de semaine dernière.
« Kubernetes a pratiquement volé le marché de la virtualisation à VMware. Celui-ci n’avait d’autre choix que de revoir son moteur, tout en conservant la même apparence en espérant que cela suffira à garder les clients », commente, au micro de nos confrères de TechTarget USA, Holger Mueller, analyste chez Constellation Research.
Une nouvelle offre adaptée aux entreprises qui écrivent leurs applications
En pratique, les deux principaux produits de VMware, la suite de virtualisation vSphere 7 pour datacenters et sa déclinaison Cloud Foundation 4 pour infrastructures hyperconvergées, sont désormais fournis avec un moteur d’exécution de containers, appelé Kubernetes Grid.
vSphere 7 et Cloud Foundation 4 s’accompagnent par ailleurs de cinq options. La console Tanzu Mission Control centralise l’administration de plusieurs clusters. La console de monitoring des performances Tanzu Observability by Wavefront va jusqu’à faire de l’APM. Le moteur (ex-Pivotal) Tanzu Application Service automatise la mise en production des applications en VMs et/ou en containers, à la manière d’Ansible chez Red Hat.
Également, le store (ex-Bitnami) Tanzu Application Catalog sert de système de packages standardisés pour installer des applications prêtes à l’emploi, soit depuis des dépôts en ligne publics, soit depuis un dépôt interne à l’entreprise. Enfin, le kit de développement (ex-pivotal) Tanzu Spring Boot permet aux programmeurs Java de créer des applications élastiques.
« La question est de savoir si vous aurez besoin de tout cela », interroge, également au micro de nos confrères de TechTarget USA, Brian Kirsh, architecte IT à l’institut américain Milwaukee Area Technical College.
« Tout ce que VMware présente ici se destine aux entreprises qui écrivent leurs propres applications et qui veulent le faire avec des containers. »
Brian KirshMilwaukee Area Technical College
« Tout ce que VMware présente ici se destine aux entreprises qui écrivent leurs propres applications et qui veulent le faire avec des containers. Kubernetes, lui-même, ne sert qu’à orchestrer ces containers. Mais qu’en est-il des entreprises qui ne sont prêtes ni pour les containers, ni pour Kubernetes ? », poursuit-il.
Il revendique avoir toujours besoin de l’assistance de VMware pour dépanner ses 45 000 élèves. En revanche, l’établissement achète tous les logiciels qu’il utilise, il n’en développe aucun. « Le support de VMware va-t-il encore avoir assez de ressources à accorder à des gens comme nous », s’inquiète-t-il ?
La promesse de migrer plus facilement
Et de battre en brèche l’argument de VMware qui consiste à dire que, grâce à Kubernetes, il devient aussi plus facile de migrer les traitements sur d’autres matériels, vers d’autres datacenters, ou encore vers un cloud :
« Honnêtement, combien d’entreprises ont vraiment besoin de ça ? VMware pense-t-il que les entreprises ont besoin de changer de fournisseur d’infrastructure tous les quatre matins ? Une migration représente beaucoup de travail et, quel que soit le degré d’abstraction que vous y mettrez, ce ne sera jamais aussi simple que d’appuyer sur un bouton », dit Brian Kirsh
Lors de l’événement qu’il a tenu en ligne, VMware a été interrogé sur la pertinence de basculer sur la nouvelle version vSphere pour une entreprise qui utiliserait déjà la distribution Kubernetes d’un autre éditeur.
« Le passage de ce Kubernetes au nôtre sera automatique. »
Craig McLuckieVMware
« Le passage de ce Kubernetes au nôtre sera automatique. C’est la magie de la virtualisation, elle simplifie toutes les migrations. vSphere savait déjà migrer des serveurs physiques – “bare metal” – vers des machines virtuelles. Déplacer des containers d’un cluster Kubernetes à un autre est d’autant plus simple que nous respectons les standards Open source », a argumenté Craig McLuckie, le patron de la nouvelle division « Modern Apps », en charge de tout ce qui a trait à Pivotal et Kubernetes.
NSX et vSAN évoluent pour les containers
Par ailleurs, les modules historiques de VMware évoluent pour satisfaire les besoins des containers. Le système de stockage software-defined vSAN 7 partage désormais ses disques en mode fichiers/NAS sur le réseau, via le protocole NFS. VMware a aussi doté vSAN 7 d’un pilote CSI (bizarrement appelé ici CNS, pour Cloud Native Storage) qui permet d’inclure le SAN virtuel dans un cluster Kubernetes comme s’il s’agit d’une baie de disques en mode bloc.
Si cette seconde option permet d’apporter du stockage persistant aux bases de données critiques, la plupart des applications modernes – conçues pour être élastiques – préféreront aller lire ou écrire leurs données sur un NAS partagé.
Le réseau virtuel NSX est désormais remplacé par NSX-T qui fonctionne avec d’autres hyperviseurs que celui de VMware. Surtout, cette version sait s’interfacer avec Kubernetes. Par ailleurs, son module de répartition de charge applicative, NSX Service Mesh, devient un produit à part entière, appelé Tanzu Service Mesh. La répartition de charge entre instances étant une fonction de base sur une plateforme qui se veut élastique, VMware permet ainsi aux entreprises de l’installer directement sur le moteur Kubernetes Grid, sans devoir installer tout NSX.
Précisons que la répartition de charge applicative fonctionne sur la base de noms de domaine (en l’occurrence les GNS, ou Global NameSpaces). Elle permet donc facilement de répartir les instances d’une application entre un datacenter et plusieurs clouds.
Selon nos confrères américains de TechTarget USA qui ont interrogé l’US Air Force, une entreprise qui évalue en ce moment plusieurs distributions Kubernetes, OpenShift de Red Hat serait meilleur pour déployer des containers sur des appareils déconnectés. L’armée parle plus précisément ici de ses chasseurs F16, avec leurs ordinateurs de bord qui fonctionnent sous un OS temps réel. En revanche, VMware présenterait l’intérêt de fournir un package complet.
« Comme nous, nombre d’entreprises ont toujours besoin d’une pile de virtualisation traditionnelle sur site en complément de Kubernetes. Les choix sont finalement d’investir dans une solution Google Anthos, Azure Stack, Amazon Outposts… ou VMware Cloud Foundation, qui propose toutes les fonctions clés en main jusqu’à Kubernetes. Cela pourrait in fine nous inciter à préférer VMware », dit Nicolas Chaillan, le DSI de l’US Air Force.
VMotion plus rapide, vTA pour garantir la sécurité
La nouvelle génération Tanzu améliore aussi des rouages traditionnels, indépendamment de Kubernetes. La fonction vMotion sait désormais déplacer une VM plus rapidement d’un serveur physique à l’autre, car elle compresse sa mémoire avant de l’envoyer sur le réseau. Non seulement le temps d’interruption lié au transfert serait en moyenne inférieur à une seconde, mais vMotion serait aussi en mesure à présent de déplacer des VMs « de très grande taille » comme les bases de données in-memory.
Pêle-mêle, ESXi prend désormais en compte les barrettes mémoire Optane DC PMM d’Intel et offre plus de granularité dans la virtualisation des GPUs. On note aussi l’apparition d’un dispositif de sécurité appelé vTA (vSphere Trust Authority) qui dédie un nœud physique à la surveillance du reste de vSphere, conserve de manière isolée les clés qui ont servi à chiffrer les VMs et enclenche des procédures de protection en cas de corruption.
« Lorsque nous avons commencé à refaire l’architecture de nos produits, l’idée n’était pas au départ de satisfaire les besoins techniques de Kubernetes. En revanche, nous voulions répondre aux entreprises qui attendaient que leur infrastructure se comporte comme un cloud. C’est-à-dire, que la mise en production de ses ressources puisse se faire directement depuis le code de leurs développeurs. Par exemple, les paramètres de NSX-T sont définissables depuis l’API de Kubernetes. Nous pensons in fine que nous avons donc le Kubernetes le plus fonctionnel », conclut Kit Colbert, en charge de la division cloud chez VMware.
