“Thus it is that in war the victorious strategist only seeks battle after the victory has been won, whereas he who is destined to defeat first fights and afterwards looks for victory.”
Sun Tzu, “The art of war”, written between 476 and 221 BC (approximately)
In the fog of the datacenter virtualization war, it is difficult to see clearly who will end up on top, and yet the outcome is almost certainly determined, and the victorious generals are even now moving on to fight new battles. Here at the Virtualization Practice we too would like to think we can see through the fog to work out who has won, so here are our thoughts, take account of them as you wish. They concern, primarily, the big four protagonists: Microsoft/Hyper-V, Citrix /Xen, VMware/vSphere and Red Hat/KVM.
First two points which inform the debate about the way virtualization has developed in the market place to this point.
1) Although present in many historic O/S from time immemorial, there was very limited virtualization support built into either Unix or Windows, thus allowing a new vendor (VMware) to enter the market to provide that feature.
2) Through a process of adding features to subsume competitors’ market spaces, operating systems had become very large and monolithic which meant (at least in the case of Windows)
- the User Interface has become unnecessarily connected to the underlying O/S kernel, thus requiring at least Presentation virtualization to allow multi-user access.
- It took a significant amount of time for Microsoft to separate out a kernel and a set of management interfaces to provide an efficient standalone virtualization platform.
The key point about the hypervisor is that it is all, and yet nothing. The hypervisor is the control point, and yet ultimately such a small piece of the code base. You will end up paying nothing, or almost nothing for it, and yet from a vendor’s salesman’s perspective once you have their hypervisor, they have you on the hook.
Of the “big four”, perhaps the easiest to deal with is Citrix . In many ways Citrix isn’t really in the war at all. To Citrix, Xen is a tactical product not a strategic product. Citrix provides the extra layer of functionality to third-party operating systems, particularly Windows, that allows them to function effectively in an Enterprise environment. The problem has been that increasingly VMware was moving from providing the base hypervisor to offering this additional layer, and the two were competing head-to-head.
To counter this threat, Citrix acquired XenSource which allows it to push down the price of the hypervisor to hit VMware hard during its transition to a tools vendor. Since Xen and Hyper-V are very similar at an API level it can do this for both Hyper-V and Xen with little additional engineering overhead, and its salesmen make no more or less commission if the customer uses Xen or Hyper-V so they don’t have to sell head-on against Microsoft with whom Citrix has a long term symbiotic relationship.
Citrix ’s acquisition of XenSource had the side-effect of unsettling the Linux community because Citrix acquired control of the virtualization strategy of Red Hat, Novell, Sun and Oracle. Don’t let vendors fool you that because a product is Open Source they have ceded control to the Open Source community. They own the source code, they write product enhancement plans, they decide which bugs get fixed and which don’t. If you are Novell and you have an urgent bug-fix requirement, yes you can change your copy of the Xen code-base but you can’t then force Citrix to put that bug-fix into the main code base, and if they don’t, you end up bifurcating the development stream.
Control is only ceded by the creation of an open source foundation (like Apache or Eclipse) with a proper set of by-laws and governance. Again, don’t let the vendors fool you into believing that the foundations exist just because they have a “.org” domain name. If you run “whois” over Apache.org and Eclipse.org you will find them owned respectively by The Apache Foundation and the Eclipse Foundation. This is good, the independent foundations have proper governance. If you run “whois” over linux-kvm.org and xen.org you will find them owned respectively by Red Hat and XenSource (the company acquired by Citrix). Neither “.org” exists as any form of legal entity other than a domain name.
Obviously, Red Hat couldn’t let Citrix control its virtualization strategy and so within 10 months of Citrix acquiring XenSource, Red Hat paid $107 million in cash for Qumranet, a company that was “not expected to contribute materially to revenue in the fiscal year ending February 28, 2009”. It persuaded Linus Torvalds that KVM was the only thing worthy of his kernel, and thus Red Hat regained a control point and a hypervisor to build its strategy on.
Microsoft’s story is well known. It was tied into the log-jam of its 2008 server release cycle, and a point release thereafter was required to allow it to enter the marketplace with Hyper-V. The late entry caused some consternation at the time, but Microsoft is known for succeeding when it enters a war late. Maybe it just has better Generals than anyone else.
So now Red Hat and Microsoft, probably the two victorious generals, are properly entering the fray. Both Microsoft and Red Hat will be making the same argument that since your datacenter already contains a mix of Linux and Windows, it doesn’t make sense to bring in a standalone hypervisor, and you should be choosing one or other of RHEL or Windows to virtualize both Windows and Linux guests.
Few datacenters will be entirely Windows or entirely Linux. Customers with a dominant Linux agenda most-likely will choose RHEL to virtualize, those with a dominant Windows agenda most-likely will choose Hyper-V. By tying the hypervisor choice to the dominant operating system choice, both Microsoft and Red Hat hope to marginalize VMware, and since these two dominant players will both be telling the same story, there is a good chance that the strategy will succeed.
And so to VMware. Of course things are going to get harder for them, but what is the end-game? The key here is IBM. In the long term IBM is probably as concerned about Red Hat as it is about Microsoft. Red Hat dominates Linux, and IBM is reliant on Linux across its product range. IBM can’t keep bank-rolling Novell and pretending that there is an even fight between Suse and RHEL. Hence IBM’s interest in OSGi, the runtime referred to in our earlier post, which allows enterprise Java applications to run in a low-footprint environment. And so, given VMware’s acquisition of an OSGi runtime with Springsource, and a mutual concern about both Microsoft and Red Hat, VMware and IBM are aligned.
IBM to buy VMware? You heard it here first.
Comments are closed.