Application Virtualisation – Agent or Agentless?

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.

Comments

• Anonymous
  January 01, 2003
  In my previous post I talked about some of the advantages of using agent based technology to deliver

• Anonymous
  January 01, 2003
  Steve Thanks for taking the time to respond (and read :) ) Yeah, speed might not be an issue, but I think that point 1 is enough to put me off doing anything with an agentless application solution.  Agentless strikes me as a potentially good solution for a consumer, but not for an enterprise that needs to manage virtual applications.  All agentless does is embed that agent in there (something is getting in between the app & the OS right?), and that means making changes means rebundling everything. Cheers Stu

• Anonymous
  August 24, 2009
  Hey Stu - thanks for posting a comment over at ViewYonder on my VDI article http://viewyonder.com/2009/08/16/feeding-the-it-shriekometer-5-vdi-anti-patterns/ I'm not sure I agree with your "agent better than agent-less" arguments, but until I have seen some data I'm not in a position to argue.   It just doesn't seem right that using agents is a better way than agent-less - none of your points feel right...  take your Speed point: if it's acceptable to the user, this isn't a point at all.  Starting desktop apps is not fast (you should use my laptop!) so if it takes a few seconds longer I'm not that bothered. I'll keep noodling on this, but I doubt that I'll come round to your way of thinking :-) Cheers Steve