What’s the state of application layering in 2018?

Maturity level

The technology itself has been around for years—it all started over 10 years ago with companies like Moka5, RingCube, and Wanova, even though the products back then had a different approach when compared today.

A couple of weeks ago Jack and I had a brief discussion around the enterprise readiness of app layering in general. In the end, we both concluded that, especially with some of the major players investing heavily in this space, by now, it has “arrived.” As an end user community participant, I’ve also noticed that the buzz around app layering products, and the interest in the potential added value they offer, has grown significantly.

Is it the silver bullet we were all waiting for? No, it’s not. Does it have drawbacks when compared to, for example, app virtualization or the more “traditional” ways of taking care of business? Sure it does. However, application layering—when used in the right context or use case—can also make the life of an IT admin a lot easier.

A (very) high-level overview

Even though the purpose of this article is not to explain how application layering works from a technical point of view, it never hurts to have an overall understanding of what happens under the hood, so to speak.

In short, application layering is a technology for delivering applications that run in individual layers (virtual disks). They run separate from a virtual (or in some cases physical) desktop, but interact with the operating system and other applications as if they are installed natively on the base image or hard drive.

Instead of installing an application directly on a hard drive or a base image, applications are captured/installed on a Microsoft virtual hard disk (VHD) or VMware virtual machine disk (VMDK) depending on the product and/or your preferred approach. This is what is referred to as the actual layer.

The virtual disks (layers) are stored on a network share of choice, where they can be made available to users and machines. For this, in its most simple form, Active Directory groups can be used. On boot, during a user login, or (in some cases) on-demand, a VHD or VMDK will be attached to the machine of the user; depending on the product in use, multiple options might be available.

The above works for single user as well as multi-user systems.

When an application layer is in use, so-called (mini) Windows filter drivers make sure that all traffic to and from the layers is being managed in an orderly fashion—think of it as a traffic cop making sure nobody moves before they are allowed to.

Again, this is only meant to give you a high-level overview on how app layers work. The underlying technology is a lot more complicated.

The problem we're trying to solve

We are trying to solve for the complexity of managing applications in general, and more specifically, the management of golden/master images.

 Depending on who you talk to (app layering vendors included) the idea on how to use and apply application layering can, and probably will differ per person. For example, like Brian explained back in 2016 in a series on app virtualization, layering can be an excellent way to group or bundle related applications based on, for example, geographic location, or depending on the department (e.g., finance, HR, etc.), making them easier to manage (test, update/upgrade, patch, remove). And I have to say I agree, especially when it comes to larger organizations where hundreds or thousands of Windows applications are being used.

However, most of the companies I’ve worked for and visited throughout the years aren’t large enterprises. Most have around 150 to 200 applications in use, some a few more, some less. Here I also like the idea of being able to create a layer per application, allowing me to update the application on an individual basis whenever I feel fit (perhaps during production hours even) without affecting the base image, or multiple other applications as part of that same layer. This applies especially for applications that need a tighter integration with either the underlying operating system or other applications, which can be more difficult to accomplish with technologies like application virtualization. Of course, bundling applications is always optional as well.

When should I use application layering?

Many people I have spoken with in the past (and recently) have asked me how application layering holds up against application virtualization, and why or when to use one over the other. Personally, I see application layering as another tool in the toolbox, so to speak—use it where it makes sense. What I mean by this is that you don’t have to use one over the other. Both have their pros and cons, and ideally you should consider using both app layering and virtualization, one complementing the other.

Where virtualization creates a “bubble” isolating the application from the rest of the OS, and thus other applications as well (exceptions are possible, I know), layering does not. With application layering there is a much tighter integration with the underlying OS since the VHD/VMDK is mounted directly on top.

Knowing this, you can probably imagine how these two technologies can work side by side. Of course, you are free to try and use layering exclusively to see how far it will get you, though I think it is safe to say that neither solution will get you to a 100% percent. In practice, often virtualization comes first, and layering is used when tighter application and/or OS integration is needed while simplifying overall management—that’s the general thought at least.

