Clone vs. script OS builds: Why “time to deploy” is not the only deciding factor

Guest post by

By Sebastien Reister, HP Senior Cloud Architect

 

It’s a long-standing debate in the IT trenches: when automating the deployment of an OS, do you clone (i.e. image build) or perform an unattended scripted install? 

 

Most proponents for cloning argue that the deciding factor is the time to deploy. After all, if you’re dealing with Windows, it can take mere minutes for cloning. But with a scripted install, you could be at it for upwards of an hour, depending on the hardware and version of OS.

 

Seems like a pretty clear-cut case for cloning. But I think there are other factors you also need to consider when choosing between cloning and scripting.

 

OS maintenance

The first factor to consider is how you maintain operating systems. Rarely do you have just one OS to deploy, and almost never just one version with a single configuration.

 

With cloning, you can maintain one image for each type of hardware, or pre-install all drivers for all hardware. In scripting, on the other hand, you can have one script that will install all drivers or one script for each type of hardware, or use a “smart script” that installs the right drivers based on a range of inputs, such as menu, detection and parameters.

 

Patching

It’s much the same story with patching: you will have different patch policies based on the hardware, targeted usage and the area you deploy the server. Cloning gives you three approaches: install all patches; create as many images as you have patch policies; or drop in a scripted patch deployment after the system is cloned.

 

In a scripted model, you can either decide to deploy all patches or use a smart script that will decide which patch to deploy.

 

The impact of variations

For every variation in the OS version, customization, hardware drivers, OS configuration and base applications that has to be deployed, you could potentially have a different cloned image. The impact of these variations can be illustrated in the form of a decision tree diagram (Figure 1). With just two variations at each of the five layers, it can quickly become quite complex (25 = 32), and potentially doubled (or more) again with differences between Virtual and Physical OS deployments.

 

Slide2.png

 

Fig. 1: Example of a decision tree of customized OS deployments

 

With image-based deployments, you need to decide what variations get included in each cloned image. Although for each image you will reduce your time to deploy, but also multiply the number of cloned images to manage. At some point, you will want to stop creating new cloned images and instead rely on scripting to address any variations or options.

 

For example, you will likely need to limit variations in OS version, OS customization and HW drivers, because these require a lot of storage. This is where image-based cloning deployment proves to be the most efficient.

 

However, when it comes to OS configuration and base applications, depending on your use cases, you could have a range of 5 to 20 variations. This is where image-based cloning is not as practical anymore—automation through scripting is a better way to go.

 

Network requirements

In my view, here is the real clincher: how ready is the network to handle the OS provisioning infrastructure? Depending on the type of image-based cloning technology, you may be able to insert the network configuration during deployment, which is a big advantage. But with some hardware, you will need a different technology for each, which increases your complexity and makes the maintenance of all systems a little bit harder. Also, some technologies require a complex form of access to the network that could go against your security protocol.

 

On the other hand, scripted technologies always need to control the server first. This means you must have DHCP and PXE infrastructure in place. Whether you use Windows, Linux, AIX, Solaris, or HP-UX, they all need the same requirements: DHCP and PXE/BOOTP. Being able to standardize on those requirements, rather than creating a unique cloned image for each network hardware configuration, greatly simplifies OS builds.

 

In other words, it’s not time to deploy but the network requirements for OS provisioning that should influence your decision about image-based versus scripting OS builds.

 

Time to deploy

Of course, time to deploy cannot be overlooked. The delta between deploying an image deploying a scripted OS is admittedly huge: if your storage is good and your images are optimized, you can deploy an OS in less than 1 minute, compared to a scripted install that usually requires between 30 minutes to 1 hour.

 

Although that is a huge difference, I still say it’s just a minor point. What I think you need to consider is that the end-to-end process of deploying a server will always take 1 or 2 hours if you want to have everything integrated. And unless you are a big IaaS provider, it’s not necessary.

 

Making the best decision

By now we have a rough idea of what makes the difference between the two:

 

  1. Network configuration
  2. Number of images to maintain
  3. Time to deploy

 

Here is a handy table that can help the decision process:

 

How many types of OS need to be deployed?

 

Is fast deployment important?

 

Hardware or Virtual or both?

 

Is your network complex?

 

How many different options?

 

 

The more complex your scenario, the more likely you will benefit from a scripted install, while in simpler simple image-based provisioning is the easiest to use.

 

The exception to this rule is the network, which can be a tough call. Even when you use image cloning, some technologies require a complex form of access to the network that could go against your security protocol.

 

Take a high level view

So how do you decide in the end? I recommend making a decision tree of all the options you have at each layer and then decide where you want to cope with the greater amount of complexity: the number of images to manage or the number of options to manage in your scripted install?

 Image vs scripts.png

Learn more

I was recently the special guest on an HP Power to Change virtual event session titled, “Automate lately? The value of automation with or without cloud”. Check out this free online session to learn practical advice about the fundamentals of automation and how it fits into a larger cloud strategy. Registration gets you access to 15 other sessions, too.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
This account is for guest bloggers. The blog post will identify the blogger.


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation