Well, the cat is finally out of the bag. VMware's Billion dollar acquisition of Nicira last year signaled that all is not well between these two industry titans. And with the formal launch of NSX at VMworld, it has now become clear that Cisco and VMware have fundamentally different strategies around network virtualization. One thing that became very apparent this week is just how core NSX is to VMware's strategy moving forward which highlights just how deep the divide is ... for customers planning the future of their VMware environments, it seems they will have to take a hard look and decide whose vision they prefer and either move towards VMware's and away from Cisco's; or the opposite as these visions continue to move further and further apart.

Ms. Warrior's post "Limitations of a Software-Only Approach". If that left any doubts, Ms. Warrior goes on further to say "there are significant differences in our visions over the future of networking". On her leading point, I would have to agree with Ms. Warrior, there are definitely limitations to a "Software-Only" Approach. VMware networking CTO Martin Casado also seems to agree with this point - in Mr. Casado's interview on @theCUBE at VMworld this week, he noted that while VMware NSX would work very well over any infrastructure, customers would benefit from tighter integration with the physical network as provided by NSX through pretty much every networking company other than Cisco.

While some may see this as an extreme statement, I think it is said right in the title of

In fact, there have already been examples of this very point playing out in front of our eyes for the past several years, starting with the launch of Cisco UCS. From the launch of UCS, Cisco has been positioning the notion that assigning a hardware-provisioned virtual nic to each virtual machine would result in far better performance. But, what Cisco fails to mention is that, there were already other mechanisms such as VMware's netqueue that offered perhaps far better performance optimizations ... transparently. Leading NIC vendors including Intel, Emulex, Qlogic, Broadcom and others claim that netqueue can more than double the network performance of a VM, but Cisco's own nics seem to not offer support for this defacto industry standard.

