So this is a blogpost which is mostly about the session I had on NIC this year, where I held this presentation. Where I talked about different technologies from the app-virt and app-layering landscape and discussed the benefits / cons using these types of products. In these days alot of buisnesses are virtualizing their applications. In some cases it makes sense, but on the other hand there is a new technology appearing in the landscape which is application layering so this post is about showing the difference. However since this is a pretty long subject im not gonna cover everything in the same post 
and no its not a VS battle…
So where are we today? We have our VM-template which are used to deploy virtual machines which can use PXE or some built-in hypervisor deployment tool like vCenter or SCVMM.
We use that to deploy virtual machines and if we need to update the VM-template we have to start it and deploy patches to it, simple. However we need other tools like System Center or WSUS to have the other machine up to date because there is no link between the VM-template and the machines that we have provisioned. Another thing is application installation, where we for many year have been using Group Policy/scripts/deployment tools/system center to install application to the virtual machines that we deploy. Or we could pre-install these applications onto the VM-template (Golden Image) and save us some trouble. Now installing multiple applications onto a machine also needs to need to have ways to update the applications. This is typically done using an MSI update or using System Center and replace the existing software with a new one. Now installing all these applications onto a machine requires that it writes some registry entries, files to the drive and maybe even some extra components which the software is dependant on.
Now we have been doing this for years so what are the issues??
- Big golden image (By preinstalling many applications on the golden image we might have longer deployment time, application we don’t need, slowing down the VM-template)
- Patch management (How are we going to manage patching application across 200 – 500 virtual machines?)
- Application Compability ( Some application might require different versions of the Visual C# library for instance which are non-compatible)
- Applicaiton Security (Some applications do wierd shit, what can we do about those?
- Application lifecycle management (How can we easily add and replace existing applications, we might also need different versions of the same application)
- Software rot, registry bloating (You know there is a reason why there are registry cleaners, right?)
So what about Application virtualization?
Using application virtualization, applicated are isolated within their own “bubble” which includes virtual filesystem and registry and other required components like dll libraries and such. Since each application is isolated their are not allowed to communicate with each other. In some cases we can define so that the application can read/write to the underlaying machine. We also have flexible delivery methods, either using cached mode where the package is stored on a local machine or using streaming mechanisms. In these cases we avoid
- Bloated filesystem / registry
- Application conflicts
- Added application security
- No application innstalled on the underlying OS
- Multiple runtime enviroment
- Easier to do app customization
- Easier update management
Now there are two products I focused on in the presentation which are ThinApp and App-V5.
App-V
Now App-V requires an agent installed on each host (Has some limitations about the supports OS) but is flexible in terms or using caching or streaming (called Shared Content Store)
And we can either manage it using App-V infrastructure or using standalone using PowerShell cmdlets. We can also integrate it with System Center and even Citrix.
However in many cases we need to have older versions of Internet Explorer running when we for instance are upgrading to another Operating System. However App-V does not support this. We have also seen that adding App-V puts extra I/O traffic on the host compared to other app-virt solutions.
Vmware ThinApp
Vmware ThinApp is a bit different, it does not have any infrastructure. You basically have the Captuing agent which you use to create an app-virt package and then the package is self-contained. When you run an application the ThinApp agent is actually running beneath the package that we captured. ThinApp can be created as an MSI or EXE file which allows for easily deployment using existing tools like System Center or other deployment software. Most of the logic of a ThinApp package is stored within the package.ini file.
However if we want some form of management we need horizon setup, and there is no PowerShell support, in order to use that we need to develop some cmdlets using the SDK. Since there is no infrastructure as well we don’t have ny usage tracking feature. However we have a handy update feature using Appsync which is part of each package ini file.
Now both of these solution use a sequencing VM which is used to do the package/capturing process. ThinApp however has a larger amount of supported operating systems it supports.
Now what about application layering ? Important to remember that AppVirt runs in user-space, and therefore there are some restrictions to what it can run (Antivirus, VPN, Boot stuff, Kernel Stuff, Drivers and so on)
Application layering is a bit different, it basically uses a filter driver to merge different virtual disks which will then make up a virtual machine.
So we have the windows operating system which might be its own layer (master image) and then we have different layers which run on top, which might consist of application layers, which are read only (VHD disks for instance) and might also consist of a Personalization layer which might be read and write layer.
Now using application layering, application will behave normally like as they would when they are innstalled to an operating system, since its pretty much a merger of different VHD disks.
Since they aren’t isolated, the “capturing process” is much more simple. Unlike when doing app-virt where the sequcing part might take a loooong time. We can then add different applications to different layers and we can for instance distribute the read/write across different layers where are stored different places. This allows for simpler application lifecycle management for instance if we have multiple virtual machines using the same application layer, we can just update the main application layer and the virtual machines will get the new application.
In the application layer space there are four products/vendors I focused on.
- Unidesk
- Vmware AppVolumes
- Citrix AppDisks
- Liquidware labs
NOTE: There are multiple vendors in this space as well.
UniDesk
Now Unidesk is the clear leader in this space, since they have support for multiple hypervisors and even Azure! They can also do OS-layering as part of the setup.
They can layer pretty much everything since they are integrated into the hypervisor stack. So its not entirely correct to state that they are an application layering vendor. They are a layering vendor period
NOTE: The only thing I found out they cannot layer is cake.. Plus they have an Silverlight based console + they don’t have instant app access like some of the other do. But there is a new version around the corner.
Citrix AppDisks
Then we have Citrix AppDisks which is going to be released in the upcoming version 7.8. Now the good thing with Appdisks is that it is integrated into the Citrix Studio Console. AppDisks is Applications only, Citrix has other solutions for the OS-layer (MCS or PVS) which both AppDisks will support. They also have PVD for the profile which can be writeable, and they have profile manager as well which will make Citrix a good all-round solution.
Now AppDisks support as of now XenServer and Vmware and suprise! you need an existing Citrix infrastructure. So no RDS/View. AppDisks also has no instant-app delivery, and is only for virtual machines.
Vmware AppVolumes
VMware is also on the list with. which is agent based and runs on top of the operating system. The good thing about this is that they have instant application delivery, they can also function on a physical devices since they are agent based. However you should be aware of the requirements for using AppVolumes on a physcal device (they should be non-persistent and have constant network access, I smell Mirage)
Its has a simple HTML5 based management, it only does hypervisor integration with ESX and vCenter however but can be used in RDS / Citrix enviroments, just install the agents and do some management and you are good to go.
Now we have seen some of the different technologies out there, to summurize I would state the following.
Liquidware labs – ProfileUnity FlexApp
This is a new addtion to the list, Liquidware labs ProfileUnity is primarly an UEM solution and therefore not an original part of the stack, but in addition to delivering UEM is also does Application layering capabilities. ProfileUnity is Agent based and therefore is not dependant on reboots to attach an layer to a session. It can deliver two types of different layers (DIA Direct Installed Applications) or UIA (User Installed Applications). DIA can be sequenced from a packaging console.
ProfileUnity has a simple an clean HTML5 management, it can do hypervisor integration to VMware do deliver Direct User Applications also known as FlexDisks. We also have micro isolation feature which handles layering conflicts between different layers.
Application virtulization should be used for the following:
- Application Isolation
- Mutliple runtime versions
- Streaming to non-persistent
- Application compability
Application layering should be used for the following:
- Application lifecycle management
- Image management
- Profile management (if supported by vendors)
- Applications which require drivers / boot stuff
UPDATE: 15/03/2016: Added Liquidware Labs FlexApp
And lastly, what is coming in the future? Most likely this will be container based applications, which have their own networking stack, more security requirements and contained within their own kernel space. Here we have providers such as Turbo.net which have been delivering container based applications before Windows Announced container support for their operating system