by Paul Stansel, CTP, CT-RI CUGC Leader

I’ve been doing this a long time. Some days it feels like way too long. And for years now there’s a pretty common theme that has been talked about, presented, and sold as fact… That with a little bit of work you can have ONE image for your entire VDI environment. And maybe that’s true if you have 20 VMs, or 50, or maybe even a hundred. If you have a homogeneous workforce and a small enough application population maybe you really can get away with a single image and MCS. But unfortunately for me most of what I deal with these days consists of installations in the thousands or even tens of thousands. And that single image concept has been a dream for larger installations.

But maybe we’re finally at a tipping point that can change that. Maybe, with the expansion of the layering landscape, we really can achieve the dream. Let’s talk about the common issues facing a single image infrastructure:

1.    Too many apps to install them all into a single image

2.    No one has ever bothered to create an accurate profile of apps by line of business

3.    Your users get angry because they install apps and those apps disappear when they log off

What those three issues lead to is persistent VDI and an expensive cost per seat. And that’s why for years what I’ve seen is persistent VDI ruling the landscape. It was simply too much work to do anything else, cost notwithstanding. I can’t tell you how many industry events I attended where a poll of the room showed 85% or more on persistent VDI.

But enough of that. It’s a new day! Let’s talk about layers. There are several players in the layering space. I would argue Unidesk and AppVolumes probably see the most usage, though FlexApp from Liquidware might also lay claim to that title. There are other technologies also starting to emerge on the scene as well. Things like Docker or even the new Windows Server technologies have been mentioned as layers but they are more properly containers since rather than slide in to a base OS they contain their runtime environment entirely within their bubble.

Here is a traditional looking install stack:

And here’s what it looks like with layering technologies instead:

Now, I don’t want to give the impression that every company does it the same way. Unidesk for instance manages the entire stack from the image up, actually replacing some of the Citrix functionality. AppVolumes and FlexApp mount on top of the OS and inject into whatever the client is, from physical to virtual. But at the end of the day the point is that using a layering technology in conjunction with your XenApp or XenDesktop deployment gives you an incredible amount of flexibility in your design. Problem #1 is eliminated because you are putting minimal code in your base image, and #3 is eliminated because you are giving your users a writeable volume where they can in fact install their own apps if they need to.

I know there are some of you wondering though about two other technologies and their place in this brave new world. What about AppV and PVDs? After all, for years now Citrix has pushed those technologies in conjunction with XenDesktop as the solution to get you to a non-persistent desktop. Let’s tackle AppV first. AppV has a tremendous amount of possibility. I’ve loved the concept since it was first acquired by Microsoft back when it was Softricity. But in every Enterprise I’ve seen the AppV deployment gets hung up between promise and reality.

The promise is everything can be AppV’d. The reality is a lot of stuff can’t, and even if it can sometimes it shouldn’t. Companies go all in on AppV and get stuck in the face of hundreds or thousands of apps that all need to be repackaged, tested, and deployed again. That often requires man hours and budget dollars that your internal customers never signed up for. It takes a lot of resources and buy-in for a large customer to move to AppV in any great numbers. There’s also the problem that many customers choose to use SCCM as their AppV deployment method. It works, but in a non-persistent environment it’s too slow. You really have to use the AppV5 server technology to make it play well with non-persistent, non-static machines. That’s not to say AppV doesn’t have a place. What it can do that no layering technology can is create isolated bubbles to run multiple conflicting applications at the same time. So if that’s your use case then yes, AppV still makes a lot of sense.

PVDs are of course a completely different animal. Citrix acquired the technology years ago when they bought Ardence and… it’s pretty much remained the same since. Full disclosure here, I have never used PVDs in a production deployment. Every time I tried to use them at any scale in testing they were too easily corrupted and limited your flexibility by locking users to a specific machine even in a non-persistent pool. You can’t deliver additional apps as a PVD layer, it just becomes a space where things get installed to and settings are saved.

There’s been a lot of grumbling over the years about PVDs, and with the newer layering technologies that grumbling has increased significantly. People are seeing what could be and are wondering why Citrix didn’t do something similar with PVDs years ago. Frankly, I was stunned they didn’t step up and buy CloudVolumes (previous name for AppVolumes) since it seemed like such a great fit. With the recent Sanbolic acquisition I think you are going to see renewed focus on the PVD to create an actual layering solution. I just hope it doesn’t come too late to the party.

So layering is all good and everyone should use it and we will all have just one image forever, right? Not so fast. We are ignoring Problem #2. ANY delivery method, from silos to layers, requires you to have a handle on the association between your users and the actual apps they need. Yes, a writeable personal volume alleviates some of that but if everyone still just installs their own apps then what was the point? To bundle apps into a departmental layer and deliver them to the base streamed OS, you need to know what to put in there! And that’s the technology that doesn’t come as part of any of these packages. You need something like a Lakeside Systrack or Liquidware or even RES to report on actual application usage over a large sample of clients.

And beyond that there’s still the simple fact that not every app likes to be layered either. Yes, the technologies support a broader base of applications than say AppV. But I’ve had plenty of problems with packages in AppVolumes for instance that just didn’t seem to want to run, or lost their licensing every time they were re-layered, or conflicted with something in the base OS. You also need a good distributed infrastructure to handle layered applications and the read IOPS that they can require. And finally there can be the issue of delays in launching an app as it streams into the OS. Your network design needs to be able to handle all that traffic that now flows from the mount points of those layers.

What this adds up to is simple… no, there is no one image. Some apps will ALWAYS need to be installed, and sometimes it will make a lot more sense to have a disk for a specific Line of Business. But you can get a whole lot closer than you ever could in the past. Places with hundreds of gold disks (I’ve seen it) might instead need dozens as the very LOB-specific apps get moved into layers. When you think about layers in terms of your business continuity or DR strategy it gets even better. And when you realize some of them at least can even work with physical PCs, it absolutely rocks. Am I excited about layering? Heck yes! And someday, maybe we really will only have one image. Or, you know, everything will be webified.