Infrastructure as Code 101 [DevOps Series]


Welcome back to the DevOps 101 series (you can read the first two articles here and here). Today, I’m going to look at one of the key foundational concepts of DevOps and the Continuous Deployment model, Infrastructure as Code

Continuous Deployment is about deploying an application. That application has to go somewhere, and a modern web application needs a variety of other supporting services and infrastructure to operate. Common examples of supporting services include, but are not limited to databases, caching services, authentication infrastructure. The services and configured infrastructure to run an application are what we call an environment.

As I touched on earlier, typically a given application will have one or more environments. Alongside the final environment, typically called production are environments for activities such as user acceptance testing, integration testing, development, and so on.

An incredibly common problem is keeping all of these environments in sync. Even a simple web application will typically have at least few services operating in concert. These services all need to be patched, configured with security and firewall rules, have various levels of logging, monitoring and alerting applied. Replicating these environments manually often is error prone, and changes over time often lead to drift.

If you’ve been following the series, you already know where this is going; it’s time to automate! Rather than building environments by hand from a checklist, turn the process into an automated and repeatable process.

This is Infrastructure as Code.

Originally, Infrastructure as Code (IaC) started out as literal code, stored in a version control repository. However, over the last fifteen years, various software tools have sprung up and been refined to abstract away many of the more repetitive parts of this code. Modern IaC tools often are sufficiently abstracted that configuration files have replaced all, or almost all of the code. AWS Cloud Formation – Cevo’s tool of choice is an example of this. The core concept remains however, and these configuration files should remain tracked in version control, developed in sync with the application.

The Benefits of IaC

There’s a multitude of benefits from using this technology. Right away, differences between development, testing and production environments are outright eliminated, and deployment of environment changes become much more predictable. Servers are turned over in minutes, with troublesome instances simply retired and replaced.

On top of this, there are several side benefits that become apparent when a team has integrated Infrastructure as Code as the norm into their regular software development practice. By its nature, Infrastructure as Code inherently documents the steps required to build the environment. Even when uncommented, the code still provides a complete blueprint of how to build an environment, and update from one version to another.

This capability to define the target, regardless of the current state, vastly simplifies roll-backs, and also enables significant experimentation, improving the teams agility and the opportunity to try new cloud services.

The combination of Infrastructure as Code and integrated cloud environment like AWS simplifies also makes it much simpler to add controls and monitoring to all of your infrastructure and applications, unlocking a wealth of data. Using this data is the next step on our devops journey, Fast Feedback.

In the meantime, if you’re looking for guidance in CI/CD, Infrastructure as Code, pipelines or other devops practices, get in touch with us.  

Cevo is the trusted leader at the forefront of continuous delivery technologies, helping our customers stay competitive through innovative solutions and building capability on the AWS platform.