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

This question came up in a session at VMworld, if vApps are being used to deploy entire self-contained and silo’d application stacks won’t that lead to massive VM sprawl. Because cloud deployments are less considered and are a result of quick instant gratification provisioning in the private/public cloud by business units who don’t necessarily understand IT services and the burden of operations, integration, etc.

Well, yes – and that’s an interesting point for a number of reasons which apply equally to private and public cloud;

vApps encourage less shared application services

This is both a good and a bad thing, good in the sense that less shared typically means higher SLA’s are possible and change is simpler because there are less interdependencies to consider. But, bad in the sense that it increases the overall number of machine instances required to support all of your IT services.

Traditional Shared application Services vs. vApp

Guest Software Licensing Increase

When you consider you will normally have to license the software running in each vApp, providing a shared corporate database cluster is typically a way of providing an HA Oracle or SQL database service in a cost-effective manner because those applications are expensive and more cost-effective to license by CPU in larger environments.

Software licensing needs to change for the cloud, the move to a more consumption/rental based model is underway for most major vendors; those that don’t will die.

Guest Management overhead

Now a vApp may have it’s own DNS, domain controllers, databases, web services, applications VMs each of these will need to be patched, maintained, monitored etc.

Automation solves a lot of this and is the holy grail but particularly when VUM is going to have it’s guest patching functionality removed in future releases this could be a concern.

However…

If you think about it the costs in the vApp model are more controllable and accountable – yes you may have more machine instances than you did in the more traditional IT world but you know exactly who is using it, how much of it they are using (the charge units are more easily quantifiable) and they can easily stop using it or move it to a lower SLA tier if it’s costing too much.

The control/decision of cost/benefit is back with the consumer (internal business unit) rather than being dictated as a fixed fact by IT – moving the consumer to a different service tier is MUCH harder to do with traditional shared services, in the cloud world it’s configuration from a shared pool of infrastructure.

if a vApp isn’t used anymore it’s easier to archive the data and destroy it, it’s much harder to disentangle a tenant from a traditional shared application service like CRM or an intranet where customisations or extra components may have to remain in-situ because just uninstalling them poses a risk to overall service.

It also has the advantage of potentially providing a higher net SLA, there are less inter-dependent parts across the enterprise so less scope for things to break as a result of subtle incompatibilities.

Likewise you can clone an entire vApp in-situ to a test or DR environment with data and configuration in-place and run it in isolation from the production copy to fully test changes, this is much harder with traditional IT shared application services.

So in conclusion; Yes it could lead to some degree of silo’ing of application services which is somewhat at odds of what virtualization has done in breaking down and consolidating these silos from an infrastructure perspective. Strategically, software architecture frameworks will make applications move to a different deployment model that is more “cloud friendly” and less tied to machines, operating systems and infrastructure.

The net benefit is choice and cost control for the end-user.