No middle ground, no compromise: VMware blocks Cisco's SDN play
Not cool, man
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 understand what the lack of third-party virtual switches could mean, we need to first understand the major approaches to SDN. In its barest essence, SDN is about managing network configurations across multiple devices.
Once, if we wanted to configure VLANs, ACLs and other networking parameters, you'd have to log in to each switch, make a change and then commit that change. Networking vendors are allergic to anything resembling ease of use, so we had to employ specialists to wiggle the runes and make it happen.
This worked for the cash-flush corporations when the number of workloads was smallish. When the number of workload skyrocketed so too did the number of network change requests and network devices.
Individually modifying devices wasn't cutting it; we needed to make changes from a single location that could affect any device on the network. We also needed to be able to disseminate change throughout the entire network fabric quickly.
SDN types call this "separating the control plane from the data plane": centralizing the bit that tells switches and routers where data flows should go from the actual devices that make the data flows go to that place.
The three big approaches are hardware-dominant (the approach taken by Cisco among others), software dominant, and hybrid. Such is the potential that tech researchers IDC reckon SDN will be worth nearly $12bn by 2020.
VMware's already doing a billion dollars a year on it.
Three paths in the forest
In the hardware-centric world, network functions are provided by hardware. You have physical routers, physical intrusion detection systems and so forth. DHCP, DNS, various tunnels and other basic network functions are provided by devices in your physical network fabric. In the software-centric world we have Network Functions Virtualization (NFV), and all these network services are provided by virtual machines.
If a workload wants network services it sends packets out to the physical network, and the physical network takes care of them. This is true even if the other workload(s) being communicated with are on the same physical host. In a software world, network services are provided on each host, sparing the utilization of physical network resources for journeys that don't leave the same host, but consuming some resources on each host to accomplish this task.
Hybrid systems are far more focused on "use what you already have". They tend to put low-impact services (DHCP, DNS) in the physical layer and keep higher volume services (such as routing) in the host. There are no hard and fast rules for this, however, and different hybrid solutions will use different services in different places.
From a practical standpoint, hardware-centric SDN is about extending the control of network administrators right to the VM in an easy to use fashion. Software-centric SDN is usually about doing away with the need for network administrators altogether by giving control over the network to virtual administrators.
Why vswitches matter
Workloads live in VMs and containers with somewhere between dozens and hundreds of workloads per physical host. They often talk more with each other than they do with other nodes across the network. These workloads shouldn't be all on the same flat layer 2 network. They will need to occupy multiple VLANs. They will have different security needs. And, when multiple sites are involved, workloads on one site will need to talk to workloads on another site unhindered.
The virtual switch inside a hypervisor or microvisor is important. It's the switch that these workloads connect to, and it will be needed to provide some basic services, such as VLAN/VXLAN connectivity. Ideally, it would also handle tunnels and other such things directly, without needing to pass packets all the way out to the physical network. (This would mean packets are in the tunnel and encrypted before leaving the box, making snooping on them harder.)
To be effective, hardware-centric SDN approaches really need to be able to coordinate with a virtual switch. Cisco (and others) will try to tell you otherwise, but it doesn't take a networking specialist to see why that's more marketing than tech.
Software-centric SDN, however, doesn't really need the co-operation of the hardware switching fabric. It can brute force SDN with enough tunnels. The price for this is often latency; hardware acceleration is useful, especially when talking about layer 2 extensibility across sites.
Hybrid systems aim for that ideal world where we have a single control plane that managed both physical switches and virtual switches in a joined-up way.
When it works, it works great. 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.
VMware's decision is a very public dick move signalling that there can be no co-operation. So for those organizations that can't get beyond the brand loyalty and insist on Cisco and VMware, either Cisco kills VMware or VMware kills Cisco. There is no middle ground, no compromise. One of these two wins all the accounts of those who only believe in market share. The other's SDN ambitions are annihilated.
VMware's official line on killing off third-party vswitches is that less than 1 per cent of VMware customers use them. Of course, only 2,400 customers use VMware's own NSX.
SDN is usually rolled out in stages. Those who deploy Cisco's SDN, for example, often deploy it first as a means to get their physical switching fabric under some form of control, with plans to extend that into the virtual switch space viewed as a second stage.
VMware's decision is therefore a brutal blow to Cisco, who would hope to grow in time. VMware's NSX can work with any switches. They simply don't need Cisco. They could choose to launch their own line of switches tomorrow – or buy someone who does – and, in the datacenter at least, Cisco is done.
Cisco, on the other hand, can't even buy (or pseudo-not-buy, or whatever it is you want to call the subordinate position Springpath is in) the right hyperconvergence company.
Those rumors of Cisco buying Red Hat are – frankly, I believe – insanity. Cisco has no hope whatsoever of buying a virtualization platform and doing anything other than driving it straight into the ground.
I see no path to 2020 in which Cisco gets to preserve its outrageous margins on network gear, excepting for the very niche or very top-end widgets. The other side of this is that VMware is a strong adoption cycle away from regulatory scrutiny and discussions about antitrust. ®