Building and Maintaining Image Templates for the Cloud

As IaaS platforms like OpenStack gain traction in delivering compute and storage resources on demand, we’re seeing telco and enterprise IT customers increasingly focus on “software on demand”. Typically existing software delivery processes are too lengthy to take full advantage of the “instant-on” nature of the cloud. End users need to be able choose and instantly provision software and applications, then decommission them when no longer required. Consequently this raises many questions: how do I get apps onto an IaaS platform? how do I ensure software governance if somebody else is providing the apps as part of an app store? how do I build and maintain software images through time, making cloud deployments predictable and consistent?

Today, software images are often built manually, making them difficult to update and maintain over time. Cloud users are now realizing the need to work with transparent image templates which enable them to trace individual software components, versions and licenses. They are combining these templates with automated software delivery processes, using APIs to industrialize image creation and maintenance. This enables them to easily track components, add or update software automatically, and generate to one or many clouds. The image remains consistent and predictable, whether it’s used only within a private cloud or as part of a hybrid model for bursting into Amazon, for example.

Customers can take different approaches to building and deploying these images. Firstly, the devops model uses a base image that contains only basic packages to boot the OS. Once it’s installed, a phone home feature enables the devops platform to install all the packages that a particular service needs. This is a great model for many customers. However, others are realizing that it takes a long time to stand up the service, if you’re installing say 400 VMs from an outside repository. In a cloud model, you’re also paying for bandwidth and other resources over that time.

Secondly, customers can use more complete images that include not only the OS packages but also middleware and applications. They can then combine these with a devops platform for configuration, which is a very flexible way to push configuration information without some of the disadvantages we discussed earlier.

Finally, there are “fully baked”, self-contained images that include all the software components, as well as configuration logic. These images can be used to turn a specific solution on within a private or public cloud without a great deal of expertise and are often used by ISVs for quickly ramping up POCs, for example, at a customer site.


Whichever approach you take, it’s essential to remember that all three approaches require to control and maintain the base image over time. You must be able to track the packages and components you’re using, even in a devops base image, otherwise you’ll quickly end up with scores of unmanageable images.

Easy traceability and maintenance will also help you transition to the next phase of cloud software deployments: moving from a monolithic image for small deployments or test purposes to multi-tier images for pre-production and production deployments on a larger scale. You’ll be able to more easily piece together multiple VMs, provision, maintain and decommission complete solutions over multiple cloud nodes.

James Weir

CTO, UShareSoft

Trackbacks/Pingbacks

  1.  - Boston 2 Phoenix
  2.  Webmaster Crap » Blog Archive » Building and Maintaining Image Templates for the Cloud » The …
  3.  Building and Maintaining Image Templates for the Cloud » The … | blog, iphone, app, creative, games, programming, project, various
  4.  Cloud Image Life cycle management | Slash Cloud . Net

Leave a Reply

Your email address will not be published. Required fields are marked *