Citrix's release of XenDesktop (and VMware's crazy response) are still dominating my thoughts this week. Back in January, I wrote that Citrix XenDesktop would be a stronger product than VMware's VDI offering. Now that XenDesktop is real, I still prefer XenDesktop over VMware VDI (and for the same reasons I did in January). But instead of saying XenDesktop is stronger, perhaps it's more appropriate to say that XenDesktop is the less incomplete of the two?
Many of you know that I love the concept VDI and that I think VDI will ultimately replace TS-based desktop virtualization in a few years. (In fact, I'm taking the "VDI" side in the "VDI versus Terminal Services" debate at BriForum in a few weeks.) But I want to point out that I love concept of VDI if it's done right. And today, neither Citrix nor VMware do it right. (For the record, I am 100% convinced that both Citrix and VMware will do it right after a few more product revs—maybe after another 18 months or so. But today VDI is largely a hypothetical mental exercise for me.)
The fact that today's remoting protocols have some limitations seems lost on VMware and Citrix--at least in their marketing messaging. For example, the only "real limitations" of XenDesktop that Citrix's Sumit Dhawan mentions are "offline access requirements or advanced peripheral support." In last week's letter to partners, VMware's Jeff Jennings wrote that "One of the main value propositions of a virtual desktop is that all your applications work in a VDI environment." Neither vendor mentions the real inconvenient truth—that neither ICA nor RDP can remote all applications.
How important is it that the remote display protocol does "everything"?
Citrix's ICA protocol is light years ahead of Microsoft's RDP protocol, which is the protocol VMware uses for their VDI solution. (Unless you buy specific thin client devices—err, "desktop appliances"—that include other protocols, like Wyse TCX.) In fact I think that ICA is a huge reason to use XenDesktop over VMware VDI. But like I said, ICA still can't do everything.
How close is ICA to doing "everything?" 90 percent? 92? 99?
Actually it doesn't matter. Because anything less than 100.00% means there will be some use cases where ICA (and therefore XenDesktop) doesn't work. And if this is the case, then a customer will need some method in addition to ICA to deliver 100% of their apps. And if they have to introduce an additional method, who cares whether they have to use that additional method for 1% or 5% or 50% of their apps? Once they break that "additional method" barrier, they've just added huge complexity to their environment.
Think of it like this. If a customer cannot remote ALL of their apps, then they have to start start making choices about which apps get remoted. They start going through their app list one-by-one, saying yes, yes, yes, no, no, yes, no, yes... They ultimately end up with a mixed solution of some remote and some local apps.
A mixed solution of some remote apps and some local apps.... Sound familiar? It should, because that's exactly what everyone is doing today. Some apps are installed or streamed locally, and some are delivered remotely via TS-based solutions. This is fine, and widely accepted.
What's the value of partial VDI?
Most people would probably agree that the concept of VDI would be cool if it would work for 100% of desktops, users, and apps. Everyone agrees that we're not there yet—at least not with Citrix or VMware. So "full" VDI is a future concept.
If today's environments are a mix of local and remote, and if today's VDI only works in certain use cases, why even bother introducing VDI into an environment if it can't get rid of the TS-based apps and the local apps? Now you'd just have three different app architectures instead of two. (With the new architecture introducing a whole new set of servers, products, costs, and complexities.)
Citrix's Sumit Dhawan blogged about the value that XenDesktop can add to an existing XenApp environment. Quoting directly from his blog, Sumit listed three three benefits of using XenApp to deliver apps into XenDesktop:
- Dynamic provisioning of virtual desktop implies that a user's desktop always stays pristine with no apps installed - all apps are delivered (using streaming or hosting technologies) enabling an on demand assembly of personalized desktop at the time when a user logs on.
- Predictability and Capacity planning on VDI - Separating all LOB apps that have unpredictable (problematic) resource requirements, and running them on separate XenApp servers, prevents over-provisioning the VDI server architecture and can reduce the number of servers required for virtual desktops, improving the TCO of virtual desktops.
- Application and license management - each app can be controlled granularly. You have complete visibility into who has access to the applications and who accessed which application when.
I don't fully agree with any of these points. To each, I respond:
- True, but if you're using XenApp for a shared (stateless) desktop, then why even bother with XenDesktop? Why not just serve desktops from XenApp?
- True, but (again), why even bother with XenDesktop? Why not just build a XenApp "desktop silo," and serve the desktops in a much most cost effective way from a TS-based XenApp server that double-hops to XenApp published apps?
- True, but (again still), why add XenDesktop to this mix?
I agree 100% with Sumit's three listed advantages listed above. However, these are advantages of pure XenApp environments with app silos plus desktop silos. These are NOT advantages of combining XenApp with XenDesktop. In fact, this points to disadvantages of XenDesktop, because it just adds extra cost and extra complexity into an environment.
So for the general desktop user, why even bother? Sure, much like Terminal Server, there are very specific, very niche scenarios where VDI makes sense today. And for these cases, great! Go for it! Use VDI. But for the general user population, the industry needs a display protocol that works for 100.00% of applications. If even 1% of the apps don't work, a customer would have to build out some additional solution to deliver those apps. And if that's the case, then why even bother with VDI? (By the way, Qumranet and Teradici get a lot closer to 100.00% remote display protocol app compatibility today. I'll write more on those two solutions next week.)
Citrix's other ICA problem: ICA on XenDesktop is NOT the same ICA that's on XenApp
I wrote about the implementation of ICA in Citrix's XenDesktop product called PortICA a few months ago. Now that XenDesktop is out, Citrix has confirmed that several of the ICA features in XenApp are not available in the implementation of ICA in XenDesktop. And they've done it in the typical Citrix way—they've hidden and spun the crap out of it. Check out the quoted text from the official Citrix.com XenDesktop Technical FAQ:
Q: How do the ICA capabilities in XenDesktop compare with that in XenApp?
A: All of the ICA functionality of XenApp 4.5 FP1 is available in XenDesktop. The following are not yet supported:
- Kerberos SSPI or SmartCard Virtual Channels
- SpeedScreen multimedia acceleration & zero latency
- PDA sync, TWAIN, shadowing and SmartAuditor
- Audio on Vista
- ICA perfmon counters (SMC) and end-user experience metrics
I love how they say "all" of the functionality is supported, but then go on to list a bunch of thing that are not supported. :) I also love how they have five bullet items, but they put stuff like shadowing and PDA sync together on the same line to pretend like it's only five things that aren't supported, when really it's more like eleven. Sigh!
I'm sure ICA will get there. Maybe Citrix will license something like Qumranet's Spice protocol or Teradici's PC-over-IP (and call it ICA-plus)? Maybe VMware will license something? But until that time, XenDesktop and VMware VDI are niche solutions only.