Quoting Interop News
After my post two weeks ago about Xen, I got a call from the XenSource people. I had a long chat with their CTO Simon Crosby, who had some very interesting things to say.
He confirmed that XenSource has reached 500 customers, and added that they are doubling their customer base every quarter. Obviously this can't go on forever, but it looks like they are seeing a nice little exponential spurt of adoption. These are mostly mid-market customers, though they are starting to see a few site license deals. Crosby says Xen is being pulled into enterprise and production environments sooner than they expected. I suspect most of these larger deals are hosting-related in one way or another, such as the Amazon EC3 example, where Crosby says they have 3,000 servers under Xen.
Crosby also shed some light on the changes in XenSource's go-to-market strategy. A few years ago their plan was just to deliver the best hypervisor they could, and rely on the Linux distributors (Suse and Red Hat) to take it to market. But the results of this approach to date haven't been terribly exciting, so the new strategy is to sell a full-blown competitor to VMware's ESX, that is, the hypervisor plus the entire management and infrastructure framework. XenEnterprise 3.0, released last year, was the first big step in the implementation of this strategy. The next major milestone will be the release of XenEnterprise 4.0, set for later this summer.
One key point about XenSource that they don't go out of their way to emphasize is that their offering is a hybrid of open and closed source. The Xen hypervisor itself is GPLv2, while its system-level APIs come under a "BSD-like" license which is friendly to closed source OEM partners. But the XenEnterprise management tools which use those APIs – and which for evident marketing reasons they are calling XenCenter – are plain old commercial software. There's nothing wrong with that, of course – this company isn't exactly crushing anyone under its proprietary boot. Their reasoning is that if they released all of their stuff under GPL then Red Hat would just scoop it up and serve it in place of the very inferior management tools bundled into RHEL5.
The story behind the "BSD-like" license governing the Xen APIs is also interesting. According to Crosby, use of the Xen trademark (as distinct from the GPL code) is restricted to software developers who respect both the APIs and the ABI (application binary interface). This requirement has produced some friction with Red Hat, which as a result has stopped using the Xen trademark, leaving itself free to pursue what Crosby calls "proprietary software published openly," as exemplified by the libvirt API in RHEL5. Crosby argues that the ABI policy guarantees you can take a VM out of the freezer ten years from now and still be sure it will run on whatever version of Xen is current then. This isn't the way operating systems traditionally work, of course. You can't just take every application and driver that worked with Windows XP and expect it to work with Vista. But these days people use virtual machines as portable containers for their applications, so you need to be sure that new versions of the hypervisor won't break the ABI.
Interestingly, Crosby points out that the most common workloads running on VMs these days - regardless of the hypervisor used – are legacy versions of Windows, especially Windows 2000, because that's where the largest number of legacy apps have accumulated in customer data centers. By contrast, since the big growth in enterprise Linux has occurred only in the last few years, a higher proportion of Linux apps are running on more recent versions of the OS, and thus don't require as much VM-based "containerization."
There's a lot more to be said about the parallels between what XenSource is doing and the VMware approach. I'll try to cover some of these issues in my next post.
Read or comment on the original, here.