If you’re a DevOps engineer, you know that the only constant you can count on is change. 

From Chef and Puppet, to Ansible, and then CloudFormation and Terraform, your configuration management tools have evolved rapidly over the past decade, and that shows no signs of stopping. Now, with Terraform's more restrictive license changes and new players entering the field, it’s time to reassess your Infrastructure as Code (IaC) strategies. 

You may be asking:

• Is Terraform dead?
• Will OpenTofu be the new king of IaC?
• If I continue to use Terraform-based IaC tools, do I run the risk of breaking my CI/CD pipeline?
• What else is at risk, and what should I do next?

Many cloud practitioners today remain unsettled by all the uncertainty. But uncertainty about the future of IaC tools shouldn’t hold you back, at least not if you’re equipped with knowledge on where the evolution of IaC started and is headed, what trends stand to drive more change, and how to start embracing the “everything-as-code” movement on the horizon.

I recently hosted a webinar alongside Chris Pirillo of The New Stack addressing all these questions, and sharing my two cents on how DevOps leaders should be thinking about their IaC strategies, now and tomorrow. Here’s an overview of what you need to know to make smart choices in the face of constant change. 

What’s All the Terraform Fuss About?

In August 2023, HashiCorp, the company behind Terraform, made a significant and controversial change to its licensing model: moving from an open source license to a less permissive "source available" license. The license change raised concerns about the future of Terraform and its ecosystem; in response, the community forked Terraform, creating OpenTofu, an open source alternative.

Now the IaC tooling landscape is in a state of flux, and cloud practitioners are looking for guidance planning their next move. Still, Terraform is still (by far) the most dominant IaC, and moving between IaC frameworks is challenging. 

According to Firefly’s 2024 State of Infrastructure as Code Report: 

• Terraform remains the dominant IaC tool, managing nearly 64% of cloud deployments.
• The DevOps community is exploring alternatives, with interest growing in tools like OpenTofu, Pulumi and Crossplane.
• There's a trend towards using multiple IaC tools within organizations, with projections showing an increase in the number of tools used per company.
  

To figure out how best to move forward with so much to keep in mind, it’s important to first take a look back, and then look ahead toward potential future challenges. 

So, let’s look at the evolution of IaC so far — and where it’s going.

How Is IaC Evolving — And Where Is it Headed?

Infrastructure as Code has come a long way since its inception, evolving through several distinct phases before arriving at its current evolution: a rapidly maturing ecosystem embracing futuristic frameworks for advanced IaC and an everything-as-code mentality.

From Manual Scripting to the Configuration Management Era 

In the early days of IaC, once we moved on from manual scripting, we ushered in the configuration management era. It all started with tools like Puppet and Chef — and later Ansible. This era provided an advancement, or modern day realization of, scripts by enabling automated server configuration and provisioning. 

Gone were the days of writing basket or Python scripts to replace manually configuring a new machine on our VMware or ESX hypervisor. Puppet, Chef and others came along and gave us a way to do it automatically. It worked like magic, DevOps teams loved it, and it saved so much time and effort, which helped us work in the virtual machines space at scale.

Ansible then took it to the next stage, making everything much simpler — not just configuring the actual machine, but also provisioning the machine infrastructure.

Enter: Cloud-Specific Infrastructure as Code Frameworks

As the space matured, we saw the first cloud-specific Infrastructure as Code  frameworks crop up. Cloud computing gained prominence, and different providers introduced their own IaC solutions. These allowed users to define and manage cloud resources specific to each provider. 

First came AWS Cloud Formation, which allowed us, for the first time, to write actual Infrastructure as Code — not just configuration management scripts. That meant that as a cloud practitioner, you could write up code and know it will work at scale, such as if you wanted to spin up a new instance, to connect to a security group with specific identity and access management (IAM) permissions with policies and users, and to then connect to an API gateway. 

After AWS CloudFormation came Azure Resource Management (ARM), which later evolved into Bicep, followed by Google Cloud Deployment Manager. 

At the time, cloud practitioners were extremely excited about the ability to not just configure VMs and instances, but also actually code their infrastructure. Over time, teams brought more and more of their business and application logic into the infrastructure, which required that they code even more of that infrastructure. 

