Infrastructure as Code is a DevOps practice taking IT industry by storm. Do you know what it is?

People who have only a vague idea about DevOps may not realize the significance of the Infrastructure as Code (IaC) approach and the positive impact it has on all stages of the development cycle.

Let’s see how IaC emerged and why it’s making such a big difference to DevOps productivity and businesses’ ability to experiment and release important software features on time.

What is Infrastructure as Code (IaC)?

Before we define IaC, let us first define infrastructure. If a DevOps engineer wanted to explain infrastructure to a five-year-old, they would probably say something like, “It is that part of your app environment that nobody ever notices until it stops working.” To be more specific, it’s the servers and networks that power a particular software application or a group of apps.

Now let us define Infrastructure as Code. The Infrastructure as Code approach lies in automating infrastructure provisioning and configuration with ready-made scripts and templates.

Creating and managing infrastructure is both complex and complicated. Adding to the complexity are numerous integrations that go into a typical app these days. Plus, there is a trend for microservice architecture and containerization, which also increases complexity. At the same time, complications may arise out of confusion that exists around infrastructure management, especially when one has to deal with a legacy system.

Both these complexities and complications are reduced thanks to IaC.

A brief history of IaC

In his book “Infrastructure as Code — Managing Servers in the Cloud,” author Kief Morris draws a line between the two periods in the IT history (technically, the period before and after IaC), which he calls the Iron Age and the Cloud Age:

In the ‘Iron Age’ of IT, systems were directly bound to physical hardware. Provisioning and maintaining infrastructure was manual work [emphasis added], forcing humans to spend their time pointing, clicking, and typing to keep the gears turning. Because changes involved so much work, change management processes emphasized careful up-front consideration, design, and review work. This made sense because getting it wrong was expensive.

And in between those two ages, Kief Morris mentions a kind of transition phase – the virtual machines period.

So, we may say that, initially, sysadmins and infrastructure engineers would set up everything by hand on “bare metal” servers. Then came the virtualization, which decoupled actual servers from their virtual representation, allowing DevOps to split and allocate server space more freely. There came custom shell scripts, too – but it was hard to keep those uniform across your infrastructure.

Eventually, the Cloud Age arrived, which brought with itself uniform configuration templates: Chef recipes, Ansible playbooks, AWS CloudFormation, and Terraform templates. These templates can be kept in sync much more easily with automatic monitoring and updates. A bunch of other cool things appeared, like Docker container orchestration with Kubernetes and automated configuration drift management. We’re now in the Cloud Age of IT and can take full advantage of the modern IaC practices.

The benefits of IaC

So, now let’s see how Infrastructure as Code helps streamline, speed up, and facilitate the process of provisioning and configuring software infrastructure. Here are some of the most obvious benefits:

• Shorter lead time (less time to go from code commit to code running in production).
• Shorter recovery time (you can quickly rebuild infrastructure from a template).
• Consistency (development/testing environment is the same as production).
• Fewer errors (DevOps make fewer mistakes due to the reduced “human factor”).
• Transparency (once put into code, infrastructure documents itself).
• Scalability (effortless horizontal scaling).
• Security (automated threat detection and security testing).

Now let’s compare different infrastructure engineering practices of the past with those of the IaC era:

Things to watch out for

Automation is about amplifying things. When virtual machines first appeared, it was tempting to create a new server each time you needed one. But you need to think about how you are going to manage those servers once their number goes over the board. And what happens if you make changes to one environment – will you have to copy them to other instances? Which ones?

Errors on steroids

If you make an error during the provisioning stage, you can get it amplified by scaling that configuration to a large number of servers. So think about a way to identify the affected servers and fix the problem across all of them at once – otherwise it will be a nightmare to debug.

Configuration drift

In the ideal world, you should refrain from making manual changes to a template once it’s run. And if you do, watch out for configuration drift. Again, there are ways to detect and fix it automatically.

Docker container orchestration

App instances get increasingly containerized these days, and that creates additional complexity. You can use tools like Kubernetes to orchestrate Docker containers to make things simpler.

In conclusion

Most DevOps these days automate infrastructure with IaC. That is, they use standard provisioning and configuration templates to allocate server space, perform load balancing, and configure runtime environments as needed. This approach leads to much greater transparency, reduced lead time, and other benefits, allowing DevOps engineers to focus more on strategic tasks.

Still, a highly automated infrastructure is a challenge in itself. Although, when you fix a bug, you fix it in all instances — when you introduce a bug, you risk amplifying it across the entire infrastructure. Hence, it’s better to leave infrastructure automation to professional service providers.

Related Blogs

In the cloud, everyone is looking to save

LEARN MORE

Real benefits of adjoining DevOps culture to your Agile processes (supported by hard numbers)

LEARN MORE

Digitize

with ObjectStyle

See our work