Laying the Foundation for Your Cloud
April 2, 2012
The basic building block of many cloud computing environments is the virtual image. Most IT departments have been using virtualization for quite some time and are comfortable with the technology. This level of comfort is why I believe it is often overlooked as a crucial element of many cloud-based services. And trust me, what may seem like a minor oversight can have significant impacts that reverberate for the life of your cloud environment.
Put simply, poorly designed virtual images are far more likely to increase management overhead, decrease agility, and hamper an enterprise than they are to contribute to achieving the benefits we often associate with the use of cloud computing…
Given these risks, I think it is helpful to discuss the signs that point to a poorly constructed image so that you are sufficiently prepared to avoid certain pitfalls. Consider the following danger signs:
- The image contains everything but the kitchen sink: One of the chief aims of a virtual image is to make it simple and reliable to create a particular environment. While I can understand the rationale of the “I will install this just in case someone needs to use it” approach, let me assure you that you are only asking for trouble. Just because something can be installed and captured into a virtual image does not mean it should be. Software that is frequently updated probably shouldn’t be burned into an image. Since it is constantly changing, that means the image will constantly change, requiring repeated construction, validation, and testing of the image. Applying this software component as a late-binding customization will be a better approach that lowers overhead.
- The image does not contain a mechanism for activation–time customizations: The reality is that virtual images are rarely one size fits all. Late-binding customizations, such as creating an administrative user account in your environment, need to be automated as part of the power-on, boot-up process so that the changes are systematically applied and explicitly documented. Late-binding customization mechanisms let you avoid manual ‘fix-up’ actions which can be a significant source of bugs and indeterminate behavior in cloud-based environments.
- The image has no personality: No matter the type of software you are capturing in an image, it is very likely to have many different variants or “personalities” (consider an application server that contains management nodes, worker nodes, routing nodes, etc.) If your virtual image has no way of exposing the different personalities of the software application so that a user can make a deploy-time decision about what kind of node he or she wants to create, it will invariably fall short. The alternative to this kind of flexibility built into a single image is to have an image for each variant, and this will only lead to image sprawl and increased costs.
Moreover, there is additional value to be had from the single image, multiple personality approach. An image with different personalities sets the stage for the construction of composite environments. Going back to the application server example, if you have an application server image that exposes a management node, worker node, and router node, you may be able to use that to easily build a composite environment that includes all of these types of nodes.
I realize this may give the impression that building sustainable, reusable and ultimately valuable virtual images is impossible. That is not the case. Constructing well-designed virtual images is really a matter of foresight and execution: defining a solid approach and having the right tools to implement that approach. My advice would be to gravitate to tools that encourage an approach that avoids the pitfalls mentioned above. Namely, the tool you choose should:
- Make it easy to clearly define pre-installed content versus activation-time content and customizations.
- Provide a framework for running configuration actions in a late-binding manner, based on input from the end-user.
- Acknowledge that most software contains many configuration variations. These variations, or personalities, should all reside in a single virtual image.
- Enable images that are conducive to higher-level abstractions. Virtual images may be the atom of your cloud, but it is likely you want to deploy applications, and your image should lend itself well to that purpose.
- Work with many different server virtualization platforms. While it is possible that a particular server virtualization platform is predominant in your organization today, it may not be in the future. Tools should not hold you hostage to a particular platform.
So, as you can see, virtual images are not an afterthought and deserve careful attention upfront. I strongly encourage you to do yourself a favor. No matter where you are in your cloud journey, stop and think a little about the virtual images you are using. You will be glad that you did.