Infrastructure as Code: The Ultimate Guide
What Is Infrastructure as Code (IaC) and Why Is It Gaining Popularity?
With the rise of IaC, there’s a growing demand in DevOps for direct communication with machines, enabling developers and operations to implement and manage infrastructure using a shared language.
This eliminates unnecessary layers of software interfaces, promoting a cleaner approach. There’s also a trend toward reducing complexity, moving away from what could be termed as “gunk” in software interfaces.
People seem to prefer interacting directly rather than adding extra layers to simplify commands, sometimes in plain-spoken language through large language model (LLM) interfaces that can then display the code used for infrastructure.
IaC allows for the deployment, management and scaling of infrastructure through machine or direct-to-machine code.
Given its propensity to offer a direct way to configure, deploy and manage infrastructure, IaC lends itself to version control and the extension of version control DevOps or GitOps, and in this way, it also provides scaling opportunities.
“IaC is important because it gives you a way to automate the deployment manifest of the infrastructure layer, independent of its location and scale,” Alexis Richardson, inventor of the term “GitOps,” told The New Stack.
What Are the Principles of IaC?
IaC enables the deployment, management and scaling of infrastructure through machine or direct-to-machine code. This contrasts with traditional methods that involve working through interfaces and additional software layers. Due to its direct approach, IaC facilitates version control and extends to DevOps or GitOps, offering scaling opportunities.
How Is IaC Applied to CI/CD?
The use of IaC to provision and deploy infrastructure consistently and efficiently across various environments through a command line lends itself well to CI/CD.
When IaC is applied across the production pipeline, organizations report gains in productivity and resource savings. However, not all IaC solutions are created equally. Prospective IaC users should scrutinize whether and how a particular solution can really improve the CI/CD process.
An IaC solution should provide CI/CD with:
- Automated provisioning.
- Immutable version control, so that a single repository is used to create and remove infrastructure.
- Testing capabilities throughout CI/CD.
- The ability to set policy.
- The ability to manage security.
The immutability that IaC offers CI/CD “is king,” Torsten Volk, an analyst at Enterprise Management Associates (EMA), told The New Stack. It earns this status, he said, because it “ensures consistency, a clear audit trail for easy rollbacks, unified control over security and compliance, and overall efficiency.”
How Is IaC Used to Set Policy and Manage Security?
IaC provides a unified method to handle and define policies across various configurations. Its advantages extend beyond just the declarative approach, impacting security management based on tool choices and IaC methodologies.
During his talk, “How a Bank Modernized Its Software Engineering With Infrastructure as Code Automation,” at Pulumi’s annual user conference, PulumiUP, Dennis Sauvé, DevOps engineer at Washington Trust Bank, offered a mini case study about IaC’s role in policy and security at a bank.
He noted how he works with developers “to understand their cloud infrastructure needs and coordinate how to best deploy those resources with my team and information security.”
According to Sauvé: “Working with our development team can be challenging at times. Our development team schedules around a scrum framework, whereas infrastructure works off more of a kanban triage framework, or IT after all. This means that sometimes I have a lot of bandwidth to assist with development objectives, and other times my duties on infrastructure have to take priority.”
The overarching goal of adopting IaC at Washington Trust Bank has been to “remove infrastructure availability as a bottleneck and put a lot of development environment scaffolding in the hands of the developers in the form of premade Infrastructure as Code resources and components,” Sauvé said. Automating deployments has alleviated an enormous burden of manual deployments from the infrastructure team, and “creates repeatable and reusable components for use in future projects,” Sauvé said.
Before Washington Trust Bank decided to adopt IaC into their deployment pipeline, the Federal Deposit Insurance Corporation (FDIC)’s strong regulations surrounding the protection of clients’ personal data influenced this decision, Sauvé said.
As Sauvé described: “Data breaches have a horrible impact on an organization’s clients, and all data entrusted to us must be treated as confidential. It’s because it’s the right thing to do and because the FDIC mandates it. Given that client data must be protected, using Infrastructure as Code to build out cloud resources provides a blueprint that can be reviewed and improved on by the information security team and the infrastructure team.
What Is an Example of Infrastructure as Code?
IaC involves using tools like Ansible to manage and automate IT infrastructure. Ansible requires the installation of its software and subsequent command execution. An initial step involves creating an Ansible playbook, which is composed of YAML instructions guiding Ansible on various tasks, spanning deployments, networking, service management, and security and policy configurations.
Here’s an example of YAML instructions to configure an Ansible playbook:
Once the playbook is set, the playbook is run with this command:
The output looks like this:
What Are Some of the Limitations of IaC?
IaC does have its limitations — namely, it was designed to automate and avoid the need for manual processes in creating and managing infrastructure.
Using just the bare-bones open source alternatives or tools such as Terraform can have limitations. Hence, automating those tools, offering a more direct way to provision infrastructure, or simplifying it can go a long way.
This is particularly important for developers. For example, with a tool that provides infrastructure workflow automation, IaC can help developers better provision and manage cloud infrastructure more declaratively in code files.
The idea is to make it less error-prone and more immutable for developers when provisioning infrastructure in the cloud. Offering the ability to do IaC while simplifying that process — and providing more templates that are easier to use, such as for Terraform, Ansible or any other tools — contributes to achieving this goal.
How Can IaC Be Automated or Improved?
A number of alternatives are emerging that either add layers to boost automation and add additional functionality like Terraform or Ansible or seek to replace these solutions. In the case of Terraform rival Pulumi, while Terraform claims nearly 10 times the market share of Pulumi, Pulumi’s share is growing at about two to three times the rate of Terraform’s, according to EMA. These solutions, including Nitric as well as Pulumi, are designed to provide an automation objective with IaC.
The flexibility Pulumi offers, with a choice of programming languages, is key, said Joe Duffy, Pulumi’s CEO and founder, during his keynote at Pulumi’s annual user conference, PulumiUP. “For instance, many users today are unfortunately limited to using YAML only for their deployments, which should not be the case; developers shouldn’t be limited to one language,” Duffy said.
Pulumi, on the other hand, claims to support all major programming languages, thus offering more freedom of choice and a more direct way to provision infrastructure for CI/CD and in general.
“Pulumi is IaC in your favorite language — folks familiar with IaC may have experience with other tools that use domain-specific languages or even markup languages like YAML or JSON, and oftentimes that works fine for getting started. But especially as we scale to modern cloud architectures, the cracks begin to show,” Duffy said.
How Does IaC Integrate with GitOps?
First, let’s describe what GitOps is, and how it serves to automate and simplify infrastructure deployments for CI/CD and across complex environments such as Kubernetes.
A precise and consensus-led description of GitOps has been released by OpenGitOps, a GitOps working group under the Cloud Native Computing Foundation’s App Delivery special interest group. It consists of a set of open source standards, best practices and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps. It describes GitOps principles as:
- Declarative: A system managed by GitOps must have its desired state expressed declaratively.
- Versioned and Immutable: Desired state is stored in a way that enforces immutability and versioning, and retains a complete version history.
- Pulled Automatically: Software agents automatically pull the desired state declarations from the source.
- Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.
“The goal is to improve the accessibility and manageability of cloud native deployments, simplify the complexities linked with Kubernetes and facilitate smoother operations,” said Alexis Richardson. “These improvements will be realized through ongoing efforts and advancements in GitOps, largely driven by the open source community and projects like Flux,” he said.
It could even be said that Infrastructure as Code is GitOps — or at the very least, it is an integral part of how GitOps works. On the developer side, whether it is merely using a pull request or, conceptually, putting applications on a repository through Flux or Argo, the developer team is using IaC commands to do that with templates or APIs.
The immutability part is where the IaC aspect comes into play for the operations folks who are updating and deploying the actual infrastructure when applications are rolled out, for example.
According to Richardson, as he explained, at the same time, you’re getting that automation as well, which is a key aspect of GitOps. A standard set of code templates is used to create, deploy, etc., applications as part of the GitOps realm for CI/CD. This is a part of the automation that reflects IaC. And, of course, this automation is happening simultaneously with GitOps.
Richardson said GitOps and IaC encompasses three different use cases: IaC, CI/CD (particularly CD), and platform engineering.
“These three elements converge to provide a cohesive approach to automating how you manage the entire stack: Best practice dictates using a combination of these tools to coordinate correct rollouts, manage pipelines, delivery, fleets and scale,” Richardson said. “As you scale up, you’ll find the need to employ new techniques to handle scale, since having 1,000 Git repos for 1,000 clusters is impractical. Ideally, you want one Git repo or, at most, just a handful.”