What is Infrastructure as Code?

As IT organizations wrap their heads around DevOps, there’s one term they often find being used with "DevOps": infrastructure as code. It's an important term to understand because it's one of the essential elements of managing infrastructure at scale, and it's also at the very core of DevOps.

Table of Contents:

• What is Infrastructure as Code?
• How Infrastructure as Code Helps Organizations Work Faster and Better
• Why Infrastructure as Code is Important for DevOps
• Using Infrastructure as Code: Factors to Consider
• Get Started with Puppet's Infrastructure as Code

What is Infrastructure as Code?

Infrastructure as code (IaC) is the practice of treating infrastructure as if it were code — just like software. Infrastructure as code enables organizations to automate tasks and processes that would otherwise be done manually, like managing infrastructure and provisioning resources.

Treating infrastructure as if it were code lets you adopt powerful practices that have been used by software developers for years, and with great success — practices that include version control, peer review, automated testing, release tagging, release promotion, and continuous delivery.

The older methods of infrastructure management — manual processes and documentation, brittle single-purpose scripts, and graphical user interface based tools — each had their uses in the past. Today, though, with the perpetual need to scale infrastructure, adoption of ephemeral infrastructure, and greater application system complexity, new ways of keeping things under control are needed.

The wide adoption of virtualization and self-service cloud infrastructure has shifted the bottleneck from allocating servers to configuring them. Where it used to take weeks or months to allocate a server, now it can be done in a minute or two.

These new challenges require a change to the way IT works, but the primary challenges are the same as they’ve always been:

• Develop the most reasonable change for a problem, then propose its adoption into the main codebase through a pull request.
• Reasonably prove a given change is safe and correct by deploying it to a production like environment and run a sufficient number of tests.
• Orchestrate change to a potentially large and complex portion of the infrastructure.
• Know at any moment the current state of any part of the infrastructure, especially its health.
• Know the history of any configuration, including who proposed it, who approved, and when it was applied.
• Do all of the above as quickly, efficiently, reliably and securely as possible.

To address these challenges at modern scale (both in terms of infrastructure and organization), while still keeping up with the needs of the business (not to mention keeping the lights on), you need new methods of collaborating, delivering, and gaining situational awareness.

How Infrastructure as Code Helps Organizations Work Faster and Better

Previous methods of IT management won't work if you're trying to address modern scale and agility requirements. Graphical tools often have a low learning curve, but they fall apart when trying to account for differences between platforms or porting configurations as code progresses from one environment to another. Graphical tools also make it difficult — or impossible — to share pieces of configuration with other teams, do peer review on proposed changes, view historical changes, and roll back to a previous set of configurations. And scripts are equally unsuitable for modern scale and agility. They're brittle, unmaintainable, are sprawled throughout teams and individuals, and are rarely portable between environments.

Defining your infrastructure as code solves these problems because code is portable, reusable, shareable, testable, and introspectable. And in case we haven't said it clearly enough, manual changes are just terrible — period.

Why Infrastructure as Code is Important for DevOps

Code is portable, reusable, and can be managed with version control. By using infrastructure as code, as changes are made to the code, these changes are committed to version control, where they can be peer-reviewed, tested, collaborated on, and approved (merged) by peers.

Once the change has been accepted, it can be automatically deployed to thousands of systems just as easily as to a single system. The version control system also provides an audit history. Using a continuous integration/continuous delivery system, these steps can be codified into a continuous delivery pipeline. The result of using infrastructure as code with version control is a workflow that promotes collaboration, dramatically shortens feedback loops, reduces deployment risk, and keeps a continuous history of who did what.

Gene Kim’s Three Ways is a path towards continuously improving IT’s ability to serve the business through rapid learning, experimentation, and continuous feedback loops. With the Three Ways, IT builds and reinforces a culture of fast feedback, collaboration, iteration, and visibility — all of which support the rapid learning, experimentation and continuous feedback that help the business become more competitive.

The cultural characteristics of the Three Ways are enforced through the technical practices of infrastructure automation, peer review, continuous delivery, automated testing, and deployment automation. All of these technical practices, by the way, are DevOps practices, and all are enabled by managing infrastructure as code.

Using Infrastructure as Code: Factors to Consider

In order to align everyone in IT, it’s important to establish a common language for everyone to use when contributing to and managing infrastructure. With a common language, everyone can propose infrastructure improvements, collaborate on infrastructure implementations, and read the code itself to understand how any part of the infrastructure is being managed. (You may have seen the term "executable documentation" for infrastructure code. That's because the code itself enforces the documented infrastructure policies.)

When choosing your infrastructure code language, there are important factors you should consider. Since you want everyone aligning with a common language, the language needs to have a low learning curve, be declarative, be idempotent, and holistically manage the infrastructure as a single source of truth. Let’s break that down.

1. Easy adoption

It’s important to consider the strengths and skill level of everyone who contributes to the infrastructure. Are they all software developers with degrees in computer science? Probably not. At the same time, do not underestimate their capabilities, nor their experience in writing some form of code. Ask your DBA to show you their PL/SQL queries — that should convince you your DBA really does know how to write code. Or ask to see your Windows administrator’s batch files or login scripts. Almost anyone in IT can pick up an infrastructure language, provided it is well-designed, purpose-built, and imposes a strong opinion on how it should be used.

2. Idempotence

Idempotence is defined as the property of an action always having the same result. A example in mathematics is taking the absolute value of a number and continuing to apply the absolute value to the result. No matter how many times you perform that operation, the result is always the same. An example operation from Unix is the rm -f command. No matter the beginning state, the result is always that the file does not exist.

The more your code is idempotent, the more it can handle any condition, and always do the correct thing. Idempotency is a critical component to successfully using infrastructure as code.

3. Holistic modeling

As more and more of your IT team contributes to the infrastructure code, you need to know the solution you’ve chosen can scale to potentially hundreds of contributors across a plethora of teams. Where are all the different places the infrastructure code can live? How many different pieces of code manage the same system? What happens when two contributors write code that manages the same configuration differently?

With holistic modeling, all the infrastructure code is combined to a single central source of truth that identifies how each piece of infrastructure code relates to every other piece. Because the relationships between all the pieces of code is understood, common mistakes such as two contributors trying to manage the same configuration differently are caught, and problems averted.

Get Started with Puppet's Infrastructure as Code

Puppet was born from the combination of software development and operations and grew as the concept of DevOps gained traction, and infrastructure as code is at the center of it all. With infrastructure as code, Puppet allows you to scale your infrastructure automation with your organization's IT needs, meaning you can do more provisioning, deliver apps faster, stay in compliance, and build more resilient infrastructure with code – and get the same result every time.

Infrastructure as code is an important practice to adopt if you want to implement DevOps in your organization. I hope this has helped you understand the importance of infrastructure as code in making your IT organization more responsive, collaborative, faster, and ultimately more innovative.

START MY PUPPET TRIAL

Learn More

• Download this white paper: Accelerate Digital Transformation with an Infrastructure as Code Strategy
• Video: automation engineer Jeremy Rose talks about infrastructure as code at ERCOT.
• Haven't tried Puppet Enterprise yet? Download the Learning VM for free and get a hands-on experience of infrastructure as code.

This blog was originally published on February 9, 2017, and has since been updated for accuracy and relevance.