I think it is important to ask, why don't Cisco's nics support netqueue? Perhaps the coolest part of netqueue is that its optimizations happen completely transparently and dont require any specific type of configuration, meaning that if you need to move a virtual machine the destination doesn not have to have identical hardware to the source. But, becasue netqueue is supported across almost all data center class nics(except Cisco's), that is not really an issue. But, for some unknown reason, Cisco has apparently opted not to support it, instead putting forth an alternative technology that would limit a virtual machine to only be able to move to servers that have this Cisco-specific hardware. Now I am not saying netqueue is perfect, but it offers a significant impact and an open, broadly supported mechanism and highlights an approach that will certainly continue to grow - hardware optimizations that do not require strict vendor lock-in and cumbersome out-of-band add-ons to achieve VM portability. VMware has also provided network APIs that currently allow just about every network vendor other than Cisco to transparently configure the physical network, automatically as needed by the VM, but once again, Cisco is the lone standout choosing to not participate in this optimization.

I think these examples are directly in line with the points I see being made by Ms. Warrior and perhaps how they would differ from Mr. Casado's. To see this you need to look no farther than seeing how much virtualization has grown over the past decade. When virtualization was new, it could only run workloads that did not have high performance requirements. And over the years they have gotten to the point where today you can run pretty much any workload in a VM. And this has only happened becasue VMware has never taken a "software-only" approach but rather a very hardware-centric one.

But there is no bigger divide between Cisco and VMware than each vendors respective approach to how they take on hardware. VMware has achieved their optimizations by evolving hardware standards and norms along with Intel and the entire server hardware industry, all nic vendors and the vast majority of storage vendors. VMware's robust storage API's are an exceptional example of this offering a deeply integrated mechanism that allows storage vendors to offer significant hardware optimizations without forcing vendor lock-in.

But perhaps most puzzling to me is Ms. Warrior's assertion that a stack must be completely vertically integrated to be able to work well, she notes:

" a software-only approach to network virtualization places significant constraints on customers ... This loosely-coupled approach forces the user to tie multiple 3rd party components together adding cost and complexity in day-to-day operations as well as throughout the network lifecycle. Users are forced to address multiple management points and maintain version control for each of the independent components. "

Now the reason why I find this puzzling, is that it seems to me about the most self-contradicting statement one could possibly make. The name of the show is VMworld, it is for VMware customers that use VMware. The very basis for Cisco to even attend this show, along with VMware's 55,000 other ecosystem partners is becasue it is in fact possible to drive deep integration with 3rd party components. The Nexus1000v for example is a glowing tribute to VMware's ability to deeply integrate 3rd parties not only in areas that are at the periphery of their own concerns - clearly VMware's billion dollar acquisition of Nicira and the entire vision of the software-defined datacenter showcases that NSX and networking are the very core of VMware's vision of the future ... yet they have completely pulled back the kimono and allowed their partners and competitors like Cisco's Nexus 1000v to have complete access and compete on par with their own products.

Frankly I think it seems clear that Ms. Warrior's and the many other Cisco execs that have made similar comments this week simply cannot understand that it is in fact possible to drive deep integration with open, well-defined interfaces. Not by trying to claim open api's and abuse "open-source" to create perhaps the most locked-in strategy Cisco has ever put forth. If UCS wasnt locked in enough for you, this weeks glowing homage to complete vertical integration by Cisco shows their true colors. VMware also makes proprietary technology, but I can easily export my VM's and move to another system ... so long as my VM policy is not deployed per Cisco's guidance as the hardware contingincies and external configurations kill portability.

Vmware has proven over the past decade exactly how a software vendor can lead a vast and broad hardware ecosystem to deliver an ever-growing and continuously improving virtualization platform that today can support among the most demanding workloads out there, all with very hardware-centric optimizations that allow these workloads to transfer seamlessly from Dell to HP to Lenovo to Whitebox to Intel to AMD to any cloud provider all without taking a performance hit, offering this very hardware-enabled level of performance without the extreme lock-in that makes Cisco by far the most MARGIN-rich infrastructure company in the world.

Lets just run through some of Ms. Warrior's claims:

Vmware's approach to networking is "Software-only" This claim is patently false. VMware's approach has never been software only and does not claim to be now. It is only "Software-only" for companies that, like Cisco, choose to not support VMware's openly available optimizations. VMware has their own approach too, but they still allow customers to choose Cisco's Nexus 1000v and not force customers down their preferred path. "this approach does not provide key capabilities such as multi-hypervisor support, integrated security, systems point-of-view or end-to-end telemetry for application placement and troubleshooting." Again, patently false. Um, perhaps you missed the memo, but the core capabilities of NSX include multi-hypervisor support and integrated security. And as for telemetry and troubleshooting, perhaps you should spend a little more time outside of the Cisco booth at VMworld as the show floor was filled to the brim not only with partners talking about support for NSX (as with OnePK), but already showing a vast sea of robust applications that support these exact needs ... MUCH moreso than can be said for OnePK (which has been around a good bit longer btw ;) Using "3rd party components" adds "cost and complexity" OK, so tell me again why I would use the 3rd party Nexus 1000 as oposed to VMware's own vDs and NSX platforms? Ya know, since apparently using 3rd party integration adds 'cost and complexity' and all?

The rest of Ms. Warrior's post adds more sugar blossoms and fairy tales about how great Cisco's "Application Centric Infrastructure" will be. Which reminds me of past Cisco initiatives like SONA which have shown that completely closed and proprietary initiatives wont work ... if they would only learn.

I would like to respectfully remind Ms Warrior about why we are having this conversation to begin with, or why any of us have ever even heard of Martin Casado or Nicira or NSX. The only reason is becasue the period of Cisco's dominance over the networking industry has resulted in network technology falling drastically behind other domains of technology. And dont take my word for it ... keep in mind that VMware's Martin Casado is the father of OpenFlow and the primary figure behind the entire SDN movement ... you know, the technology that Cisco downplayed and attacked until they realized they coudnt stop it.

Then Cisco technologists issued many a mea culpa's acknowledging just how bad the network had gotten under their watch and finally fully commited to SDN, leading initiatives like OpenDaylight. But no amount of OpenStack or OpenDaylight can inject a 3rd party into the closed UCS/ACI vision or free virtual machines and policy from proprietary hardware contingencies. These faux postures with open initiatives wont make it any easier to free a virtual machine from being locked down by Cisco's hardware-centric vision. Soon the open source community will come to realize what is really going on here - Cisco is writing a Harvard Case-Study-Worthy strategy in using open-source posturing to promote the most locked-in platforms they have ever put forward.

So today with NSX once again Cisco is downplaying the technological vision of Martin Casado, but this time Mr. Casado is backed up by the whole of VMware from Pat Gelsinger on down. We dont know all that Cisco's "Application Centric Infrastructure" has in store, but one thing seems astoundingly clear - despite Cisco's posturing around being more open, it will be built on the single most closed, vertically integrated stack since the mainframe.

So Ms. Warrior, with all the massive changes happening across the industry, I think the crux of the issue comes down to trust. Do we trust the company most known for hardware lock-in saying we need more hardware lock-in? Or we do we trust the company that with the open x86 industry has proven over and over again that you don't need hardware lock-in to drive virtualization forward, that had shown it is possible to drive open, industry-wide hardware acceleration, and has done so continually over the past decade. Do we trust the company that self-admitedly has screwed up so many aspects of networking, or do we trust the man who has already turned the entire networking industry, including Cisco, on its head and led us all in the new direction of Software-Defined networiking. As for me, my bet is on the vision of Martin Casado, virtual machine and policy portability and the SDDC with open, transparent & robust hardware.

Disclaimer: I work for Dell, but this is my post and my opinion. By that I mean I woke up this morning, read Ms. Warrior's post and decided to respond to it all on my own. My opinion is not necessarily that Dell or any of its affiliates, partners or subsidiaries.