Application Layering questions? I got answers. Graphical cheat sheet included!

Application virtualization (mostly App-V & Thinapp) has been around for some time now, application layering however, is still relatively new. Although assumed by some and theoretically possible in some cases, application layering is not meant as a replacement for application virtualization. In fact, you could say that they go hand in hand. Today there are multiple layering solutions available, and while the concept is the same they all take a (slightly) different approach. By the way, if it’s the (graphical) cheat sheet you’re interested in, I would suggest you scroll down.

App virtualization in general

One of the biggest issues when it comes to application virtualization is that simply not all applications can be virtualized. The more applications a customer has the harder this will be, which makes sense.

Due note that I’m primarily focusing on a RDSH / VDI deployments

Take a look at some the results of this year’s Project VRC (the annual Virtual Reality Check). As the graph shows, being able to virtualize around 50 to 60% of all applications on average is hard enough, let alone even higher.

From what I have seen at various customer sites it’s not uncommon for a mid-sized to larger company to have (at least) a few hundred different applications. And if ‘only’ 60% of those applications can be virtualised (again, on average) you are left with dozens, potentially hundreds even, of applications that you will have to ‘present’ to your users in some other way.

And while cloud based applications are becoming more and more popular, they won’t fit all use cases and primarily apply to new(er) applications in general.

Many older, or legacy applications simply can’t be replaced that easily meaning you will still need to come up with a way to ‘present’ those applications to your users. This is where application layering can help.

The big bad image

So what happens with applications that cannot be virtualized or replaced in another way? Right, they end up in your ‘base’ image. Not something to get very exited about. Let’s have a brief look at some of the cons associated with this approach.

1. It will make your applications harder to maintain and manage. When an application needs to be updated / patched you will always have to make those changes on your ‘production’ image. This could also be true for some of your virtualized applications, which might be pre-cached for example, but at least you have a choice.
2. Although, based on permissions, your users will only be able to see and start what they are allowed to (at least that’s what they think) there will (potentially) be a whole bunch of applications on the base image that need to be shielded and/or hidden so users will be unable to locate and start the them. Not to mention that although not used by everyone, all applications will still need to be patched and updated.
3. The same applies to adding new, and removing old applications, it’s not dynamic, at all.
4. You will have a hard time installing and maintaining multiple versions or editions of the same software.
5. Your image might potentially grow up to hundreds of GB’s. This doesn’t have to be an issue per se, but it sure can be.
6. I have come across (multiple) applications that needed to be updated on a weekly basis, or twice per week even. Queuing the updates and applying them once every two weeks or perhaps only once a month is far from acceptable in most cases. Can you imagine the horror?
7. It’s not that hard to see how all this will negatively impact production and not to mention your users. Think about it, when updating and thus changing a production image, with most companies it will need to be retested and ‘accepted’ each time before taken back into production as part of their standard ‘change’ protocol. This will take one or two day at a minimum, and that’s fast, trust me!
8. This could easily force you to create multiple images / silo’s, based on departments for example, while it should be, less is more.
9. Another consideration might be the use of fat clients (niche software) or another form of persistent desktops, which you might not want to do, preferably.
10. Application lifecycle management becomes much harder.
11. And there is more to consider.

Bring on the layers

Although this post isn’t meant to give you a detailed technical explanation on how layering works, and this will also differ per product (vendor), here’s a simplistic explanation on what it is about… First an application gets installed / captured on a VDH or VMDK file (virtual hard disk).

This virtual disk will then be mounted onto a virtual machine (assigned to a user or machine, this also differs per layering solution). In some cases a so-called in-guest mount is also optional making layers available to physical machines as well.

Almost without exception all application layer vendors make use of (mini) filter drivers a.k.a. write filters (write when capturing data and read when the application is in use) residing in the base Operating System to ‘manage’ the file system containing c:\ etc. These ‘filters’ will also make sure that all application layers mounted to a machine will be seamlessly merged into the file system making them appear as if they were installed locally, including any .ini, .dll’s, registry entries and other files that may come with it.

