Why application virtualization didn’t turn out to be the ‘nirvana’ a lot of us thought it would be

History and the promise

I was first introduced to application virtualization in about 2002 or 2003. I remember the first conversation I had on the topic. The “Softricity guy” described what they could do (not how they do it) and explained that he could run multiple versions of MS Access, side by side, executing on the same desktop. I was the first of the group to “explain” to him that it (it being Windows and Windows apps in general) doesn’t work that way and essentially he could “go pound sand” or whatever my phrase of the week was at the time. Luckily, cooler heads prevailed and my boss continued to listen and got me to look at the product.

Fast forward a few months and I was a reformed application virtualization believer. Much like the early Citrix days (think 1998/1999) I was running around explaining all the benefits Softricity could offer immediately and the potential impact it could have in the future. I pictured a world where most of my Citrix silos were removed and I had one gigantic load managed group serving all my apps without conflict. I also looked forward to creating a single package for my apps that I could deploy to both terminal server and desktop environments.

In the desktop world, I started to think about mixed environments with offline uses. As Softricity’s maturity level increased and their offline mode became available (think early 2004), I started to picture (yes, I drank the kool-aid) a world where terminal server would be used for applications that required connectivity to a central infrastructure, and desktops or laptops would be used for locally executed applications. In all instances virtualized applications would be delivered to both fat and thin clients… Ahhhhh, it was such a happy time.

Now, it’s late 2009 and looking around the industry you don’t hear much about application virtualization. Sure, you hear from VMware about ThinApp on occasion and there is a rumor floating around that MS will offer an App-V package for Office 2010 (App-V being the latest name for Softricity’s original Softgrid). But all of today’s talk is about VDI, server virtualization and the resurgence of thin clients…

So what happened? Why did my dreams of an application nirvana fall on its face?

I think the answer is that, as usual, I was slapped in the face by the realities of the Windows architecture, and the tolerance people have for complex technologies and additional infrastructure when they are trying to solve desktop issues. End users (and potential buyers) of application virtualization ran into a huge list of items that weren’t supported or requirements that were just plain odd. Add into this mix the fact that you had to “re-package” the applications in a new way and couldn’t get rid of your “normal” application packaging and deployment mechanisms because App Virt didn’t support all applications, and you got a boatload of pushback on the technology.

This pushback basically led to application virtualization being used in targeted use cases. Citrix/Terminal Server admins still loved the technology, but even they found its limitations, and still had to create silos (killing my dream of silo-less environments). So App Virt fixed certain things, but wasn’t worth the time or cost to implement in all cases. Why?

I think the key to any solution to our desktop problems (read application and OS updates) has to address the core issues of the environment we live and work in. Like it or not we live in a Windows desktop world today, and are required to deal with it as best we can. Application virtualization missed the mark because of the following (in no particular order):

• App Virt required you to learn about the apps and learn a new skill set to deploy them. This killed interest in all but the largest deployments, since you had to have enough apps to make the investment in training your admins and understanding your app relationships pay off.
• App Virt could not support low-level applications such as anti-virus or services that needed to start at boot time.
• Patching of the OS essentially still had to be done “in the traditional way” and thus multiple deployment mechanisms needed to be retained.
• App Virt ‘broke’ links and dependencies and sometimes made packaging applications harder than it was before for those doing the packaging.
• App Virt had no solution for user installed applications and a clunky system for dealing with user preferences and settings.

The last bullet is the one I find most interesting. I am starting to believe that the next shift in desktop management is not going to be driven by management applications used in the enterprise. Instead the next shift will be driven by a solution that can be used by anyone. A solution that is transparent to the end user and works with both corporate and user-installed applications. Maybe this is just the “Mac user” talking inside my head, but if we look back at Server Based Computing and Application Virtualization, both of them solved specific problems in the desktop arena, but not in a holistic fashion. Application virtualization started out as a way to deploy applications, then grew into “virtualization” to solve the conflict problem. In both cases, these technologies worked around the limitations presented to them by the Windows desktop.

What if we could work below Windows? What if we could solve the service problem or the boot time problem or the user personalization problem, without Windows knowing about it? Maybe application virtualization wasn’t the nirvana I was looking for.

But it did teach me a lesson: “Solve the problems holistically Ron, and stop trying to solve one problem at a time and crunching a bunch of individual fixes together.”

I guess that is part of the reason I am at Unidesk: We get to solve the bigger problems of desktop management in a holistic fashion without kludging together 2 or 3 or more “fixes” to individual problems.

-Ron Oglesby
Unidesk Chief Solution Architect