vCloud Director has allowed developers to create isolated, self-contained virtual applications that are easily replicated and shared across clouds. As we increasingly bring a number of ISVs and SaaS developers onto the BlueLock public cloud I have seen an interesting trend evolving – vApps (and the OVF metadata that wraps around them) have become an increasingly convenient way to package and distribute applications.
The practice of creating ready-made virtual machines is not a new one – in fact VMware Player exists for this very reason. A ready-made and pre-configured application can very easily be bundled inside of a virtual machine, compressed and made ready for download. Bundling more complex applications that span multiple virtual machines has been a more difficult thing to do; VMware Workstation attempted to tackle the issue with the concept of "teams," but it wasn’t a complete solution. It took the advent of the OVF standard and the vApp construct within vCloud Director for a practical solution to arise.
vApp encasulation has made distribution of SaaS and complex multi-server applications easy – you just freeze-dry your vApp, save your vApp to your vCloud catalog or save the entire thing to disk. Want to easily spin up an n-tier application? Just deploy from the OVF and you’re up and running within minutes.
Could this capability be exploited to help with the software release lifecycle? At first this sounds like a great idea: when your n-tier application is ready for quality assurance testing just clone the vApp and hand it off to your QA team. Once the application is tested and approved, you clone the vApp once more to place it into production. No more guessing about configuration files, no more wrestling with pushing binaries or creating automated deployment scripts. One big wrinkle exists with this strategy… the mega-problem that always comes back to bite every engineer with good intentions… data is rarely portable.
Current production data can’t be blown away with every new release, even with stellar database backup procedures. Even if we isolate our data tier and place it in an immutable VM you still need to tweak your application configurations to point to a new database after every development/QA/production push. Even worse – what if you forget to make these configuration changes? Your production application could suddenly be serving up QA data. It’s enough to make a release manager eat the entire bottle of antacids.
Without a doubt, vApps give you extremely more convenient and agile ways of promoting applications along with the infrastructure that hosts it. This is extremely useful for development, test, quality assurance and demo environments. Still, one has to be ever mindful that binaries don’t make an application. Data makes an application.