Application delivery new ways on the horizon
Application delivery with AppVolumes, more choices for customer
For over a decade we’ve been fighting with appliction compatibility. Application depended on a DLL hell as it was called, a vast directory of DLL files each causing more pain than pleasure. Every software vendor would ship their own version of a DLL and depend on that single version refusing to be compatible with other versions from other vendor or let alone Microsoft itself.
To resolve the DLL hell application virtualization was introduced, application virtualization added application is a kind of container where it had access to it’s own files and a selected number of files outside the container or bubble as it was called.
Conflicts between applications was not possible as these bubbles by default didn’t inter-communicate. In concept this looked like a solution to the DLL hell but it was far from that. Applications need to communicate with each other, that’s the way you do your work, if communication is not possible or slow users will complain. Inter-communication is lacking by default, the reason to avoid conflict. It is possible to create this communication but this creates a management overhead.Inter-communication is possible but not without sacrificing some performance, and communication between native apps and virtualized apps is still troublesome.
Application virtualization should have been used for those few non-compliant applications that caused havock, instead companies decided to do a virtualize-all route. I’ve never been a fan of this route for I think it’s simply wrong because of the following reasons;
- It creating more overhead on a system,
- It’s making applications start slower,
- It doesn’t make it simpler, building and maintaining a package requires knowledge on many levels, it’s not a next-next-finish kind of job.
Lucky for us a new way of depolying applications was on the horizon (see the hint in here 😉 )
VMware – CloudVolumes/AppVolumes
While packing for VMworld on a Thursday I heard they bought Cloudvolumes. The company was in the picture already a year before but was small and new at that time. I never imagened VMware to buy them, but what a good move it was.
At VMworld 2014 Appvolumes was introduced and you could see it was new, no one really knew what they bought, on the floor there was one desk and the lady admitted she learned the app right there while doing.
At first we had to get used to the idea of volumes being attached to a virtual machine on the fly but the longer you think about it the more awesome the idea is. The technique behind is, is old and very proven but for some reason no one ever thought of doing this.
Application virtualization or volumes?
On another blog I read that it was confusing for customer whether to use application virtualization or volumes. In my opinion that’s saying that having more than once choice for a solution is a bad thing, VMware now offers customers multiple options to deploy applications and allows them to get rid of the non-persistent/persistent discussion along.
I don’t see why that would be confusing to customers at all, we had no issues explaining them to use application virtualization next to installed applications (also two options) so why would we have issues explaining to use application virtualization next to volumes (which is installed application 2.0).
I think we are on the brink of a totally new era of building virtual desktop, behind us is the time where we had issues with;
- user installed apps,
- big golden images,
- non-flexible base-application-sets and so on.
For every department with a different application set a new desktop pool was brought into life, leading to more management. For users with the need to install their own apps, persistent desktops where used, leading to more old-fashion management.
Now with Appvolumes becomming available for both Citrix and VMware products we can solve these issues all at once;
- We can leverage the power of Appvolumes writeable volumes to let users in non-persistent desktop pools install their own applications.
- We can connect different application volumes to different users even if they are from different departments, using only one non-persistent pool.
Management of a VDI desktop pool becomes a single pool management job, one non-persistent desktop pool handling all kind of user scenario’s, who can call this a bad thing?
So will AppVolumes solve it all?
Sure they will not but it’s a very impressive product that takes care of some of challenges we had in the past years. They won’t solve applications biting each other but to be honest we don’t see that happen that much anymore. The DLL hell war had been fought and it’s peace in application land now. For that reason it should be possible to let most applications to live close to each other without borders. Without borders communication is faster and everybody is happier. There is no reason to introduce a broder if it isn’t needed.
VMware offers AppVolumes and ThinApp for the applications that can’t live together and need a border between them. In the real world we see App-v used more often but the idea is the same. For that application that is causing issues, create the border and use virtualization. For all other applications place them in a volume and deploy them just-in-time to users, any user on any desktop in a non-persistent VDI environment.
Kudos to the guys from CloudVolumes and VMware to enrich us with more options to deploy applications and stop doing virtualization because we had no other alternative.
Hope this blog raises some discussion in your organization about how to deploy applications in the future, that’s what I strive to..