Virtualization, Cloud, Infrastructure and all that stuff in-between

vApps were introduced as part of the vSphere 4 release but were largely a forgotten area of functionality until now.

The concept of a vApp is as a bar-code for an IT service, where that service consists of a number of inter-dependent virtual machines containing applications that provide a service – for example a website. the vApp contains a number of virutal machines and is tagged with required levels of service and other pertinent information like start-up order, dependencies and required networks etc. to allow them to run successfully.

For example a corporate Sharepoint service could be grouped and deployed as a vApp containing relevant domain controllers, DNS, SQL and MOSS VMs to allow it to run – from a VMware perspective you manage and deploy the servers as a whole vApp rather than individual VMs.

With the vCloud Director (vCD) announcements it’s clear what VMware’s intention was; vApps are core to the service catalog concept for vCD, you don’t just pick virtual machines you can pick ready-to-use and self-contained application stacks to deploy and un-deploy.

However, if you think about it, it’s not as simple as it might seem once you go beyond the infrastructure level as you’ll still need to do in-guest engineering and automation to make this sort of deployment model successful but it’s a good foundation to work from.

This type of rapid provisioning and the level of in-guest automation required to make it useful can be problematic with Windows guest OS’es – there are still tight dependencies on domain controllers, forests and domain SIDs to get around for many applications. As more and more Microsoft applications move to PowerShell at the core this becomes more feasible but architecturally speaking it’s a problem for anything other than trivial applications.

The guest automation story is much better for Linux VMs deployed as part of vApps as scripting and automation is at the core of Linux deployment and always has been but it’s not done for you, vCD just handles the {virtual} infrastructure provisioning; tailoring and automating the resultant guest OS images is up to you but there is much more precedent on this space.

Strategically, Springsource makes a lot of sense for these sort of container deployments, the use of application frameworks breaks the dependencies on the underlying OS and makes applications much more flexible and portable, but this is an evolution away from current enterprise applications.