I think we can all agree that end-users leverage applications while they interface with desktop operating systems. For years we have heard about small, large, fat, thin tall, short desktops in all kinds of colors. We have been told countless ways that users can access, touch, manipulate, and move these desktops, but what is often lost in the shuffle of all the madness, is the importance of the application itself.
Users need applications to be productive in their personal and private lives, but lately the line is being blurred between both of those worlds. Which makes it even more crucial from a support standpoint to make application infrastructure decisions that are both cost effective and logical long term.
In the past the application lifecycle was all about products like Microsoft’s SMS and the ability to wrap applications as an MSI. Those packages could then be delivered to endpoints where individual unattended software installs happen natively. The magic was ultimately in the controlled administration within SMS / SCCM and the ability to remove or uninstall the deployed applications, thus maximizing efficiency within the enterprise desktop environment. Over the years various technologies attempted unsuccessfully to improve upon the MSI workflow.
Companies like Citrix optimized the “Application Remoting” concept, by hosting applications on centralized server workloads, while providing controlled remote access to users. This platform proved tremendously successful and has stood the test of time across countless enterprise environments.
The Application Virtualization concept emerged as a true game changer innovation and was quickly adopted by enterprise production environments. The ability to isolate individual applications from either, other applications as well as the operating system itself was and is truly impressive.
Personally, I have survived / thrived through the Application Virtualization war. I started out as a Softricity / Microsoft SoftGrid architect and trainer. Which was exciting, until my company was acquired by VMware and overnight I was informed that I was now a ThinStall expert. Which then evolved into the VMware ThinApp platform of today. At first that felt like trying to be a Yankees and RedSox fan at the same time. For my European colleagues, that would be like trying to be a Manchester United and Chelsea fan at the same time. Awkward to say the least.
Both products have merits, both products have success and failure stories across enterprises so I will simply say that Microsoft App-V and VMware ThinApp are the two clear market leaders in the application virtualization space. Application virtualization has earned its place in the EUC product space, plain and simple.
Application Layering has evolved of late to be a very intriguing and plausible option within the EUC product stack.
The goal of Application Virtualization solutions is to isolate the corresponding applications from both the host operating system as well as other applications. This is often achieved by creating a “bubble” or container that the application resides in. Inside this bubble, the application interacts with a proprietary unique mini “environment” that I have often described as an “answer engine”. Where, the application makes a request and gets an acceptable response, after which it functions normally. Essentially the corresponding applications think that they are installed or configured on the native operating system, but in reality they are hovering just above the host operating system in this isolated virtual bubble.
The corresponding virtualized applications are often communicating with the host operating system through a natively installed agent. Normal functionality of the corresponding applications is maintained through standard operating system features like file associations and services.
One important aspect of the application virtualization process that often gets overlooked, is the elimination of the native application install procedures. After the virtualized applications have been deployed, they are ready for use immediately. The typical application install and configuration is only necessary once during the original package creation process.
Individual virtualized applications are often stored on network based file shares. Virtualized applications are often deployed to endpoints using various trickle streaming mechanisms for offline use, or can be launched using a shortcut directly from the network based file share.
Some applications, often based on the individual code framework, do not interact well with application virtualization solutions. It is based on this challenge that application virtualization solutions are not capable of single handedly supporting an enterprise application strategy. Additional solutions are often required in an effort to achieve a complete strategic application solution.
One example of a real world use case for an application virtualization solution like Microsoft’s AppV, centers on application compatibility problems when attempting to deploy software within a Citrix XenApp environment. Sometimes Application A does not play nicely with Application B and the standard work around was to simply publish Application A and Application B on separate XenApp instances. With Microsoft’s AppV, there is an alternative where you have an opportunity to virtualize either Application A or Application B, decoupling the individual applications from the host operating system. By leveraging AppV, the corresponding packages have limited visibility of the other conflicting application, and subsequently less chance of application conflicts. The need for separate XenApp instances for both Application A and Application B scenarios has been alleviated through the use of an application virtualization solution like Microsoft’s AppV.
Application layering solutions take a slightly different approach as compared to application virtualization solutions. During the application layering creation process, a virtual hard disk in the form of either a VHD or VMDK is created and stored on a network file share. Once the virtual hard disk has been created, the normal application install and configuration is essentially redirected to this new virtual hard disk.
Just like a puzzle piece, placed into its corresponding location within a puzzle, the new application layer virtual hard disk is connected to or attached to the corresponding operating system. This puzzle piece or application layer can be attached to and removed from the corresponding operating system without effecting existing processes.
At this point both the corresponding operating system and the application think that it is installed natively. Unlike application virtualization solutions, where the application has to communicate with the corresponding operating system through the proprietary “virtual operating system”, the application within an application layer is communicating with the actual operating system, like it is “natively installed”, which provides for higher compatibility rates across many enterprise applications.
Similar to application virtualization solutions, application installs are only necessary once during the application layer creation process. Application updates can either be applied to application layers or as real time events through an application layer temp folder within the user’s environment.
Application layers are configured and stored in a few different formats, Microsoft’s virtual hard disk (VHD) and VMware’s virtual machine disk (VMDK). Ultimately which virtual disk format leveraged will be decided by many factors, not the least of which is existing EUC infrastructure.
The FlexApp Layering solution from Liquidware Labs for example provides customers a powerful tool in their application lifecycle management arsenal.
Early analysis suggests that application layering solutions have the potential to provide for higher conversion rates. A few of those aspects will be discussed below.
As detailed above, some percentage of applications are unable to be virtualized using application virtualization solutions. Primarily because of an inability to communicate with the unique isolated environment within the bubble or simply the way the legacy application was coded.
Application isolation as described above is the primary difference between application virtualization and application layering. It is the best and often most challenging aspect of this technology process.
Application layering by comparison provides much needed portability considering the application has simply been redirected to the virtual disk. No changes have been made to the expected application workflow. When reconnecting the application layer, the operating system and native applications simply recognize that this new application layer is just another natively installed piece of software.
As expected, Application Layering solutions do not provide any application isolation and therefore do not solve application compatibility issues.
A real world use case for an application layering solution like FlexApp from Liquidware Labs focuses on developer applications. These applications have a tendancy to be very large and hard to support. One often forgotten aspect of the supportability challenge around developer applications is the time required for installs and subsequently reinstalls. By leveraging the FlexApp layering technology, the developer application can be deployed to the endpoint without the need for the standard install. Within the FlexApp layer the application is already configured and ready to go.
Customers are Looking for Direction
Across the enterprise application landscape there are many challenges to be solved. There is often no one tool that provides a complete fix of the problems. Based on the strengths and weaknesses of both application virtualization and application layering solutions it has become clear that both solutions are great individually. Ultimately tools like Microsoft’s AppV and FlexApp Layers from Liquidware Labs are better together when attempting to achieve as close to a 100% application solution.