There is no doubt that cloud computing is raising both the awareness and ubiquity of the use of virtualization technologies. As I see it in the application middleware space, users are getting increasingly comfortable with the idea of capturing complete software stacks as virtual images.
Of course the reasons they are getting comfortable with this approach are due to its obvious benefits. The use of virtual images means users drastically reduce the number of times they need to install and configure a given solution. Once everything is installed and configured, users freeze-dry the result as a virtual image. The installation is configured and preserved and can be used over and over again.
The use of virtual images also means that the time to provision these environments is drastically reduced. Typically users have measured the time it takes them to stand up application environments in days (hours if they are really, really good). With virtual images this stand up time becomes a matter of minutes. Standing up an application environment simply means activating an image or set of images to produce the necessary collection of virtual machines.
While the use of virtual images brings about clear advantages, it also introduces its own set of challenges. Of those challenges, the issue of virtual image sprawl is one of the most consistent. Because it is so easy to create and use virtual images, there is a temptation to create an image for every distinct configuration of a particular environment. While it may seem beneficial to capture this configuration data along with software binaries, this can easily lead to a situation where users have hundreds of virtual images that they have to administer, manage, and update over time. In short it can quickly become untenable, and the benefits of virtualization and virtual images may be outweighed by these management costs.
How then does one go about getting the benefits of virtualization without the likely crippling costs of virtual image sprawl? First you need to take a practical approach to creating virtual images. Capture the basest elements of your application environments (software binaries and some configuration) and decouple other configuration data from the virtual image. Work with virtual images and management solutions that provide you the capability to pass in a subset of configuration data during activation. This allows a single image to take on multiple different personalities as the result of activation-time configuration data.
For example, consider that you want to create a virtual image of the web proxy software that you use in your organization. For an environment of any significant size, it would be a nightmare to try to create and maintain virtual images for each unique proxy instance in the company. Instead, you could create a virtual image containing the installed proxy stack, and then during the activation process pass in basic information needed by the particular instance. This could include information like the host name of the proxy, the backend servers that instance routes to, the session behavior information, and much more. The activation process then accounts for this input and configures the unique instance. By allowing for the parameterization of configuration data that varies across instances, you create a much more broadly applicable virtual image of your web proxy stack and at the same time reduce the likelihood of image sprawl.
Whether you are a consumer or producer of virtual images, keep in mind the need for images that allow for this type of configuration parameterization. If you actively use or produce virtual images and have not heard of the Open Virtualization Format specification, you may want to learn more. Briefly put, it is a standard that specifies how virtual images are packaged and distributed. It lays out a mechanism through which configuration data can be passed to the virtual image activation process, thus allowing the decoupling of instance-specific configuration data from a virtual image. No matter how you achieve it, this decoupling is essential to prevent virtual image sprawl and the ensuing management nightmare.