Momentum was building, and everyone recognized more evolution was coming. It was clear that just because cloud computing providers were offering their own IaC frameworks, it didn’t mean they were necessarily the best option — and practitioners worried about being locked into working with one provider. 

Then came the explosion of multicloud popularity, and everything changed again.  

The Age of Declarative Multicloud Solutions

Roughly 12 or 13 years ago, we saw what I would call a step function in cloud operations. With the advent of Terraform, we welcomed the first declarative multicloud IaC language. It allowed us to think about our cloud more broadly, because as practitioners, we thought, “I'm not locked into AWS. I'm provisioning my infrastructure on Azure and on Google Cloud Platform, on AWS, and any other clouds I want: all in the same manner with the same tooling.” Terraform emerged as a game-changer, offering a declarative, multicloud IaC solution beloved for its ability to manage resources across various cloud providers using just one tool.

Unsurprisingly, Terraform exploded in popularity. But at the time, Terraform was purely declarative. And while DevOps teams recognized that Infrastructure as Code was great, they needed to guarantee their code was also immutable (so they’d always have the same module running across development, staging and production environments). After a few years, Terraform closed this gap and now has native Terraform modules. 

But this era of IaC spurred even faster evolution of the space, nudging it forward and catalyzing the inception of tools like Pulumi.

Introducing Programming Language-Based IaC 

The next evolution of IaC brought tools like Pulumi to the community, which allowed developers to write IaC — not in a declarative language, but rather using familiar programming languages such as Python or Node.js. That’s when we were introduced to programming language-based Infrastructure as Code. 

And this shift had a wider impact than just contributing to the continued evolution of IaC. 

For example, If I was a full-stack developer, writing everything from frontend to backend in Node.js and JavaScript, I could now use Pulumi to write my IaC parts in any programming language I prefer. So, Pulumi and programming language-based IaC offered a solution that was more robust and very appealing to more people in the organization, not just DevOps and platform engineers or cloud practitioners. Later came Cloud Development Kits (CDK) from AWS  and other cloud providers. 

Today, it's pretty common that every IaC has a CDK, but it all started with this crucial era. And then Kubernetes (K8s) fever rocked the IaC landscape again.

The K8s-Based Era

With the rise of Kubernetes, solutions like Crossplane emerged, enabling infrastructure provisioning through the Kubernetes API. The DevOps community thought, “Okay, Kubernetes is now extremely popular, so let's use it to provision everything that we want to have in our cloud, so it can all correspond and talk to our Kubernetes cluster.” This meant we now had a way to describe our cloud through the Kubernetes API and that could spin up (and down) resources in the cloud. 

Next came a new stage of maturity in the IaC space. 

Experimentation, Advanced IaC and Everything-as-Code

Everything we’ve seen before has become relatively mature, but the ecosystem continues to change. Some extremely futuristic frameworks (like Wing) suggest you need to merge your application logic and infrastructure logic, and all eyes are on OpenTofu as the shiny new toy driving interest in experimenting with IaC tools. 

Looking back at the last decade and a half of Infrastructure as Code’s growth, we’ve seen advancement from configuration management to more widely adopted, multicloud, and application-aware advanced Infrastructure as Code. 

Next, I expect to see cloud practitioners expanding their horizons beyond traditional infrastructure and exploring more ways to manage other aspects of their technology stack as code (think: security, operations, observability) — moving us toward a fundamental mindset shift where we recognize that everything can be managed as code. 

Managing Infrastructure Will Get Even More Complex

While Terraform's licensing change has sparked discussions about its future, it remains a dominant force in the industry. Still, the rise of alternatives like OpenTofu and the trend towards using multiple IaC tools suggest there’s an even more diverse and complex future for infrastructure management on its way. But each practitioner has their own choice of tools or combination of tools, and it’s too soon to say if OpenTofu will reign supreme any time soon.

Fortunately, organizations that stay adaptable and embrace change will be best positioned to leverage the full potential of IaC — and even eventually, everything-as-code in their cloud computing strategies.

To explore my actionable tips for future-proofing your IaC strategy in the wake of so much constantly shifting, watch the webinar recording in full.