For several years now, I’ve held the opinion that isolation is becoming less and less important when it comes to Application Virtualization of general end users applications. You see, isolation was great when DLL hell was a major issue but developers have got better at producing a higher standard of application. DLL Hell is all but gone, in my experience at least. If you’ve ever demo’d AppV, ThinApp or any other application virtualization solution before, you’ve likely presented yourself launching multiple versions of Microsoft Word side by side on the same machine. That’s still pretty cool but now some applications are even developed to work side by side with previous or later versions of themselves! So, what’s to be gained with isolating your applications?
Not all applications will allow multiple versions to work side by side. And although dll hell is not a widespread problem any more, application conflicts can still occur, particularly on a shared RDS session host or a XenApp Terminal Server in which you may have many, many applications hosted and running concurrently. Containerization is also becoming popular which relies heavily on isolation.
Am I saying isolation should be scrapped entirely?
No, not at all. I still see the value in it, for the reasons I stated in the previous paragraph BUT I’d love to have the option to switch the isolation off when, I so please!. If I have an application with drivers, I can either spend hours trying to extract the drivers or just proceed with a traditional local install. If I have an application with COM+, I can again spend valuable time extracting this. It’s not a good use of my time! We also all likely hear that companies get around 80% of their applications packaged and delivered with a solution like App-V or ThinApp. How are they handling the other 20%? Wouldn’t it be great to handle all applications the same way and without issue?
In my efforts to extract drivers in the past, I believe I could see part of the challenge for Application Virtualization vendors and why drivers are a limitation for so many in the market e.g. Microsoft App-V, VMWare ThinApp , Spoon.net, Cameyo etc. Developers are not consistent with how they deliver their drivers. I’m sure these vendors would love to have a way to simply detect the application you are trying to package has a driver, automatically take that driver out and deliver it side by side with the virtual application, maintain the isolation and integrity of the app BUT I’d also bet that it’s very difficult or impossible to try to code a solution to handle these when there’s no standard being followed.
Numecent Application Jukebox does offer the ability to switch off isolation on a per application basis. Allowing you to package and deliver applications with Drivers or COM+…or anything really. Essentially with Application Jukebox you can package and deliver all of your companies applications, streamed to the desktops.
Currently I’m trying out AppVolumes which is a different form of application virtualization than all others on the market. Rather than stream your applications or deploy a standalone portal .exe, AppVolumes allows you to capture an application install onto a virtual disk. When you assign the application, the virtual disk merges with your desktops disk and the application appears instantly (if desired). The beauty of this solution is that it appears to me that any application can be delivered using AppVolumes.
With AppVolumes you are delivering the application in a really cool, quick and dynamic fashion but essentially once the application is delivered it’s just like it was installed the old fashioned way, the application is on the local drive, it’s not isolated. With AppVolumes, as it’s a VMWare product, if you do find yourself yearning for some isolation for particular problem applications, you can use VMWare ThinApp to package and isolate the application in question and then create an AppVolume AppStack to deploy the application. As with Numecents product, You get a standardized deployment method for all of your applications.
I’m also currently playing around with Unidesks Hyper-V Tech Preview which kicks ass! I blew away my entire home lab which consisted of one physical server that acted as my Domain Controller and Hyper-V server. With all my other machines living as Hyper-V VMs. Now I’ve got one physical server that’s my DC and has RDS, Hyper-V and Unidesk installed. In my old lab, I had some Powershell scripts for automation (Adding Features, setting up certain applications), as well as using MDT. In my new lab. I’ve got one Gold Image and application layers for whatever I want or need! I spin up VMs in minutes with whatever apps I desire. These application layers seem similar in concept to AppVolumes, though as I have limited experience with AppVolumes thus far, I can’t commit to saying they are the same.
Unidesk also allows you to create little virtual disks with your applications on them and then it delivers these by merging with your virtual machines virtual disk. Again these applications are just as if they were installed but they did not require an install on the users desktop. They were delivered in a quick and dynamic fashion with no downtime or loading screens. What if I need isolation for some apps? well, in my environment. Surprise, Surprise, I’ve got App-V so I intend to deliver my App-V applications to my Unidesk desktops with Shared Content Store enabled. Anything which I cannot or do not wish to sequence will be delivered as an application layer. I’d like to see if this may help reduce my storage needs, I’ll let you guys know in a blog post when I get to that point!
With all of that said. It seems clear to me that while isolation is good to have, it should not come at a cost. We want to be able to deliver all of our applications in one uniformed method. I don’t want to virtualize my app but then also manage a locally installed driver for that app. In fact, I’d go so far to say, I don’t want to package my applications at all! If I can get somebody to install and configure the app the way the users want and expect it and then simply and quickly deliver that to the masses, that would be ideal! I’ve made a career as an application packager but I think it’s time for the role of an application packager to become obsolete!
It will be interesting to see what happens in this space in the coming years! I’m excited for the future!
