There has been some turmoil lately in the industry when VMware announced that wanted to join the OpenStack community. In the last few days Martin Casado (Nicira co-founder and now Chief Network Architect at VMware) was quoted in a few interviews for the plans VMware has to integrate, evolve and position the Nicira technology. You can read more about it here and here.
I guess we can summarize the bulk of those interviews in the following quote from one of the articles: “Specifically, Casado says we can expect a hypervisor-agnostic network virtualization platform that could be marketed as an independent product.”
This obviously brings up the tedious topic of… can a platform vendor really become platform agnostic? More on this later.
This goes back to a Nicira slide I built a few months, before VMware bought Nicira. This is the slide I am referring to:
Note I was using that slide for a slightly different argument (which, in turns, was going back to my ABC of Lock-In theory). However what this picture was (implicitly) conveying is that, in order to be in a particular spot of the infrastructure, you do need to be agnostic to the stuff that surrounds you.
vSphere, in the context of a server hypervisor, is agnostic to the hardware and to the Guest OS it supports. Similarly, the Nicira NVP needs to be agnostic to the hardware and hypervisors it supports. Or, to steal Martin’s specific way to put it: “…networking is the one thing that you can’t be a unilateralist with. The network touches everything. It’s the network.”
By the way, in the slide above, you can picture vCloud Director, OpenStack (or whatever) instead of vSphere, Xen, KVM (or whatever). Same concept.
Now, let’s go back to the original question: can a platform vendor (e.g. VMware) really become platform (e.g. vSphere and vCloud) agnostic?
The theory is really very simple and it goes like: it depends where the money flow.
This is how I picture in my head a vendor with a (traditional) platform play and a (new) cross platform play:
The T theory continues by saying: if the vendor is able to make the money in the cross platform play, then the same vendor is willing to concede third party platforms more love (for lack of a better IT word). On the other hand, if the vendor is not able to monetize on the cross platform play, then the same vendor is NOT willing to concede third party platforms more love (and will try to drive and funnel their customers towards the platform play where they can still make money).
Let’s try to make three examples of the T theory.
Did the cross platform play work for IBM? I would say so. IBM is making a lot more profits on the Tivoli product line than it is making on AIX (the mainframe is a tricky story) so they got well past this dilemma of potentially compromising their own platform play by having a cross platform play.
Will the cross platform play work for VMware? Who knows. What we know is that VMware said that there are (a lot of) money to be made in that space though. This doesn’t mean that VMware will push to compromise the platform business with this strategy. However this does tell that, if VMware is able to make money on the cross platform play, potentially compromising the platform play (by working with third parties platform plays) will be worth it. You can go a step ahead and make a parallel between Nicira NVP and DynamicOps but let’s not complicate the discussion too much as there are different nuances there.
Will the cross platform play work for Microsoft? Who knows. What we know is that Microsoft is giving away that piece, arguable a core technology of the data center of the future, for free. Admittedly I don’t have an MBA but to me this means either one of two things: they will try to move people to the platform (where they are still making money) or they are going to charge for that piece (if they want to be in the true platform agnostic business).
At least this is what the T theory says. I realize, however, there are gray areas in it. I am not going to call out all possible nuances to avoid boring you more than I have done already.