Another technology I’d like to briefly highlight is app masking. App masking is where you put all your applications into a single image and let a filter driver handle what your users are allowed to see and use. This can also also apply to things like fonts, folders, printers, and so on. While this may help in getting closer to single image management, you’ll still need to take the whole image “out of production” when updating a single application. Again, use it where appropriate.   

Another reason to use (or at least try) layering is because customers often already have it as part of an existing VMware or Citrix licensing package. Give it a spin, you might be pleasantly surprised, or not.  

What else?

When it comes to application compatibility, there’s not much between the big three, which are VMware App Volumes, Citrix App Layering, and Liquidware FlexApp. They all pretty much support the same type of applications, with a few exceptions here and there. In the end, it will come down to trial and error.

FlexApp and App Volumes can both create standalone layers that are not dependent on or tied to the underlying OS, meaning that these layers can be updated independently from the underlying operating system.

With Citrix App Layering, however, you first need to create an Operating System (base) layer, from which your Application Layers will be created. In other words, your app layers are tied to the OS layer they are created on. For example, if you are using multiple OS types/versions, you will have to create separate layers for each, for just a single application. This makes Citrix layers less flexible and they’re a bit more work from a maintenance point of view, as well. But on the other hand, you could argue that when using Citrix App Layering, at least you have the ability to layer your OS and (almost) everything that surrounds it (an option the others do not offer), which helps to improve the integration and overall app compatibility.

Of course, there are a million more functions and features to discuss, which depending on what you would like to achieve might, or might not be beneficial to your case. However, since it is near to impossible to cover all of them in this article, I would advise you to have a look at the WhatMatrix. WhatMatrix is a community site where multiple very detailed and non-biased comparisons have been made throughout the years, including one on application layering, which was added not too long ago.  

The future

Many claim that with the rise of cloud computing, application remoting, and SaaS, technologies like application layering will slowly become obsolete. I agree, but it won’t happen immediately—I’m talking about five to 10 years from now. Even then, traditional Windows applications will still be with us and probably so will most of the management challenges we encounter today.

Don’t get me wrong, it’s not like 80% of all companies in the world use app layering (for various reasons). There’s still plenty of room for improvement and future development. Here, I’m thinking about things like ease of use, stability, app compatibility and updates, the layer creation process and the time it takes to do so, and more.

But also think about future developments like Layering as a (cloud) Service, which could be the next step following the current wave of control/management planes in the cloud. Insiders tell me that this will be a reality not too long from now. Will it catch on? Time will tell.

Another interesting development is what both Liquidware and FSLogix are doing today. They offer direct integration with public cloud-based storage (Azure, AWS, Google) through API calls, eliminating the need for an additional Windows Server/SMB share, a very clever way of taking care of things. Use it to store your application layers, in the case of Liquidware, or any other type of data for that matter. Some interesting use cases, besides layering, come to mind.

Some statistics

Not too long ago the results of the 2018 State of the VDI and SBC union were released. One of the things it taught us was that although the consumption of cloud services (SaaS mostly) is increasing, so is the use of on-premises SBC/VDI.

In fact, the use of traditional Windows applications also increased, as it did in 2017. On average, up to 75% of all applications used are Windows applications. We’ll probably see a massive decline in years to come, but still, it’s almost the opposite of what most marketing folks want us to believe.

As for application layering, 66.59% of all respondents indicated not to be using any form of application layering—the market is still wide open.

Citrix App Layering currently leads with almost 14%, though this will probably include a bunch of former Unidesk customers as well. As highlighted earlier, it also helps that App Layering is part of all editions Citrix has to offer (note that not all features are available with each edition).

Alongside the opportunity for the application layering vendors out there, I also see an opportunity for the administrators and customers involved. Why not make your life a little easier? Although, I’m sure some will not agree.

Wrapping up

Throughout the last year and a half or so, I have seen app layering in action multiple times. Most often the people using it were more than satisfied, including myself on one or two occasions.

I’m wondering, have you tried application layering yourself or are you considering giving it a try? Which products do you use, or are you thinking about using, and why? What are/were your experiences? And finally, what do or don’t you like? Please, do share.

As always, thank you for reading, until next time.