No middle ground, no compromise: VMware blocks Cisco's SDN play

VMware's recent decision to block third-party virtual switches on its platform could put a serious crimp in, among others, Cisco's plans for Software-Defined Networking (SDN). What does this move mean for customers who don't buy into VMware's NSX vision, but prefer the more hardware-centric SDN exemplified by Cisco's ACI? To …

[Voland's right hand]

Vmware behaving like Vmware

Vmware is behaving like Vmware. Nothing new to see here - move along.

[Locky]

Michael flexing his muscles

While I don't think the Borg are done just yet, this is clearly Dell wanting to kill off a bit of competition before raking back in some of that EMC pricetag.

Grab some popcorn, this one has a way to go yet

[Dakaix]

Sorry Trevor, but you've missed a big piece of the ACI system here. ACI can make use of and control the VMware Distributed Switch, it's not just limited to hosts with the 1000V installed.

It's true that VMware's recent change in policy on third-party switches means that the 1000V itself will likely be killed off, but the number of actual customers paying Cisco for that is already negligible (after Cisco made the basic license free-to-use a couple of years ago) so the effect is relatively minimal.

[Glen Turner 666]

SDN future is driven from cloud providers, not supplier strategies

"The problem is that large customers rely almost exclusively on Cisco and VMware, and they aren't interested in the open-source switches and open-source hypervisors with open-source management software that's needed to make hybrid SDN actually workable today."

This paragraph summarises my issue with the article. It's writes as if the enterprise vendors are the major source of influence over SDN. Whereas SDN is being driven by the cloud vendors, all of whom build their own switches, all of whom run their own software on those switches. It's likely that the future of SDN in the enterprise will be a byproduct of the main game at those cloud vendors; rather than anything in the strategic plans of VMware or Cisco.

In my view it's very likely that one of the cloud vendor SDN technologies will become so widely known that enterprises persisting with traditional enterprise networking and VxLAN will find themselves in an expensive niche.

[Anonymous Coward]

Re: SDN future is driven from cloud providers, not supplier strategies

Good point, and if you start thinking about the shift to hybrid workloads running (or migrating) to/from the cloud, using the cloud provider's SDN for seamless connectivity and control is compelling.

[Anonymous Coward]

Re: SDN future is driven from cloud providers, not supplier strategies

Agree, people are interested in moving to cloud, AwS and GCP, to get away from this proprietary in fighting. Really expensive to buy proprietary and it doesn't work well because each vendor is trying to take over the world, won't stay in their lane.

[Anonymous Coward]

Independence

I think decoupling creates more value for customers and the ecosystem

https://www.varmour.com/resources/blog/entry/a-declaration-of-independence-for-network-segmentation

[Terafirma-NZ]

standards and API access

This was why the industry chose to standardise on Open vSwitch. The fundamental problem here is that VMWare builds and maitains the bulk of OVS and even made a commitment to move ESXi over to it, no idea if they did or not but one thing is for sure they are not giving us the API access va OVSDB to control it. If this was exposed then all parties could link in and control the vSwitch be it using NSX or a 3rd party control/integration.

If you look around this is why all the non NSX products show integration with KVM and Openstack as they have access to OVSDB. If you want this on ESXi you have to purchase NSX thus negating the 3rd party product you wanted to use.

Funny how VMWare build OVS and are the only ones who don't use it heck even MS Hyper-V is supported and MS will give you OVSDB API access to their switch.

[Anonymous Coward]

Re: standards and API access

The funny thing is that OVS is supported on the ESXi hypervisor, but only with "NSX Transformers" (aka NSX multihypervisor). There are only about three VMware employees who know or acknowledge that fact.