Here we’re going to be looking at the the idea of applying automation tools to the wider product development process. Tools that help you do this are part of a collection known as “Infrastructure as Code”, which refers to the the provisioning of compute instances (physical machines and their operating systems) and software applications using revision-controlled machine-readable text files.

A comprehensive discussion of “Infrastructure as Code” (IaC) can be found on Wikipedia. We’ll explore the risks of not automating your deployment process in this article.

Now that this area of development has a neat name IaC has gained significant popularity in the wider industry as well as appearing as a “desirable skill” in Job specifications.

It’s all about: -

• Making it Repeatable
• Using revision control
• Eliminating human error

IaC tools address these areas.

Should you be putting more effort into IaC?

Well, that depends on what your specific circumstances but you are probably already relying on clever build systems like Ant, Gradle, Make and Maven to automate the compilation process. These tools prevent you from having to navigate into each source directory in order to compile it and construct a runnable image. These tools let you concentrate on the value you’re adding (the code) and avoid you having to worry about compiling.

That’s good.

IaC is about automating the provisioning of your compiled application and allow you to use tools not people.

We often do not utilise tools of this type because: -

1. There are lots of them and there may be no emerging industry standard
2. The learning curve can be time-consuming
3. The time to automate something, even with a shell script, can consume significant effort in order to make is repeatable. Often it appears to be easier to just do it rather than spending all that extra time automating it.

That’s understandable. 1. and 2. is always a risk, especially as it’s often difficult to understand what these tools can do for you and learning a new tool is always a concern because it may well be usurped by yet another new tool in the industry. 3. is more-often-than-not simply a “false economy”.

Yes, automating a process can be time-consuming to get it right and it’s always significantly more tempting to “just do it” because we think that “we don’t have a lot of time” to do anything else.

Maybe you don’t have time because you’re spending too much time nursing your current process?

In a previous role I attended the roll-out of the company’s main software product to a new customer site. I was there simply to record the process and identify any areas of the installation that would benefit from improvements as there was some concern within the company that the roll-out was taking too much time.

It was a complex product with multiple compute instances, networks to be setup, Docker to configure, databases to be installed and configured and various application technologies deployed. The deployment was accompanied by a 50-page installation guide written by all the key developers.

The deployment occupied the best part of the day and around eight separate members of staff were required at various points to complete the processes.

The main problem with the installation was that most of it required individuals to work around mistakes in the guide, mistake in the software packaging and to resolve issues that cropped up during the day. The roll-out was achieved by basically reading the guide and typing the instructions on a keyboard to do things like login to remote machines, setup networking, transfer files, unpack files and run dozens and dozens of commands.

Over the 8 hour period 27 human errors were made, some minor, some major. That’s a human error every 18 minutes!

Yes, you will make mistakes refining your automation process but you won’t be risking making the same mistake again and again. Instead you can divert your newly acquired effort adding value to the product.

I’ll leave you to asses the risk of things like…

• Stopping the wrong server
• Removing the wrong file

Any one operation could be catastrophic.

Do you still think you don’t have time to automate?

In summary…

If you feel the need to spend the time writing and reviewing a large installation guide then you probably need to pause and see if you’d prefer your key developers to be tied up writing and reviewing installation guides (that almost always have errors in them, regardless of how often they’ve been reviewed) or having them spend time leveraging the power of automation through the use of IaC tools and produce something repeatable, under source control and (hopefully) executing with fewer errors.

In the past the “Small Fish” were eaten by the “Big Fish”. Today the “Fast Fish” eat the “Slow Fish”.

At the end of the day it’s about “time to market”. The faster guy is likely to win.

It’s always worth continually reviewing your own production process to see if there are any areas that can benefit from the removal of the risk of human error.

It’s what we do.

In a future article we’ll explore the specific benefits of some of the tools we’ve chosen to use. In the meantime feel free to take a look at the following frameworks to see if they offer anything that would benefit you.

• Packer
• Terraform
• Ansible

We’ll explore each of these later to show you how to automate the build of a reference base operating system image, the creation of a cloud-based compute cluster and deploy your applications to that cluster.