by
Brian Madden
Citrix's XenApp and XenDesktop products have always had an artificial and somewhat arbitrary separation of features. The more expensive XenApp delivers desktops from terminal server and apps from terminal server, VDI, and streaming servers, while the less expensive XenDesktop is used to deliver desktops from VDI (but not terminal server and no apps.)
A year-and-a-half ago I wrote that this was a de facto “app tax” for Citrix customers, since if you just wanted desktops you could use XenDesktop by itself for about 1/3 the price of XenApp. (Citrix has since reduced the impact of this “tax” a bit by bundling XenApp into higher end editions of XenDesktop.)
Conceptually I’m okay with this. Citrix has a monopoly in the application space so they can charge whatever they want. But there are a lot of options in the desktop space, so Citrix’s desktop product is cheaper than their application product. That would be totally fine if it truly was “XenApp for apps and XenDesktop for desktops.” But while the XenApp part is true (since XenApp can deliver TS apps, VDI apps, and streamed apps), XenDesktop is not the only “desktop” option, since XenDesktop only delivers VDI desktops and offline streamed desktops. If you want TS-based desktops, you have to go back to XenApp!?!
Actually, maybe I shouldn't say "you have to go back to XenApp." Maybe I should say "You can get these TS desktops with XenApp?"
A few months ago, Citrix hired a guy named Harry Labana (blog, LinkedIn, twitter) to be the CTO of their XenApp/XenDesktop group. Harry is super-experienced, having architected VDI for Goldman Sachs (his previous employer) long before VDI really existed. How? He simply used XenApp! (Or MetaFrame or whatever it was called then.) In other words, he still gave each user their own single-user VM, except in his case it just so happened that each VM was actually a copy of Terminal Server running MetaFrame. Harry didn’t need to wait for Citrix to create a VDI product, he just used their existing TS product like it was a VDI product!
In his case the single-user terminal server fulfilled the same requirements as VDI. If it was persistent then it would support user-installed apps. And since there’s only a single user then thre's no worry about the TS app compat issues. Really the only thing you didn’t get with the whole “using XenApp for VDI” is the ability to connect to the VM host to dynamically power on and off VMs for each user.
That all changed yesterday, though, with the release of Feature Pack 2 for XenApp. FP2 introduced a new feature called Power & Capacity Management (PCM) which I wrote about a few weeks ago. PCM can connect to a VM host to power on or off XenApp VMs on-demand. In other words this is exactly what you’d need if you wanted a whole bunch of XenApp servers to be used by only one user each.
My point I guess is that it seems like the only value that XenDesktop brings to the table on top of XenApp now is the ability to run streamed OSes locally on bare-metal clients. If you just want to use XenDesktop for VDI (either VMs or blades), I feel like you can do that no prob with XenApp and just save yourself the extra costs. Heck, Citrix even consolidated the “receiver plug-in for hosted desktops” (the fancy new name for the ICA client) so that the XenDesktop and XenApp clients are one-in-the-same.
So nothing against XenDesktop, and the whole streaming OS to devices thing is cool, but I think I'll stick with XenApp across the board, even for my hosted VDI desktops.
(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.