Breaking news, industry blogs and live commentary

IBM News on Ulitzer

Subscribe to IBM News on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get IBM News on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

IBM Journal Authors: Elizabeth White, Yeshim Deniz, Liz McMillan, Janakiram MSV, Jason Bloomberg

Related Topics: Cloud Computing, Virtualization Magazine, Desktop Virtualization Journal, IBM Journal

Blog Post

All Virtual Images Are Not Created Equal

Understanding the impacts of virtual image choices

IBM Session at Cloud Expo

Chances are if you are using the cloud to run your application environments, you are using some type of virtual image. For the most part, you can categorize these virtual images as one of two types: those that include an operating system and those that do not.

You may think, "What's the difference? The result is the same. I get my application middleware software running in a virtual machine." I cannot argue the fact that the result is mostly the same, but the difference in the packaging of the virtual image has impacts on the operational and cultural processes in your organization. It helps to understand these impacts as you make what seems like an innocent decision.

First, let's consider the operational impacts of choosing either of these types of virtual images. If you choose the virtual image with an embedded operating system, this means the virtual image becomes the center of gravity for your work on the software in your application environments. All of the custom tuning and configuration that makes your application environments unique applies to components inside of the image. From a technical standpoint, this provides the advantage of being able to codify your application environments into an atomic unit (the virtual image). It has interesting cultural impacts that we will discuss a bit later.

On the other hand, if you choose to use an image that contains just the application platform software and some type of resource coordinator (something that communicates with an operating system or hypervisor), then the virtual image is no longer your center of gravity. To tailor your application environments, you need to apply customizations to the application middleware inside of your virtual image as well as to whatever is acting as your operating system, which is separate from the virtual image.

The deployment process for these virtual images is likely to vary as well. For a virtual image that contains the operating system, a hypervisor host on which you can activate the image will probably be the deployment target. For virtual images without the operating system, the deployment target will vary. The target could be partitions running on top of a natively installed operating system, an already activated guest operating system, or perhaps even a hypervisor (if the image contains a resource-scheduling layer). While it is true that the virtual image without the operating system may give you more options with respect to deployment, in many cases it also means a more segregated management experience. You have to manage and maintain the middleware software and operating system environments separately.

Understanding the operational impacts of choosing one type of image over another is only one piece of the puzzle. In fact, the cultural impacts may be an even greater factor in making your decision on which type of image to choose.

In most IT organizations today, the team responsible for managing operating systems is completely separate from the team that manages application middleware software. Why does that little nugget matter to this conversation? Well, if you use an image that contains both the application middleware and operating system software, you are likely to disrupt culture a bit. Now, two different teams will be making their customizations on the same entity, and one team will be responsible for "installing" both the operating system and application middleware software by activating the virtual image. This will require new inter-team interactions, well-defined access controls, and a clear delineation of responsibilities.

In addition, to the potential for the disruption of inter-team dynamics posed by the all-in-one virtual image, there is also the chance that this packaging challenges the operating system culture in your organization. Since the virtual image packages the operating system, you may or may not have the ability to run the middleware software on the operating system platform to which your organization is accustomed.  In my opinion, operating system friction is largely cultural. Many times when pressed about the choice of running application middleware on one operating system versus another, I hear "That's just the way we do it." Of course, to say it is always cultural is naïve. In some cases, existing investment in skill, resource, licenses makes it fiscally irresponsible to consider other operating system platforms. All of these factors come into play when using the operating system inclusive virtual image.

While the choice of the type of virtual image you use may seem largely innocuous, it is anything but. It will most certainly have impacts that span the operational and cultural domains in your organization. Understanding these impacts as you decide upon the right type of virtual image for the job is a key component to getting started down the right virtualization path.

More Stories By Dustin Amrhein

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, he worked on the development of Web services infrastructure and Web services programming models. In his current role, Dustin is a technical specialist for cloud, mobile, and data grid technology in IBM's WebSphere portfolio. He blogs at You can follow him on Twitter at