Never mind virtual desktops – what about the apps?

Conventional wisdom says that when planning an IT project, the things to get right before you start are less about ‘the thing’, and more about what the thing has to fit into, who’s going to use it and who needs convincing of its value in the first place. Somewhere along the line ‘the thing’ gets some attention, but when it comes to practicalities in most real world projects, the thing comes last.

When it comes to virtualisation, though, ‘the thing’ gets a bit more attention. If we’re talking about virtualisation in the context of delivering application software then one of the choices, unsurprisingly, is to virtualise the application itself.

Application virtualisation has its own take on the virtualisation theme, but the principle is the same. Rather than having a virtual ‘bucket’ which emulates an X86 processor and runs an operating system, application stack and so on, why not just have the ‘bucket’ containing the application itself? This way, applications become the entity that can be managed, moved around and so on, rather than an entire machine.

Why might you consider virtualising a software application? There are numerous reasons usually cited, around increasing the portability of applications and improving their manageability and compatibility with other applications. Some clarification on the latter is due: application virtualisation doesn’t so much make things more compatible with each other as removes their need to fight over common services and resources.

What is equally important is the environment in which the application is being used. Existing applications may find themselves as virtualisation candidates if there is a requirement or opportunity to reduce running/ownership costs, or if another application due to be introduced is deemed an unsuitable stablemate. On the other hand, application virtualisation may offer a way of delivering a new application into an environment which, without the virtualisation capability, wouldn’t allow the application to run – for example running Windows applications in a Linux environment or vice versa.

Regardless of any of this, another case for virtualised applications is the improvement in speed of deployment, enhanced security and better tracking of actual usage. These are all compelling attributes that a service provider, or an IT shop wanting to get a handle on control and visibility of its application software portfolio, or indeed, just a specific application, may find attractive.

But what of the limitations of this approach to software delivery? For a start, you cannot make all software applications virtual, and the act of isolating an application may have implications when it comes to thinking about things such as integration or vendor support. Frankly, the more applications your organisation runs, the more likely you are to find some that are prime candidates for virtualisation, and that some are not.

All the same, application virtualisation does offer a halfway house between the current ways of installing applications and full-fat desktop-hosted virtualisation (let’s not forget that’s where virtualisation started, before it made its way onto the server), or indeed server based VDI. And for many organisations, it may be enough to satisfy their needs for flexibility and efficiency.

There are perhaps no ‘rights and wrongs’ here; more a case of ‘right for us’ or ‘right for the [technical] environment’ or ‘right for the job in hand’.