If you’ve ever gone 4 wheeling there is a saying when going offroad: “as slow as possible, as fast as necessary”. This phrase reminds me a lot of how I feel with application virtualization, “as little as possible, as much as necessary“.
Application virtualization whether done via App-v, ThinApp, or XenApp (or others) all have some common characteristics.
- Virtualized file system and registry
- Files, installation packages (.msi, setup.exe), etc are repackaged into a new format
- Applications are streamed out to the endpoint on demand and run in an isolated space
- Streamed packages can be cached and used offline
- Updates made to the base package are streamed out to clients
The promise of application virtualization is that you are making apps portable and available on demand, no lengthy installation package to run through or customizations to make.
Some of the challenges of application virtualization are actually some of the core tenants of application virtualization that I mentioned before:
- The application is virtualized and see virtual registry and file systems, meaning it can’t necessarily (unless allowed) interact with other apps (be called to or call in to other apps).
- Applications have to be repackaged in order to be streamed and although there are previews of technology that automate this repackaging process (ThinApp Factory) it’s a process that adds time and steps to a user getting a new piece of software or an update to an existing one…and it’s frankly not so easy to repackage these applications that you can assume automation of this is even possible.
- Not all applications work or can be virtualized. Depending on the software being used there are still challenges with certain drivers, DCOM, kernel level items, plug-ins, 64 bit apps, etc…every vendor is currently working from a different list of limitations.
Ultimately application virtualization is a patch (or perversion) due to the deficiencies of the Windows operating system, installer process offered by Microsoft, and application isolation options as a core operating system feature. The problem can’t be solved by 3rd parties it has to be taken on by Microsoft and resolved as a core feature of the OS. I’ve talked about some other challenges and thoughts on application virtualization in a prior post here.
- I believe that application virtualization should be used when you have application conflicts where 2 applications need to be isolated from each other.
- I believe that application virtualization should be used when you have an application that requires very frequent updates and the traditional deployment tools fall short or if you don’t have them.
- I believe that application virtualization should be used to isolate “messy” applications from shitting all over your OS image that make them difficult to remove or update cleanly.
- I believe in application virtualization when you have a small list of “easy” applications that allow you to truly layer your apps on top of a single gold image.
So back to the phrase I said at the beginning in 4 wheeling: “as slow as possible, as fast as necessary”, in application virtualization I say: “as little as possible, as much as necessary“.