Infrastructure as Code: The DevOps Standard

Infrastructure as Code (IaC) supports DevOps best practices by facilitating the creation of repeatable infrastructure environments using a declarative language. This article explores what IaC is, the benefits it offers from a DevOps perspective, and some of the most popular IaC tools available today.

If you’re a DevOps engineer looking to advance your career, you’ve probably heard of Infrastructure as Code (IaC). Infrastructure as Code has emerged as a key component of the DevOps movement, which aims to improve communication and collaboration between development and operations teams.

The benefits of IaC include declarative infrastructure management, version control of infrastructure changes, and collaboration with other team members on these changes.

In this article, you’ll learn the basics of IaC and how to build an infrastructure as code pipeline. You’ll also discover how to use some common IaC tools to implement automated and versioned infrastructure deployment.

How Can Infrastructure as Code Improve DevOps?

Provisioning infrastructure has always been a challenge, dating back to when the only way to increase capacity was to either add more servers to the data center rack or upgrade the servers in that rack. Provisioning new servers was a time-consuming and error-prone process that could take weeks or even months, sometimes involving desperate trips to places like eBay to make ends meet.

With the advent of cloud computing, an API came into play, allowing thousands of instances to be provisioned in seconds, eliminating the physical dependency on managing hardware logistics. Teams began interacting with the API, either through a portal or code, to create instances as needed without incurring capital expenditures (i.e., purchasing physical goods). Unfortunately, this came with some significant drawbacks. Knowledge about the infrastructure remained in the hands of a single person or a small group, and sharing this knowledge was difficult when new members joined or a key employee left the company. With things in the hands of a few or even just one person, the “bus factor” came into play. If one of these key people left the company, it could spell disaster.

Moreover, despite the advantages of cloud computing, infrastructure provisioning remained an error-prone and slow, manual process. Human errors crept in when changes to the running environment were not recorded or communicated to the responsible parties. Documentation of the infrastructure setup became outdated the moment it was written and was regarded with the same casual loyalty as doodling on a napkin for amusement. It was a mess.

Compliance and audit issues also arose, as a myriad of services ran and were updated without a plan of the infrastructure; you can’t know if you’re patched against a security issue if you don’t know which machines are potentially affected.

With the introduction of IaC, infrastructure provisioning became much easier, faster, and more reliable, eliminating many of the aforementioned shortcomings. One could even say that IaC brought the same benefits to infrastructure as DevOps did to software development.

In particular, you can continuously create, destroy, and update your infrastructure using the same process and tools you use for your application code, as prescribed by your DevOps practices. This means IaC offers your infrastructure the same benefits that a DevOps workflow provides your code. You can also use the same collaboration and review tools to track your infrastructure changes as you do with your code changes. This makes it much easier to manage and understand your infrastructure and quickly identify and fix issues.

IaC also facilitates the automation of infrastructure provisioning, saving a lot of time and effort. Manual interventions can even be entirely eliminated. This can significantly improve the speed and reliability of your infrastructure provisioning process and make scaling your infrastructure as needed much easier. Need to set up more servers? Add a line to the code. Need to shut down those servers? Remove that line from the code. It’s really that simple.

Overview of Infrastructure as Code

A clear understanding of the benefits of IaC tools can help teams and companies appreciate their significance. Among the many benefits, cost savings, flexibility, and less risky implementations stand out.

Costs

Saving money is a crucial aspect for businesses, and IaC is a great way to achieve this. When using IaC tools, infrastructure knowledge is stored in code rather than in people. This allows you to work efficiently with smaller teams for deploying and managing infrastructure. Additionally, because these tools enable consistent and automated deployments, savings occur in the form of fewer errors and high availability.

Large companies can lose millions of dollars with each minute of downtime, so avoiding downtime due to misconfigurations is a surefire way to save money. When you use IaC tools, you also have less overhead because the configuration code is easy to maintain, and you can understand the dependencies between different resources by looking at the source code.

Finally, the ability to deploy code and infrastructure quickly and in a repeatable manner allows for faster time to market, as you can focus on core business logic rather than the error-prone task of manually managing and deploying infrastructure.

Agility

Modern software deployment is all about speed and agility. With IaC, teams can quickly respond to traffic spikes by automatically provisioning and configuring resources as needed. For example, suppose you operate a cluster with five nodes and receive ten thousand requests per second. Suddenly, there’s a spike to nineteen thousand requests per second. Manually scaling up would take hours to add and configure the necessary capacity. With the appropriate IaC tools, you can simply scale the cluster up to ten nodes, and the doubled capacity would be available almost immediately.

The most helpful aspect is that by changing a few parameters, you can create QA, pre-production, and production deployments without having to laboriously start from scratch.

Risks

Secure services are crucial when dealing with applications and data. It’s often challenging to configure these services without creating security vulnerabilities.

Infrastructure as Code can help mitigate these risks by automating the deployment of these services, ensuring they are configured securely and consistently. You don’t need to open an interface to your portal to configure things manually, nor worry about hackers sneaking in through backdoors. Since these processes are now automated, they can also be easily repeated if something goes wrong.

Finally, IaC can help make setting up new servers simpler and more repeatable. This ensures that new servers are configured correctly and securely from the start.

IaC Methods and Protocols

No tool can be used for everything, so it’s always more efficient to use specific tools suited for the task at hand. That said, Infrastructure as Code can be broadly categorized into some categories: imperative or declarative and push or pull.

Imperative vs. Declarative

Imperative IaC means writing code that explicitly describes every step required to provision your infrastructure. This is often referred to as procedural code. An example would be using a shell script to provision and configure a virtual machine.

In contrast, with declarative IaC, you write code that specifies the desired state of your infrastructure. Using a tool like Terraform to configure and provision a set of virtual machines or container orchestrators like Kubernetes is an example of this. You specify which provider you want to set up the cluster in and provide the tool with plugins and authentication tokens. After making the changes, the tool takes care of the rest.

The main difference between the two approaches is that with imperative IaC, you need to write code to describe every step required to provision your infrastructure. This can be time-consuming and error-prone.

With declarative IaC, you only need to write code to specify the desired state of your infrastructure, and the IaC tool figures out what it needs to do to achieve that state. Since this is less time-consuming and error-prone, most popular tools (like Terraform and Pulumi) use a declarative approach.

Push vs. Pull Configuration

With push configuration, configuration files are sent from a central repository to the servers. The approach is very simple and easy to implement. All you need is a central repository and a method to transfer files from the repository to the servers.

The main drawback of the push approach is that it can be slow and cumbersome with a large number of servers, as all configuration changes need to be pushed to all servers.

Pull configuration means that servers regularly check the central repository for changes and download the latest configuration files. The main advantage of this approach with a large number of servers is that it is much faster and easier to manage. This is because you only need to make changes in one place (the central repository), and the servers automatically pull them down.

The main disadvantage of this approach is that it is more challenging to set up (most IaC tools are geared towards the push model) and that conflicts can arise if changes are made on the server before the pull is completed. However, this is unlikely to be an issue as it’s not advisable to play around in a live environment, which is typically restricted.

The pull method is more popular and efficient as it allows for testing before infrastructure deployment. It also enables centralized configuration storage, avoiding conflicts and establishing a single source of truth.