Fiction Versus Function: Three Unspoken Annoynaces of Cisco & VMware’s Virtualization “Partnership”
I spend a good amount of time thinking about how multiple technology strategies from market leaders coalesce into a reasonably homogenized version of reality in the networking and security space in order to decide where to place bets; it's akin to reading a tell and analyzing a player's betting strategy at a poker table.
I look at Cisco and VMware and can't help to chuckle at the moves being made in the name of "partnership" on the virtualization front and there's an awful lot of twitching going on that doesn't require Phil Hellmuth to decode.
Partnerships are nothing new, but usually they are couched with certain modicum of suspicion and cynicism. However, speaking with folks at VMworld, either folks were high from the Oxygen Bar at the airport, or they were adding naiveté syrup to the drinks because I seemed alone in my concerns…
I've put together a couple of summary points on the matter — more for my own personal enjoyment and note taking than anything else — and framed them in terms of what I find to be really annoyingly obvious examples of these two strange bedfellows' behaviors:
1) The purported cohesion of Cisco's and VMware's virtualization strategies is a simply a matter of converged parallelism and forced perspective.
You've seen diagrams that demonstrate the notion of converged parallel lines, right? If you haven't here's an example:
You'll notice that in this diagram there exists a series of parallel lines which seem to converge at a "vanishing point" on the horizon.
This in fact is not the case. The lines don't actually ever converge, they just look like they do. It's all a matter of perspective. Imagine these lines as Cisco's and VMware's virtualization strategies.
Similarly, the notion of forced perspective is a method by which the manipulation of perspective employs an optical illusion to make something appear closer, father away, larger or smaller than it actually is (see the title image above*.)
The announcements from Cisco and VMware are very much like these examples. Whilst they offer excellent opportunities for improving the management and security of virtual infrastructure, it's very much Machiavellian marketing — the end is going to justify the means.
Speaking to either Cisco or VMware you're asked to suspend disbelief and accept that these two companies share a common blueprint for a datacenter OS, but they don't. In fact, they're quite different, and the balance of who needs whom more is also very lopsided.
Despite the close technical partnership needed to pull off the integration of the Nexus 1000v as the first third party virtual switch (which we've been talking about for almost two years,) Cisco and VMware really are on parallel trajectories in terms of their visions regarding the datacenter OS; how it's designed, provisioned, deployed, managed and governed…and by whom.
Cisco is approaching this primarily as an infrastructure transformation play as a way of clawing back what they lost when the network access layer become absorbed into the virtual hosts while VMware is busy distancing itself from the infrastructure and elevating the discussion to that of the cloud in an effort to stave off Microsoft and Citrix.
Each want to own your datacenter, and while they play nice on the surface, there's really a nasty game of tug of war going on here. This is a marriage borne of convenience, nothing more.
You try and unify Cisco's DC 3.0 vision with VMware's Virtual Datacenter OS blueprint and tell me how they mesh.
2) Dear Virtual SysAdmin: You're fired as the network admin. You're cool with that, right?
It's funny how both Cisco and VMware's marketing folk in the sessions discussing the release of the Nexus 1000v vSwitch, both snarkily (and rhetorically) posited "How many of you Virtual SysAdmins have coordination and communication issues between your virtualization and network teams?"
Leading the witness further, the next question was "Don't you just hate having to fight to get the network teams to give you a trunk port on an access switch?"
They followed that up with "Your prayers are answered! The 1000v will allow you to give the network provisioning back to the network teams and let them control the networking and connectivity. Isn't that great?"
While most nodded away in the affirmative to the first and second questions, I didn't see one audience member who answered positively on the latter. What makes anyone think the vSysAdmins *want* to give up the control of the virtual networking layer and be at the mercy of the networking teams again?
Interesting battle ground for sure. Now, please don't misinterpret my commentary as a suggestion that this is a bad thing, but we're already in the middle of a "West Side Story" turf war over organizational fiefdoms. This will, depending upon what sort of contention exists already, make a really tenuous issue even more so.
3) Software Sucks. Hardware Rules. I hope you like ping pong.
I hinted at this point in my post titled (The Network is the Computer…) The reality is that much like point #1, Cisco could care less in the long term about the Nexus 1000v as a software switch running in someone else's backyard operating environment, but rather introduces it to enable the landscape clawback it gets to enjoy in the short term and make relevant once again it's big network iron in the longer timeframe.
A telling slide was the announcement of what's coming AFTER the Nexus 1000v in one of the sessions that I have not seen presented in detail elsewhere — that is Cisco's goal to extract networking out of the host completely.
The plan as discussed is to utilize what Cisco calls an "initiator" to replace the 1000v and force traffic, after specialized tagging which denotes affinity of flows to specific VM ID's, and ship them straight back out the network interfaces to a waiting Cisco 5000/7000 switch for processing. Hence the ping-pong mention above.
Sorry for the quality of the picture as I took it sitting behind somebody, but here's a slide denoting just this very thing:
The notion of a third party switching capability is really just a way for Cisco to push the access layer back to where they think it rightfully belongs — in the physical switch.
Cisco claims that VMware and they have submitted this tagging specification to the IEEE for review/ratification. I find that very interesting.
I wrote about the need for such a technology at both the virtualization layer and more importantly the application/data level in June of 2007.
Check out my post which described how I suggested Crossbeam do the exact same thing by way of something I called ADAPT (Applied Data and Application Policy Tagging) which describes this very thing. What's next, they're going to announce vNAC? 😉
—
All in all, the Cisco/VMware relationship is about as natural looking as the Microsoft/Citrix version — it's sort of like a midget dating a six foot supermodel…someone's getting the better end of the footrub in that relationship, too.
So, how about it? Am I stating the obvious again — and does it need to be stated?
/Hoff
*image from "The Eye of Brad" flickrstream
You are.. and it does. Well framed. -A.
Reading that and thinking about VMWare and Cisco together really does make my head hurt. Talk about complicating this mess.
We (my company) use virtualization in almost everything we can (minus databases and other servers with special disk requirements), but I am still not sold that this is progress. It is far more complex, and all the lessons sysadmins and netadmins have learned over the past several decades are thrown out the door in favor of, well, praying other parties create these things properly.
At least the network has still been its own entity and managed as it has been.
Oh wait…
It's Tuesday, I had to come in early, and I'm punchy. 🙂
So, how about it? Am I stating the obvious again — and does it need to be stated?
Well it's only obvious you take the time to read all the materials and have seen the presentation. And yes it needed to be stated.
I agree that it needs to be stated. I think the vNetwork announcements and sessions at VMworld were almost understated wrt to the partnership and resulting technology. And since there were so many freakin' sessions this year, this info seems to have only been picked up by the people who sought it out. But I do have some comments on your thoughts (in reverse order):
#3) I think this is the obvious item that does need to be plastered on billboards in San Jose. Cisco is a hardware company and ultimately wants to own the packet in their hardware. Having a [fast|slow]path shim to push the packets out of VMware-land, brilliant, and achieves their goal of owning everything network in hardware.
#2) 2nd'd
#1) I disagree that both Cisco and VMworld are looking to own the entire datacenter. Rather I think they're looking to leverage their respective areas of expertise as the cornerstone to the datacenter. Cisco thinks networking is the most important thing so they're pushing the intelligence into the network; VMware, the OS and the idea of a virtual DC platform (ala their VDC-OS). But I don't see any reason that either one of these players wants to launch the complete end-to-end Cisco/VMware datacenter, nor do I see a conflict between DC3.0 and VDC-OS. DC3.0 is a convergence of network transport; VDC-OS a convergence of platform. Can they live/work together? Absolutely*.
*NOTE: My comments in no way endorse DC3.0 nor condone converged networking technologies. I think they're silly at best, catastrophically destructive at worst. 🙂 But that still doesn't mean I think Cisco is trying to own the DC platform.
– Alan
PS: Saw you in the DVN API partner session but didn't get a chance to swing by and introduce myself. Next time.
@Alan:
So let's take #3 for a bit more of a spin.
Let's say for, um, argument's sake that one was to couple VFrame's provisioning capabilities with a converged networking/storage solution such as the Nexus 7000.
Then, let's say, you leverage the capability of a huge number of cores in said Nexus 7000 to include the capability to virtualize your VMs directly within the switch itself since NX-OS leverages Linux kernel virtualization (which is a heartbeat away with OVF to being able to host VM's.)
What do I need VMware for? In this scenario, Cisco maintains the relationship with VMW with the 1000v, abstracts it with the initiator and the 5000 and is free to then offer a competitive platform to VMware's inside it's own hardware…
/Hoff
@Hoff
Where to start 🙂
#1
I guess I would argue that you want parallelism versus either convergence or divergence. Convergence means that we and VMware, as an example, lock-into a single architecture which eliminates customer choice and folks would cry foul. Conversely, we could each do our own thing and leave customers to try an make sense of it all. Instead, we have a loosely coupled relationship that allows flexibility but still maintains shared objectives. To draw upon your first illustration, if you imagine the lines as railroad tracks, then, in fact they do take you to the same destination, without ever touching. If you look DC 3.0 and Virtual DC OS, they share a common vision–portability of workloads across a fully virtualized infrastructure. Where they differ is scope–DC 3.0 is neither competitive nor interchangeable with DC OS–they are complimentary–DC 3.0 delivers a virtualized automated infrastructure that supports the objectives of Data Center OS . Ed Bugnion covered this in his keynote, but we can always re-visit it here.
#2
Being one of those Cisco marketing people, but not really meaning to be snarky, the questions are really just echoing back the cumulative feedback from customers. Most feel that organizational boundaries have blurred out of necessity and to the overall detriment of the team. Again, no one is being forced into a particular operational model. Some companies have virtualization admins, others don't, but now you have options
#3
So, we do actually care quite a bit about the long-term success of the Nexus 1000V–it represents a significant investment for Cisco and we plan for it to have a long, happy, productive life. The hardware-based approach and the concept of hypervisor bypass is not a pure Cisco concept (check out VMDirectPath) and is complementary, not competitive to the software approach. Each approach has its merits and we expect the typical data center to have a combination of the two. If you remember, one of the design goals for VN-Link was that operations and management should work transparently across different implementation models. This would be an example of that. BTW, if you want, I can shoot you a better image of that slide. 🙂
Anyway, midgets and models aside, I think the true proof of any collaboration is the output. I think you have to agree that the Nexus 1000V is a pretty good start…and there is more to come.
BTW, running VMs directly on the N7K either on the processors or on a dedicated linecard? Not gonna happen–the platform is not built to support that, although it continues to be a popular rumor.
Omar Sultan
Cisco
Hoff,
On "Do we need VMware?," yes and no. I see where you're going (despite Omar's debunking of support for this in the N7K platform ;), and while I think it's a viable option in general, we'll always need specific, tuned products for these technologies. If we could get away with running a VM on any ol' hardware with any ol' hypervisor, we wouldn't see a need for DC-class products like ESX3i; we'd all be running everything on Hyper-V (no disrespect to Hyper-V, it just is what it is today). Even para/kernel virtualization solutions won't get you that, IMO.
This is the Radware approach to DC virtualization: consolidate multiple, completely different, services on one device and your life will be good. You'll never get the level of performance, scale, or manageability with this type of solution you will with tuned-first-then-integrated solutions. That's why I love the idea of partnerships: let the best bring their best to the table and figure out how to make them work together rather than relying on one group to do everything on their own. All-in-one solutions for _different_ services (which is the key) are doable for SMB, but not for enterprise DCs.
-Alan
Well, as usual I can't work my way through your whole post but I would like to stand up for Machiavelli who you chose to slight with your "ends justifying the means" comment. Machiavelli may have given you the impression that he held that view if you read "The Prince" which was basically a little tome he wrote to win his way into the heart of the ruling party and get some sort of handout.
If you read his "Commentary on the first ten books of Livy" you will realize that Machiavelli is a lover of freedom and democracy and hates dictators.
There.
I see this from two angles:
1) Cisco being evil. As we all know, a "partnership" with cisco is something akin to date rape. Cisco will do it to you in the end.
2) Chris – remember compliance and regulatory goals, and how they fit into a virtual environment. Segregation of duties and all that. By abstracting the vswitch from VMware, that separation again becomes apparent, removing the network from the machine once more, and PCI DSS and it's lovers again become sated.
Good that you state "the obvious". It is clearly not a natural fit as you describe it. I would comment that you are leaving out the third party of this odd menage a trois: EMC. The even less natural aspect of this whole "partnership" is the three way joint venture they created and poured some more money and marketing into…