From there on any ‘calls’ made to the file system, when launching an application for example, will be ‘filtered’ and directed to the appropriate application layer, or VHD / VMDK file.

How do they help?

Some might argue that using an application layering solution ads yet another product to the stack, it’s another ‘technology’ and potential interface that admins need to get familiar with. It will also come at a certain cost with regard to purchasing the product, licenses and so on. Applications will not be isolated like with app virtualization for example. However, these cons, if you can call them that, are soon forgotten when you have a look at some of the pros that come with application layering. For example…

1. As for the ‘another product to the stack’ argument, yes that’s true, but if you forget what is going on under the hood technology wise, which is easily done, then learning how to deal with layers (creating, assigning and updating them) will probably only take you a couple of hours max.
2. Another GUI? Perhaps. But if you are a VMware or Citrix shop for example, then go with App Volumes or App Disks once it goes GA. The impact on your existing product stack will be minimal. And who cares about ‘another’ GUI if it helps you solve some major issues.
3. About the costs. I don’t have any list prices to share, but just think about what you would have to do, and how much time and effort it will take managing all your applications, or environments that you might be managing as a consultant, when taking the ‘traditional’ route.
4. No isolation. Yes. But if applications can’t be virtualized there’s usually a reason for this. I mean; being able to interact with the underlying OS and any applications or other resources that might reside on there can be an advantage just as easy.

What about some of the (other) pros…

1. No more applications in your base image, with a few exceptions free for you to choose.
2. You might end up with just one ‘golden’ image, maybe two.
3. No need for physical or other type of persistent machines if you don’t want to.
4. Applications can be managed completely independent from each other, on a per layer basis if you will. Even on different time schedules or ‘on the fly’ if needed, without impacting your production environment.
5. It also works for drivers, add-ons, plug-ins and so on.
6. Applications can be added and removed dynamically, the user does not have to log out, reboot etc. When a layer has been added the application icon will appear almost instantly on the users desktop, same with removing layers.
7. They all work on top of your existing infrastructure, leveraging Active Directory for layering assignment to users, groups of users, machines and so forth.
8. Non-persistent desktops…
9. Support for all Hypervisors (does depend on solution chosen) and works for all major RDSH and VDI platforms out there.
10. When combined with a personal data / app disk (optional in most cases) you can achieve persistent desktops but still maintain all the advantages of non-persistent.
11. Most application layering products have build-in application lifecycle management capabilities.
12. Reduces storage, compute and network costs. Not to mention the time it takes to rapidly ‘package’ and provision applications to users. Including overall management.
13. Layering and application virtualization go hand in hand.

Some specifics

This is where it starts to confuse people. To start, when thinking about implementing an application layering solution there will always be a few (basic) questions you have to ask yourself (or out loud) with regards to the platform you are supporting or going to support.

1. To start, is it Citrix XenApp / XenDesktop, VMware Horizon / View or maybe ‘plain’ Microsoft RDSH that you want to support?
2. The same goes for supported hypervisors. Depending on what you are using your options might be limited to a few vendors.
3. Is there a steep learning curve?
4. Does it need to work for persistent as well as non-persistent, and does it?
5. Do we need to be able to assign layers to users, machines or both?
6. Does it support both VHD and VMDK’s?
7. Can we assign layers to virtual as well as physical machines?
8. How about the rest of the vendor product portfolio, do they offer anything else that might benefit us combined with application layering?
9. For example, do they offer a (persistent) personal data / app disk solution? Would I like to use it?
10. A user profile solution (based on layering as well) perhaps?

Application Layering Cheat Sheet

Since not all vendors support all use cases, and it can be hard to keep them apart, I thought it might be helpful to put together a simple but, hopefully, effective application layering cheat sheet. To keep it from spreading onto multiple pages I focused on five of the major vendors within the app layering playing field today and answered questions with regards to, which Hypervisor, virtual and physical, persistent and non-persistent support, assignment to users and machines etc… I’m aware that there is still some info missing, but again I wanted to keep it as ‘portable’ as possible. Please let me know what you think.

There is a version 4.0 available. Click the download button below to get your copy. 

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.