This article is Part 3 in a series about app virtualization. The other parts are:
In today’s article, we’re going to cover the technology called “layering."
Layering is a popular term that we’ve been writing about for years. Gabe first wrote about it over 6 years ago, though a lot has changed since none of the three vendors he mentioned in his 2009 article (MokaFive, Wanova, and RingCube) exist anymore. That said, the term “layering” has gotten trendy, (like app virtualization), and today there are dozens of vendors who claim to have layering solutions. To make matters worse, there’s no single broadly-accepted definition of layering, meaning we can’t really point to one vendor and say, “You don’t have real layering!” because in their minds they probably believe they do. (Of course whether or not a vendor has “real” layering or not doesn’t really matter—instead all that matters is you buy a product that does what you need it to do.)
Getting back onto the point of this article, I’d like to talk about layering (as I see it) and how it fits into the overall application virtualization landscape.
The basics of layering
The fundamental technologies that make up layering solutions are the exact same technologies discussed in Part 2 of this series (about virtual “locally installed” apps). At the most basic level, layering solutions have agents that live deep inside Windows (or perhaps in the hypervisor) that trick Windows into thinking that files and registry keys are all installed into their normal locations when in fact those files and keys are coming from different places. So again, this is just like virtual “locally installed” apps.
The difference with layering is how these virtual apps are packaged and bundled.
Back in Part 2, I talked about how locally installed app virtualization tools let you package up Windows applications into isolated bundles. The key with that is that all your apps are still separate. e.g. Office is isolated from your billing app which is isolated from your sales app which is isolated from your CRM app… An enterprise could have literally hundreds (or thousands) of separate app packages for all their applications.
The idea with layering is that instead of managing and packaging all of your apps separately, you group related apps into the same bundle, and then you make those bundles of related apps available to users on demand.
For example, if you are an enterprise with 5,000 users running Windows 7, chances are the “base” Windows 7 image for all 5,000 users is going to be identical.
Then on top of that, you might have a core group of “enterprise” apps that are also the same for all users. (That might include Microsoft Office, your time sheet and expense app, Adobe Acrobat, Dropbox, and the other apps that every single employee in the company uses.)
Then as you divide your company into smaller groups, each group of users is going to have their own apps. For example, on top of the enterprise-wide apps that everyone uses, you might have a different set of core apps for US-based workers and European workers. Then you might further have sets of apps per country, then per department, then per project, etc.
Figuring out which apps are used by which groups of users is nothing new, and it has nothing to do with app virtualization. Even in your company today, a typical user might have 20 applications—10 are company-wide, another 3 are based on their location, they have another 5 based on the department they’re in, and then 2 more based on the specific projects they’re working on.
Using app virtualization (whether the remote apps I discussed in Part 1 or the locally installed virtual apps I discussed in Part 2) is a great way to package the apps and make sure they can all be easily deployed in whatever combination you need to your users. Layering is just a way to manage all these apps in different bundles.
Layering versus locally installed virtual apps
At this point you might be thinking, “Ok, so what’s the difference between layering and locally installed virtual apps?” As I mentioned already, it could be argued that there really isn’t too much of a difference.
Remember from Part 2, we talked about how locally installed app virtualization can take all the different files and registry keys that an application needs, and instead of installing them into all their different native locations on the hard drive, it actually installs them all into a single location and then tricks Windows into thinking the files are actually in the other locations where they’re supposed to be.
In the example, I talked about that “other” location as some folder on the C: drive, like a file that need to be installed into c\windows\important.dll really being installed to c:\AppHero\SomeApplication\important.dll. It’s still on the C: drive (because even the virtual app was “installed”)—it’s just not in the original location.
Okay, so you know when you put a USB stick in a computer and it appears in Windows as a new drive? Imagine that if you put a USB stick in a computer which showed up as the E: drive and then configured your app virtualization product to use the E: drive as its secret location, what you end up doing is getting all the files and all the registry keys of your application installed onto the USB stick instead of to the computer’s hard drive.
Again, Windows doesn’t know this is happening because the app virtualization product is tricking it into thinking the files and registry keys live in their proper locations on the C: drive, but you can see how you could use app virtualization to actually install all of your apps onto a USB stick. (So the c:\windows\important.dll is actually installed to e:\AppHero\important.dll.
You can then take that a step further. If your app virtualization software lets all the apps use the USB stick as their storage location, you can envision that you should be able to remove that USB stick from your computer, walk up to a brand-new computer with no apps installed, insert the USB stick with all the app packages on it, and then the apps from the USB stick should show up on the new computer and work like normal apps, right? (Assuming you installed the app virtualization software agent on the new computer.)
This makes sense, right? With app virtualization, all the files and registry keys can be stored in any arbitrary location, that arbitrary location could be the E: drive, and the app virtualization software runs interference between Windows and the storage system so Windows thinks that everything is fine even though your app’s files and registry keys are coming from some alternate location.
Now take that a step further. In today’s world of virtual hardware and hypervisors, hard drives can be virtualized into a single file. (Microsoft uses .VHD files, VMware uses .VMDK files, etc.) On a Windows computer, if you see a .VHD file, that’s a virtual hard disk file, and you can double click it and it gets opened up and looks just like another hard drive. Literally you double click the .VHD file and all of the sudden an E: drive appears which looks to Windows like a second hard drive but really all the files on it are coming from inside that .VHD file.
So imagine combining the fact that a Windows computer can “mount” a .VHD or .VMDK file like a hard drive with the app virtualization products that let you install virtual app packages into a secret location that look like natively-installed apps to Windows.
Now take this a step further. Instead of having a .VHD file containing virtual apps on a computer’s hard drive, what if you put it on a network share? Then all the users in an office would have access to it (as their P: drive or whatever), and it would contain all the virtual apps that the users need, and the app virtualization software running on each computer would make it look like those application were all installed locally.
This would be a great solution, because as an IT admin you would only have to maintain one single copy of your application packages on the network, and all the users would have the benefits of having their applications “installed” (because the app virtualization software on the users’ computers makes it look like those apps are installed), and since you’re using app virtualization none of the apps are conflicting with each other.
Taking this another step further, what if you made different .VHD files for each related group of applications? You might have one for the basic enterprise-wide apps that everyone in the company uses, a second for country-specific apps, a few more for department-specific apps, and even more for project-specific apps. Then each user could connect to their individual combination of .VHD files for the apps that they need, and to that user it would look like they have every single app installed locally even though the apps are coming from .VHD files containing virtual apps across the network.
Putting it all together
This is essentially what layering is. It’s called “layering” because people think about it logically like each bundle of apps is a separate layer. You have a base layer with just the pure Windows operating system, then a layer on top of that with the enterprise-wide apps, then a layer for country-specific apps, then a layer for department apps, then a layer for project-specific apps, etc.
In reality these aren’t actually layers that are stacked on top of each other—really they’re just modular bundles of related applications—but the layering metaphor makes it easy to think about.
This is essentially how layering workshow layering works. If you’re using virtual desktops (like VDI) running on a hypervisor like Microsoft Hyper-V or VMware vSphere, then in that case the desktops are not connecting to disk image files across the network since the hypervisor itself is able to bundle multiple VHD or VMDK files together to make a single VM disk image, but the concept is the same.
You can also use these “layers” to instantly add or remove groups of apps for users (just connect or disconnect them from the proper layer), and keeping everything in separate layers makes it easy to update the apps in a particular layer without breaking everything else.
When it comes to layering products on the market, not every vendor uses VHD or VMDK files. (Some do, and others use their own formats.) But the concepts are the same across the board. The fundamental technologies that make layering a thing are the exact same technologies which power the locally installed app virtualization I discussed in Part 2. But when you bundle groups of related apps together and then let desktops connect to multiple groups of apps at the same time to build up their complete and custom Windows environment, you now have what most people refer to as “layering."