What is Infrastructure as Code? (IaC): Tools, Use Cases, and More

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 Does Infrastructure as Code Work?
• Infrastructure as Code Tools
• Infrastructure as Code (IaC) vs. Infrastructure as a Service (IaaS)
• 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.

How Does Infrastructure as Code Work?

Infrastructure as code collects information like configurations, resource dependencies, resource properties, instructions, access, and version control information to enable automation.

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.

Infrastructure as Code Tools

Infrastructure as code tools re used to automate the creation, deployment, and management of infrastructure resources. Tasks that can be automated by an infrastructure as code tool include:

• Deploying applications

• Managing storage

• Scaling infrastructure

• Disaster recovery

• Configuring networks

• Creating and provisioning servers

Puppet is just one example of a platform that provides infrastructure as code provisioning and configuration. Terraform, Ansible, Chef, and Saltstack offer different capabilities to meet your infrastructure goals. Using an infrastructure as code tool like Puppet, you might automate the deployment of applications across end devices or keep servers up-to-date with security patches. You could create and enforce rules around configuration settings and dependencies to ensure that devices are in line with company policy. 

With a range of infrastructure as code tools, each with their own specialty and capabilities, it's important to consider what your organization needs. How often are you rolling out applications or updates? How many servers do you have, and how many end users are you reaching? 

Infrastructure as Code (IaC) vs. Infrastructure as a Service (IaaS)

Infrastructure as code (IaC) and infrastructure as a service (IaaS) are two different things. The main difference is that IaC turns infrastructure configurations into lines of code so they can be managed automatically. IaaS offers on-demand virtual computing resources via the internet (like servers, networking, and storage).

You can think of IaC as the set of instructions for provisioning and configuring IT resources and services – just turned into code, so you can automate, repeat, and manage them easily. Examples of IaC include Puppet, Terraform, and Chef.

See how Puppet IaC stacks up: Puppet vs. Terraform and Puppet vs. Chef >>

On the other hand, IaaS doesn’t define any system-level configurations. It just gives you resources and services you need to run your application code, with all the necessary configurations built in. Examples of IaaS include Amazon AWS, Microsoft Azure, and Google Cloud Platform.

Learn how automation simplifies multi-cloud deployment across IaaS providers >>

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.

🔏 Policy as Code: It's like IaC for compliance. Learn more with our free eBook. DISCOVER POLICY AS CODE

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.

Beyond just scalability, there are reasons that DevOps would see the benefit of infrastructure as code in the long run — auditability is a powerful reason. A clear record of infrastructure changes means that time is saved when troubleshooting is required, which is extremely helpful for compliance and auditing purposes. 

When code can be reproduced, testing, debugging, and disaster recovery are also part of the benefits of infrastructure as code. For any organization, no matter how complex, there are going to be risks associated with managing infrastrucure across different users, devices, and for different needs. You might not be able to foresee these issues, but you can implement a repeatable way to handle issues that appear. IaC acts as both the fire alarm and a fire extinguisher for situations like these. 

Using Infrastructure as Code: Factors to Consider

If you're not currently using infrastructure as code, you'll want to ask yourself:

• How important is security to your org? Infrastructure as code can provide a clear record of all changes made within your infrastructure — ultimately helping to identify and mitigate security risks. 
• How complicated is your current infrastructure? Infrastructure as code can help wrangle all of the different components in one place by tracking and managing everything in one place. 
• How often does your infrastructure change? Automating provisioning and configuration is a great way to save time and effort, especially if you change infrastructure frequently. 
• Who will be managing your infrastructure? No matter how your DevOps teams is structured, the common language around infrastructure as code can encourage collaboration. 

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 — ultimately making your IT organization more responsive, collaborative, faster, and more innovative.

Puppet can help you reach your DevOps goals using infrastructure as code for your specific organizational needs. Even better, you can see how Puppet works within your infrastructure with a free trial: 

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? Check out our up-to-date Puppet learning resources.

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