One of the things I sometimes hear from my customers when we’re talking about Application Virtualisation is “why do you need an agent for virtualising applications, especially when some of your competitors don’t?”.  My answer to them is “what do you think an agentless solution does except introduce management overhead?”.  Sure it looks attractive in the short term since all you have to do is distribute an executable to your clients and they can run virtual applications. 

However I can think of several reasons why an agent based technology is superior.

1. Management of the virtualisation agent

Let’s say that I discover a security vulnerability in my virtualisation agent, or I want to add new capability to my application virtualisation client (for instance, in the App-V 4.5 release, we added the capability to stream over HTTP).  If I’m using an agentless technology and want to update my client, I have to go off and rebuild every package that I’ve deployed, and then redistribute that package to each of my clients.  With agent based technology I just deploy an update to my agent software and can leverage that new technology without rebuilding my application packages.

In addition, if I want to know what version of my virtualisation agent that is in the packages it out there, I can’t really do that.

2. Duplication of resources

If I have an agent based technology, when I launch a virtual app I’m sharing all the same agent resources as any other virtual apps (CPU/Memory/Disk etc).  When I’m running agentless, every virtual app that I launch starts it’s own instance of the virtualisation agent, each adding it’s own overhead to the process.

3. Speed

If I have to extract the agent and execute it every time I launch the application, that adds overhead to my application launch time.

4. Scriptability

Because we’ve separated the virtual application content from the virtual application client, now we can do some more interesting things with the client.  Things like prepopulating the cache with certain applications, or removing applications from the machine at the command line.

Overall having the virtual application content separated from the virtual application client allows us to have a more manageable implementation, and this will in turn lead to significantly reduced cost of ongoing maintenance over an agentless environment.  If you can’t manage your virtual apps, you’ve missed half the benefit of having them virtualised in the first place.

In my previous post I talked about some of the advantages of using agent based technology to deliver virtual applications.  There were a couple of things that I forgot to include when I wrote that post.  So continuing on from that list, here are the extras:

5. Inventory

If I’ve got my application content separated from my agent, I can now query my agent to find out what applications are present on my machine.  That means using tools like System Center Configuration Manager I can find out which virtual applications are where (just because they’re virtual doesn’t mean you don’t have to pay for them). 

6. Usage information

My agent can now collate all the usage information about my virtual applications and report that into a single location, using a single mechanism that is independent of the virtual application itself.  Now I can get accurate information about how my users are using the virtual applications, and use that to optimise my licensing.

Those 6 points demonstrate that to truly be effective with virtualisation, the management component is essential.  And the only way to effectively provide an application virtualisation solution that is enterprise ready is to use an agent based technology.  Anyone selling you an agentless application virtualisation solution is not selling you any cost savings or flexibility, they are selling you complexity and overhead.