Installing by hand
After launching a virtual machine it's fairly typical (at least in the first instance) for the user to install stuff by hand. This might be done with a package manager (e.g. yum on Enterprise Linux, apt-get on Debian/Ubuntu and derivatives), a source control system (e.g. git/github or Mercurial), language specific packages (e.g. Ruby gems or Java ear/war/jar files) or simple file archives (e.g. tar or zip).
Installing by hand provides infinite flexibility, but it's time consuming, resource intensive and error prone, which is why it's often desirable to automate installation (particularly once something has been developed and it's moving into a production setting).
There's a mantra that 'any good systems administrator will replace themselves with a script', and scripting provides ways for stuff that would be done by hand to be automated. Many operations people start out writing their own scripts in bash, perl, python or whatever, but in a large organisation the scripts can become a tangled mess with their own set of (inter)dependencies.
Tools like Chef and Puppet are essentially scripting frameworks that are (or at least can be) strongly connected to version control systems. This allows infrastructure (or at least infrastructure configuration) to be treated like code. There is perhaps too much focus on the tools used in DevOps (a natural IT tendency) rather than the fact that it's an artifact of more mature design.
Deployment automation tools seek to resolve scripting interdependencies by introducing centralised repositories and management. Such tools were mostly developed for and targeted at physical servers before the advent of virtualisation.
A painting analogy
Building a server up from 'bare metal' can be a bit like spray painting a car. Different layers are applied to build up to a glossy finish - primer, base coat, colour, lacquer. Like new cars coming out of highly automated factories the aim is to get a perfect finish on each individually customised order.
This is where things can go wrong with deployment automation tools. They tend to be used to spray across multiple machines at the same time, and it gets messy when a new sort of primer (aka patch) is sprayed on after the lacquer (finished application) was already applied.
The layers found in deployment automation can often become like tectonic plates - any movement and you get earthquakes across the data center.
The point of a virtual appliance is to provide containment. A single machine to be built up (like a single car in the paint shop). The virtual appliance is a unitary deployable unit. The parts within it can be known to work together. Change in one virtual appliance doesn't ripple through its neighbours.
There are many approaches to closing the install gap, but each has their drawbacks. Virtualisation brings with it the opportunity to do something different with virtual appliances, and in the next part of this series I'll take a look inside a virtual appliance factory at the stages where installation can take place.