Virtual Appliances - a level playing field

I've only played with virtual machines for the past 6 months. I always looked at VM's as a server side  technology, and never really fully appreciated their use. Quite ignorant!

One of the challenges my organisation faces is ensuring all the developers are working with the same versions of software as production. Sometimes, the production machines get a patch, but the developers continue to work on older versions. Sometimes this happens because they don't know how to upgrade, are too busy or are just plain lazy. Either way, when their code goes in for release and breaks we always get the "works on my machine" story.

So, what is a virtual appliance?

"Virtual appliances are ready-to-run virtual machines packaged with an operating system and software application. These self-contained appliances make it simpler to acquire, deploy and manage applications by eliminating underlying hardware and operating system dependencies." VMware

At my office we work with predominantly Oracle software - and so we have created a Database, Weblogic, Forms & Reports on one appliance, then Database, Weblogic and BPM on another. Now, when we make a patch we update the VM and share it amongst the developers. Job done!

Cloning in the IT world is BAD!

Something that really irks me is my companies decision to clone production environments, and distribute these clones to create new environments. So, lets say a new project starts up and they want a replica of one of our databases - a request is made to the DBA, he takes a snapshot of production and puts this snapshot on the new target host. He/she then does a series of search and replaces for environment specific variables and then hands over the new environment.

You may be asking whats my problem? Well, here they are:

• When you clone, you take everything; configuration, structure and worst of all data.
• The process involves around 3/4 people and takes about a day.
• Garbage in, garbage out - whilst production is the only "truth" when you molest it with search and replaces who knows what you're getting?

So, what solution did I offer? 

As we're talking about the database I shall start with that. Firstly, a database is no less important than application code and so should be version controlled. Once the source code is version controlled you can use tools such as dbdeploy to build your database in a repeatable manner. I'm a firm believer that no live data should exist outside of production or the disaster recovery. If you cant generate test data for the scenarios you will encounter then your test strategy is not sufficient. 

What happens when I want to retain data?

In a data retention environment such as User Acceptance, we only ever want to apply deltas to the DB not refresh it every time - well, dbdeploy handles this very well.

Cloning isnt all bad..

I think the cloning strategy has some value - version controlling your database will not suffice in a disaster recovery scenario because the most important part - the data - will be missing. I wholeheartedly agree with the cloning strategy in this scenario.