bluebay2014 - Fotolia

VMware va fermer sa plate-forme aux commutateurs virtuels tiers

La prochaine mise à jour de vSphere abandonnera l'API VDS, qui permettait à des commutateurs virtuels tiers de s'interfacer avec l'hyperviseur. Le message de VMware est clair : NSX et son propre vswitch sont la seule voie possible pour le SDN dans l'environnement VMware.

VMware a officialisé l’abandon prochain de son API VDS, qui permettait l’intégration de commutateurs virtuels tiers à vSphere. Selon la firme, l’API continuera à être supportée pour les clients VMware jusqu’à la version 6.5 update 1 de vSphere. Dans toutes les versions ultérieures, le support de l’API permettant le support de « vSwitches » tiers sera retiré. L'information a aussi été communiquée à des clients et répercutée sur plusieurs blogs, dont celui de Julien Mousqueton en charge de la pratique datacenter de l'intégrateur Computacenter 

Dans la pratique, cette décision condamne à mort les commutateurs virtuels de partenaires comme de Cisco (Nexus 1000v, VM-Fex ou AVS), HPE (HPE 5900v) ou IBM (DVS 5000v). Autant de logiciels que ces constructeurs maintenaient, car ils leur permettaient de disposer d’un point de contrôle pour déployer leurs propres stratégies SDN sur l’infrastructure VMware.

Quoiqu’en dise VMware, la décision n’a clairement qu’un but : permettre à VMware de déployer sans concurrence sa stratégie SDN, centrée sur VMware NSX, en empêchant ses concurrents d’utiliser leurs propres vSwitches comme un point de contrôle dans ses produits.

Officiellement, VMware ne supportera plus que son propre vSwitch et Open vSwitch (OVS). Cette déclaration ne manque toutefois pas d’ironie, car elle est en fait incomplète : En fait, une formulation plus honnête aurait été de dire que VMware ne supportera plus que son vSwitch sur vSphere et OpenvSwitch sur Linux.

Car VMware n’est pas fou, d’un côté il ferme l’accès de sa plate-forme aux solutions tierces, et de l’autre, il maintient son soutien au projet open source Open vSwitch qui lui permet de disposer d’un point de contrôle pour NSX sur les plates-formes Linux. Ce point de contrôle est stratégique, car il permettra à terme à NSX d’offrir des services de microsegmentation réseau à la fois dans les environnements VMware et dans les environnements de conteneurs Linux.

VMware mise sur l’intégration verticale au détriment de l’ouverture

Comme l’explique VMware dans un billet de blog, « cette stratégie a pour but d’investir dans les priorités de nos clients et de simplifier la plate-forme pour créer l’expérience la meilleure et la plus sûre possible. En utilisant le commutateur virtuel natif à la plate-forme, les clients simplifient leur environnement informatique en réduisant les temps de mise à jour. Ils simplifient leur support, déploient de nouvelles fonctions plus rapidement ». Bref, VMware œuvre pour le bien de ses clients. À la décharge de l’éditeur, les déploiements de vSwitches tiers n’ont pas forcément toujours été de tous repos et ont parfois causé des problèmes de support. Mais sans doute pas au point de justifier l’extinction de l’API pour des raisons de « simplification » des environnements des clients.

Pour ceux qui ont un peu de mémoire, la stratégie de VMware rappelle un peu le fameux « Embrace, extend, extinguish (embrasser, étendre, étouffer) » de Microsoft. Lors de son enquête antitrust au début des années 2000, le département de la justice américain avait accusé Microsoft d’avoir mis en œuvre une stratégie systématique visant à profiter de sa position dominante pour handicaper les produits de ses concurrents sous Windows. La pratique viser à embrasser une technologie émergente du marché (dans le cas présent les vSwitch), à en enrichir les capacités, puis à fermer l’accès à cette technologie aux tiers afin de contraindre les utilisateurs à utiliser ses propres technologies.

