Last week I wrote about the four technical capabilities that needed to evolve in order for VDI to become mainstream. Since that article came out, I've started informally calling this "VDI+." So "VDI" is today's SBC-based VDI, and "VDI+" is tomorrow's VDI that blends SBC, local, offline, user customization, etc.
I spent last week on a small speaking tour in Europe, and I was asked by 100 different people about which VDI vendor I thought would get to VDI+ first, and which vendor people should buy today?
This is a complex question and the full answer requires its own article, but in order to begin to build an answer, you have to know which vendors offer which capabilities. To that end, I threw together a quick chart showing the six major players in this space and which of them offer which capabilities.
At this time I think there are eight capabilities needed to offer an end-to-end VDI+ solution: (Am I missing anything?)
- Connection broker. This is the baseline requirement that's need to connect users into the VDI environment.
- User environment management. Some kind of way to customize a shared desktop for individual users, above and beyond roaming profiles.
- Application isolation / streaming. The ability to run applications in a VM without first going through the Windows installation process.
- Hypervisor management. Turn on, suspend, migrate, provision VMs.
- A "workstation" hypervisor / VMM. Some capability to run a VDI VM locally on a client device.
- Ability to use one disk image for multiple users. We're talking about sharing the same master image--not cloning.
- A remoting protocol with 100% app compatibility. The protocol must not just support some multimedia--it needs to support everything: 3D, high graphics, multimedia, perfect audio, etc. On a fast network it needs to work as if the users don't even know they're working remotely.
- Single app SBC publishing. Finally, some apps will still be accessed via server-based computing while running on their own hosts. Does this vendor offer this capability?
A few notes about this chart
In some cases, Microsoft provides baseline capability that vendors can ride on top of. (SoftGrid, Calista, etc.) This chart only includes the specific capabilities that a particular vendor brings to the table. It does not represent what a complete solution would look like for a particular vendor.
This chart includes capabilities that vendors have announced publicly, even if they're not shipping them today. (Specifically Scalable Virtual Images from VMware and Calista from Microsoft.)
An analysis of the chart
Looking at this chart, it's very clear where the various holes are for each vendor. Of course this does not answer the larger philosphical question about whether each vendor needs to fill every hole, but it's interesting data for that discussion. A lot of vendors talk about how being "everything for everybody" is not important and they want to give customers "choice." This mainly happens when vendors have glaring holes in their lineups. But as soon as they build / buy something to fill that hole, they completely change their story and talk about how customers want to go to one customer for everything, and that they want "one throat to choke."
As we go through each of these vendors, you could probably use this chart as a template for "VDI Mergers & Acquisitions, 2008-2009."
Citrix is the closest to providing the full stack. Their biggest hole is the lack of capability to run a VDI image locally on a client device. Maybe they'll look to Microsoft for Kidaro? Or maybe they'll buy someone who offers that capability?
Citrix also needs a better protocol. As I've written in the past, ICA is great, and certainly better than RDP, but it's still not perfect.
Microsoft's biggest hole today is the connection broker. Because a connection broker is the "bare minimum" requirement for VDI, you have to wonder about what Microsoft is planning here. Can they really be content forcing everyone to go to a third party, even for the most basic use cases?
I think we would all love for Microsoft to fix the user environment problem too, although since they haven't addressed this in the past ten years, I wouldn't hold my breath.
VMware is doing really well on the infrastructure side of things. Now they just need to focus on the users and apps. They started down this path earlier this year by buying Thinstall. This shows their thinking is in the right place, but they probably need to buy someone who can deliver single apps to fill out the offering. (Is it too late to buy Quest? Can they buy Ericom?)
They really need something in the protocol space (although they licensed Wyse TCX for their VDI product, so they're getting closer). Maybe VMware's long term solution is just not to use a remote protocol? That's a nice concept, but there will always be use cases for some apps where it just makes more sense to deliver them via SBC.
Ericom & Quest
When I talk about this space, I usually lump Ericom and Quest together because they are so similar. They can both manage a ton of different hypervisors. They both offer a connection broker, good load balancing, a web interface, and seamless application publishing from terminal server or Windows XP / Vista VDI instances. Both companies' products offer capabilities similar to the combined capabilities of Citrix XenApp and XenDesktop, although the Ericom and Quest solutions are about 20% of the price of Citrix.
Quest might end up with the long-term edge against Citrix, because Quest's VDI product is via their Provision Networks division, which they bought last year. It remains to be seen, however, whether Quest will be able to integrate their other products into their VDI solution.
Qumranet is still new to this space, but seeing as they have a shipping product, a perfect remote protocol that no one else can touch, and they were started by XenSource co-founder Moshe Bar, they're definitely worth paying attention too.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.