Desktop virtualization promises to save enterprises from rising data center costs and management headaches. IT administrators, however, have had to contend with immature technology, inconsistent terminology and executive and user reluctance. Fortunately, you can get the most out of virtualization by assembling a toolbox of assorted technologies.
Application virtualization, which includes server-based computing and client-based virtualization, is a key component of desktop virtualization. After all, what would a desktop be without the apps? To that end, it's important to understand how app virtualization fits into your overall strategy and to understand the tools that can make it happen.
What is app virtualization?
Generally, virtualization is the separation of the physical from the logical. Similarly, application virtualization involves separating the physical client device from the management of the application itself. The technology allows IT to centrally manage applications that are then available to users from many different client devices.
Like many virtualization concepts, the term "application virtualization" does not apply to any one technology. Instead, many things could be considered app virtualization, including server-based computing and running apps on the client.
Remote apps/server-based computing
You're probably familiar with what used to be called Terminal Services, which Microsoft now calls Remote Desktop Session Host. This technology was originally developed in the 1990s to deliver full remote desktops from a data center to a user, but it has been adapted (first by Citrix Systems Inc., but now by many vendors, including Microsoft itself) to allow users to connect to individual remote applications.
In other words, instead of connecting to a full remote desktop with a wallpaper and Start menu, the user sees only a connection to an individual application. Microsoft calls this RemoteApp. With Citrix, it's Seamless Windows. Either way, it's a form of application virtualization.
Some might say that remote server-based computing does not qualify as app virtualization, mainly because server-based apps in seamless windows have been around longer than the term. Just because the industry retroactively bestowed the name on the technology, that doesn't make it any less appropriate. With remote computing, you install an application on a server in your data center and users can run it from whichever devices they want with no local configuration, installation or conflicts. And that is application virtualization in its purest sense.
Client-based app virtualization
The other major form of application virtualization involves running apps on the client device itself. (In all practical senses, this means running Windows applications on Windows clients, without actually installing them on the client.) To understand how this works, you should know how Windows applications work in the traditional sense, without app virtualization.
When you install a Windows application, you run a setup routine -- such as an EXE or an MSI setup -- that scans the computer and figures out which components are already installed, and which components the app itself needs to install. As you probably know, most Windows apps are deeply tied to the client machine. The installer writes files into the Program Files folder. It probably copies files to the Windows folder and the dynamic link library (DLL) files to the system folder.
In addition, shared components that are written, browser plug-ins, profile data, context menu extensions, drivers and all sorts of things may be strewn all over the place. And the installer writes all over the registry, both the system hive and the user hive, to make sure that everything is ship-shape for the application.
Of course, this is a major departure from the days when an application was just some files in a folder. That was great because you could just install an app onto a new machine by copying the complete app folder from another machine that already had it installed.
Client-based app virtualization seeks to bring the portability of yesteryear to today's modern Windows applications, while also adding capabilities to centrally deploy and update the apps.
Doing so is actually kind of tricky. Today's apps need their DLLs, system files, drivers, registry settings and who knows what else, so you can't just copy one from the Program Files folder to the new computer. (Well, you can, but the app probably won't run.) Current client-based systems attempt to capture everything an app needs and put it in one simple package that can be dragged and dropped onto any computer.
Sounds great! Admins who have supported Windows desktops for more than a few days, however, know that even if you manage to find every last bit of an app, you can't just plop it on a new computer willy-nilly and expect it to work. What about app conflicts? DLL problems? Driver versions? It can be a nightmare.
To avoid these numerous potential problems, app virtualization products typically isolate the virtual app from the physical Windows desktop environment. They wrap each program in its own protective bubble, which sits between the app and the Windows OS. The app doesn't actually know this is happening, but when the app thinks that it is writing files into the Windows system folder, it might actually be writing them to another custom location that the app virtualization product presents as the proper location.
Many different apps can run side by side without conflict, enabling IT pros to push out local, virtual apps to Windows clients with a high degree of confidence that they'll actually run.
Patching complexities also melt away in this environment, because the app package can be updated centrally, with the changed bits pushed out to every client inside each app's bubble, again ensuring that conflicts don't occur.
Using application virtualization
If you want your desktop virtualization project to include a bit of app virtualization (and trust me -- you do), you can actually figure out which technology is best for you on an app-by-app basis.
Consider the characteristics of each program in your desktop environment. Do users need to run it offline? Does the app require a lot of resources that might best be leveraged at the client? These traits might push you toward client-based app virtualization.
If so, think about products such as Microsoft App-V, Citrix XenApp Streaming, VMware Inc.'s ThinApp, Symantec Corp.'s Workspace Virtualization, Endeavors, InstallFree or Spoon (formerly Xenocode). Each of these products takes a slightly different approach, so while one may not work in your environment, another very well could.
If, on the other hand, your app requires a back-end network connection, you'd like non-Windows clients to have access, or you have security or performance concerns, you should consider running it in your data center and letting users connect to applications via a seamless remote window connection. You can do so with virtualization products like Microsoft Remote Desktop RemoteApp, Citrix XenApp, Quest Software's vWorkspace, Ericom Blaze or 2X ApplicationServer.
Application virtualization will be an important part of your overall desktop virtualization strategy. Fortunately, you have quite a few choices about how exactly to make that happen.
About the author:
Brian Madden is an independent industry analyst and blogger, known throughout the world as an opinionated, supertechnical desktop virtualization expert. He has written several books and more than 1,000 articles about desktop and application virtualization. Madden's blog, BrianMadden.com, receives millions of visitors per year and is a leading source for conversation, debate and discourse about the application and desktop virtualization industry. He is also the creator of BriForum, the premier independent application delivery technical conference.
This was first published in October 2011