I've given a "TS versus VDI" presentation several times in the past. It began at BriForum 2008 Chicago, where I co-presented the topic with Benny Tritsch. In that presentation, Benny dressed up as the mature, "proper" solution (as TS was in those days) and argued the case for TS, while I dressed up as the young scrappy VDI:
Our general conclusion from 2008 was that VDI was too risky and complex.
I presented the topic a third time at VMworld 2011 where I argued that VDI might actually have a chance, especially when it came to persistent images, but still in most cases RDSH made more sense.
Believe it or not, I'll be giving this session again (at Citrix Synergy in May and perhaps at BriForum), so I thought I'd share my thoughts about where the TS versus VDI debate is in 2015. (Well, first, I guess I should change it to "RDSH versus VDI."
What is the "RDSH versus VDI" debate about?
To take a step back, the fundamental question I'm trying to answer is how you know whether you should use an RDSH- or VDI-based solution for a particular group of users. When I say, "RDSH", I'm not talking about pure Microsoft-only RDSH, rather, I'm talking about RDSH-based application and desktop delivery solutions including Citrix XenApp, VMware Horizon 6, and Dell vWorkspace where you have a "session per user." And when I say "VDI," I'm talking about Citrix XenDesktop, VMware Horizon (6/View), and Dell vWorkspace where you have a "VM per user."
I'm also assuming here that "VDI" is based on a client-based OS (like Windows 7) and "RDSH" is (obviously) a server OS. For RDSH, I'm not necessarily talking about single-user VMs based on Windows Server OSes, though that's an option too.
Also, to be clear, I don't think this is an "all or nothing" proposition. Certainly within companies there can be a use for both, and I don't want to be dogmatic about one or the other.
RDSH and VDI are actually very similar
The most important thing to know about the "RDSH versus VDI" debate is that the two solutions are actually very similar. They're both about Windows instances running in a datacenter (whether on-premises or hosted), and they both can involve delivering full desktops, seamless published applications, or a combination of both.
In today's world, both RDSH and VDI use the same protocols and can deliver the same end user experience.
So this debate today is really just about the underlying platform.
Historical debate points
The main reason we're having this conversation in 2015 is that a lot of the advantages of RDSH or VDI in the past don't apply anymore. (This is why I need to make a new presentation, since if nothing changed then I would just tell people to watch the videos of the old presentations.)
But consider the following:
- In 2015, both RDSH and VDI can deliver full desktops or single published apps.
- In 2015, both RDSH and VDI can deliver either persistent or non-persistent desktops.
- In 2015, VDI technology is more "proven" and not a crazy fringe idea.
- In 2015, non-persistent VDI images can automatically be spun up as users login and destroyed when the log out, so the "automatic" management advantages of RDSH don't apply.
RDSH versus VDI in 2015
So where's this leave us in 2015? Honestly there's only one major difference that I can think of: RDSH is a server OS. VDI is a client OS.
Of course you're thinking, "umm . . . duh! That's in the name!" But it's a key point.
A major advantage of VDI is the mere fact that VDI sessions run the same OS as all the other non-VDI desktops in your environment. This is important for several reasons.
First, since no enterprise is going to go 100% VDI, running your VDI sessions on the same OS as your traditional desktops and laptops means that everything is "the same."
- You can use the same base image for all your users, regardless of whether they're accessing a remote or a traditional desktop.
- You install your apps in the same way for both remote and traditional users.
- You only need one set of instructions to support everything.
- Your patch cycles are also in sync because you don't have to worry about Windows Server patches coming out at different times than Windows client patches.
- You can also run the same OS for all your users, which means you have the same support lifecycles and the same versions of everything.
Contrast that to using RDSH for some apps and desktops while using Windows 7 for everyone else. Service Packs are different, and you have to have extra steps in all your support to figure out whether you need to follow the Server or the Client procedures.
Another thing that's still a reality in 2015 is that occasionally you do come across apps that don't work out of the box when installed on a multi-user RDSH server. Sure, there's a lot you can do in order to tweak the server to trick the app into running on RDSH, but meh, if you just use VDI with a client OS then you don't have to worry about anything.
Really the only reason you'd be forced to use a server OS is if you're a customer of a hosting provider (like DaaS) where Microsoft's license agreements don't allow them to sell Windows Client as a service (though in most enterprise DaaS environments you can provide your own Windows Client licenses for instances of Windows desktops that they host).
The bottom line
At the end of the day, in 2015, the main difference between VDI and RDSH is the simple fact that you're talking about a server OS versus a client OS. Any slight density advantages you might have with RDSH are swallowed up by the additional support costs generated by the fact that you're supporting multiple OS platforms for your users.
Again, to be clear, I'm not suggesting that you go out and migrate all your XenApp Servers to XenDesktop VDI environments, and I'm not suggesting that RDSH or XenApp are going away anytime soon. Certainly if you just need to publish a few apps here and there, it might be easier to just stand up a few RDSH servers and publish those apps from there.
But if you're talking about the platform to base full user desktops on, in 2015 I'm really leaning towards VDI for that, if for nothing else than the ease you get by having all your users being the same across the board.