August 22, 2011 | Written by: David Kwock
Share this post:
When building a cloud environment, one of the most important things to consider is what images will be in the service catalog. Many times, business requirements drive more variations of software configurations and operating system versions, which quickly can cause several derivatives of a base image, and ultimately virtual image sprawl. In turn, this can quickly lead to rising management costs for maintaining the cloud service catalog. Many times image templates are created so that users can simply deploy them and get to work. To do this, they usually build an image that statically captures the software components and a significant amount of configuration. Although this might be the seemingly obvious approach, it can be a problem, especially when the configuration is specific to a narrow subset of use cases. When creating images that contain components and a configuration that is specific to a particular use case, the likelihood that anyone can use the image for anything other than a very specific scenario is significantly decreased. When building a cloud service catalog, a balance between embedded configuration and configuration that must be done by the user must be reached. Too little embedded configuration can cause the user of the image to do a lot of manual error-prone configuration every time the user uses the template. However, too much embedded configuration causes the image to only be usable by a subset of use cases. Another factor to consider when looking at what images to populate a cloud service catalog is the amount of software packages on top of the base image that could be installed. This factor many times can reduce the number of images that are needed in the service catalog. For example, if you have a base Linux image and an installer file for IBM WebSphere Application Server, you do not need to have both a Linux base image and a WebSphere Application Server Linux base image.
When looking at the software that should be part of the service catalog images, group the components into three categories. First, large components are those that should install directly as part of the operating systems and other software of considerable size and that integrate well into the base virtual image. Next, common components are those that are common to most, if not all of your software environments, such as anti-virus software, monitoring agents, or office tools. These common components should be evaluated to determine if there is a specific configuration needed for them. For example many times monitoring agent software requires individual configuration, which might be well suited for a software package versus being embedded in the image template. Finally, time-intensive configuration is configuration actions that take a considerable amount of time to perform. Although no hard rule exists for which of the three categories of software should be installed as part of the image in the service catalog and which should be software packages outside the image, a recommendation is to look at your use cases for the cloud you are building and decide what will be embedded as part of the image and what will be software package installations.
Another aspect of image templates that must be considered when creating a cloud service catalog is the maintenance of the base images and software packages after the cloud is running. After image templates are in the service catalog and being deployed by users, be sure that standard service management approaches such as change control, patch management and compliance management are applied to both software packages and image templates. In addition, the virtual machines that have already been deployed based on the existing image templates, the service catalog also needs a remediation plan as patches and new software versions are available.
Proper image template planning is critical to a successful cloud service catalog. This planning includes assessing the business requirements of the cloud and determining what components make sense to be part of the base image template and what components should be software package installations. In addition, as the configuration of these image templates become more customized, be sure to consider that the more customized the image the fewer use cases it will probably cater to. The goal of a successful image catalog should be to have enough images that meet the business need, while minimizing the amount of maintenance that is needed to maintain the service catalog image templates. Finally, after determining what template images will be created and what components will be part of the images versus software packages, it is important to leverage standard service management best practices to ensure software upgrade, patch, and compliance management are applied to the image templates in the cloud service catalog.