Et ce n’est pas la première fois que VMware se livre à la pratique. Aux débuts de vSphere, VMware avait ainsi encouragé les éditeurs d’outils d’administration et de supervision à adapter leurs outils à vSphere avant de lancer sa propre pile d’administration et d’automatisation, et d’écraser la concurrence. Cette manœuvre avait rappelé ce qu’avait réalisé Microsoft avec sa propre pile System Center pour Windows.

Plus récemment, VMware s’est réservé l’accès au noyau vSphere pour développer sa solution de software defined Storage VSAN, condamnant tous ses concurrents à mettre en œuvre leur technologie sous forme de machine virtuelle (avec l’impact que cela peut avoir en matière de performance).

La fermeture de l’API vswitch externe n’est que le dernier avatar de cette fermeture progressive de l’écosystème VMware aux outils tiers.

Une déclaration de guerre à Cisco ?

Le plus étonnant est sans doute que la décision intervient alors qu’une paix des braves semblait s’être établie entre Cisco et Dell EMC. La division VCE de Dell-EMC a ainsi maintenu le niveau de commissionnement de ses commerciaux sur les solutions Vblock à base de serveurs Cisco. Cela veut dire que pour l’année à venir, au moins, la collaboration entre les deux constructeurs autour des solutions convergées VBlock se poursuivra normalement.

La fermeture de l’API vSwitch ressemble à une déclaration de guerre à Cisco, qui a le plus à perdre face à l’offensive de VMware sur les réseaux de datacenters. Car l’extinction de l’API vSwitch va sérieusement compliquer l’intégration de l’offre SDN Cisco ACI dans vSphere (elle reposait jusqu’alors sur le commutateur virtuel Cisco AVS).

En privant Cisco d’un point de contrôle dans son infrastructure, VMware cherche clairement à privilégier son offre de SDN VMware NSX. Et le problème pour Cisco est que NSX déplace le point de contrôle des réseaux d’entreprises dans la sphère de VMware et rabaisse largement les équipements réseau au rang de quincaillerie tout juste bonne à commuter des paquets.

L’adoption par les clients de NSX pourrait menacer des pans entiers de la stratégie réseau de Cisco. Elle déplace en effet des fonctions entières autrefois dévolues aux commutateurs physiques dans le périmètre de VMware et elle menace aussi toute la stratégie de valeur ajoutée de Cisco en matière de sécurité ou de gestion des flux.

 VMware courre toutefois un (petit) risque, celui de s’aliéner une partie de ses clients et de les voir migrer une partie de leurs workload vers d’autres plates-formes. On pense bien sûr aux plates-formes open source mais aussi à des plates-formes hyperconvergées émergentes comme celle de Nutanix. Ce dernier est ainsi en train d’incorporer des fonctions de microsegmentation réseau proches de celles de VMware sur sa plate-forme Acropolis. Et elles seront basées sur Open vSwitch, et donc resteront ouvertes aux apports d’équipementiers réseau tiers. 

Approfondir

Participer à la conversation

1 commentaire

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

Cela me rappelle Twitter il y a quelques années lorsque le site de micro blogging a decidé subitement de fermer son API, mettant par la même occasion de nombreuses startups en difficulté. Google a aussi fait parler de ses APIs il y a quelques années lorsque la firme de Mountain View a decidé de facturer l'usage de son API "Google Map", provoquant la panique chez tous les sites d'annonces immobilières.

Cela amène à quelques recommendations: lorsque vous consommez des API tierces, posez vous la question de leur pérennité et de ce que leur fermeture (ou leur facturation) impliquerait sur votre business. Une API est comme un contrat, elle ne fonctionne que lorsque les deux parties jouent le jeu: le fournisseur d'API fournit un service perfomant, stable et pérenne et le consommateur d'API développe de nouveaux services autour. 


Annuler

- ANNONCES GOOGLE

Close