As cloud practitioners, we can't afford to bet on the wrong technology to manage our mission-critical infrastructure — especially when it’s so important for operations, so costly, and so heavily invested in. That’s a big part of why Terraform’s restrictive license change, and subsequent acquisition by IBM, has much of the DevOps community in a frenzy. 

Platform engineers, SREs and DevOps engineers alike find themselves puzzled by how best to navigate the evolving IaC tooling landscape they’re facing. And they’re even more unsure of how to future-proof their strategies against any changes they see (or may not see) coming. 

For me, the key is to proactively and decisively embrace, not fight against, the changing tides: like recognizing that multi-cloud strategies will continue to expand, or like looking beyond just infrastructure as code to adopt an “everything- as-code” mindset. 

The Disruptors Driving Change in the IaC Landscape

Many of today’s most skilled and capable cloud teams are still struggling to keep up with the constantly changing IaC landscape. But recently, a handful of disruptors have further shaken things up. 

Understanding them can be key to keeping up with, and even staying ahead of, trends and other change catalysts to come.

Terraform’s Surprise Switch Up 

Terraform is —or at least it definitely has been— the most loved infrastructure-as-code project, largely because it came with the promise of being an open-source solution to manage multi-cloud environments. When it launched, everyone loved it, the community contributed to it, everyone built on it, and it was a fantastic fix to a long-standing DevOps problem. Then everything changed, and quite unexpectedly.

HashiCorp’s decision to move from open source to a “source-available” license and acquisition by IBM follows a handful of shake ups that impacted the evolution of IaC thus far in big ways. Before that, Chef was acquired by Progress, and Puppet was purchased by Perforce. AWS largely replaced CloudFormation with Cloud Development Kit (CDK). And new entrants, like CrossPlane, OpenTofu, Pulumi, and OpenSearch, came into play (and are now making their moves to capture market share).

On the heels of all this change, many enterprises today are reevaluating their IaC and automation strategies, in search of smarter ways to reduce risk and adapt to the changing cloud landscape. 

Introducing OpenTofu (And The Battle of the Up-and-Coming IaC Tools)

A month after the license change, the DevOps community forked TerraForm and created OpenTofu, which they declared will be forever open-source, free, and unbound by commercial limitations. OpenTofu seemed poised to step in as the new heir to the infrastructure as code throne, with a dedicated solution for the multi-cloud era.

But the birth of OpenTofu also sparked a bunch of new questions.

• Frustrated by Terraform, will everyone immediately flock to OpenTofu? (In just one year, OpenTofu has captured about 4% of the market, according to Firefly’s 2024 State of Infrastructure as Code Report. But only time will tell where it goes from here.)
• Will this be the catalyst for an explosion in popularity among Pulumi and the CDKs? 
• Or is it time for the cloud-specific IaC solutions to take center stage again? 

I think it's safe to say that the latter two are probably not going to happen, because multi-cloud strategies are now the standard. But that doesn’t mean everyone’s getting it right.

Multi-Cloud Is The New Normal

Cloud practitioners aren’t just embracing the multi-cloud norm. They’re leaning into it, while simultaneously wanting more from their cloud tools in support of this new reality. 

Data from the 2024 Infrastructure as Code Report shows that:

• Today, 23% of teams have more than 100 cloud accounts across multiple providers, including AWS, GCP, Azure, etc. That’s twice as many as last year. And there’s a trend toward using multiple accounts to simplify environments for a project or department, but that often makes it more difficult to manage the entire organization’s cost, visibility, best practices, and policy enforcement.
  
• As many as 57% use 2 or more IaC frameworks (Terraform/Pulumi, etc.) This year, compared to last, use has shifted toward using five or six different IaCs: adding even more cloud complexity to the equation. 

Still, cloud practitioners want even more elasticity, and want to further expand their multi- cloud strategies. But not all solutions are equipped to make that a reality, or at least not easily and without incurring a ton of risk. 

The Rise of Everything-as-Code

Right now, the concept of “everything-as-code” is resonating among the DevOps community in a major way. Only 22% of teams report that they still aren’t managing SaaS apps infrastructure using IaC. The remaining majority either already do, or are actively planning to embrace everything-as-code. For reference, last year, almost 40% said they didn't see a reason to manage SaaS apps via IaC at all.

Everything-as-code is an extremely wide vision (that spans across monitoring as code, observability as code, security as code, and even paging through code). So, naturally, to achieve an everything-as-code reality, it’s not just about your cloud providers. You also have to think about tools like Datadog, Palo Alto Prisma, PagerDuty, Okta, etc. from an as-code mindset, and look beyond traditional infrastructure and explore ways to manage other aspects of your technology stack as code.

And for those with “everything-as-code” goals on the brain, the urgency to master infrastructure as code —and then run further with the tremendous potential of as-code— is particularly loud.

4 Tips for Future-Proofing Your IaC Strategy

Given the rapidly evolving IaC landscape, there are a few things organizations should consider when it comes to future-proofing their cloud strategies: the importance of multi-tool approaches, of staying informed on best practices and emerging tools, of prioritizing flexibility (and with that, tools that make migration and integration easy), and of investing in skills development and literacy around IaC. 

To do all this, you have to bring asset management concepts into the modern cloud era. And that’s exactly what Firefly is about. Because today, there is no other alternative but to adopt a multi-IaC strategy. We’re living in a multi-cloud, multi-IaC world, and even if you only use a single cloud provider, you'll probably have at least three different IaC frameworks. As time goes by, it's just going to get more and more fragmented. 

So how do you plan for it? How do you future-proof your IaC strategy when we’re in a complex present, facing an even more complex future? 

Here’s my recommendation for how to future-proof your IaC strategy, summed up into four tips.

1) Inventory your cloud

First, you need to understand where you're standing. You need to inventory your cloud, understand what's running there, and to know if you have shadow IT happening behind the scenes. Access the situation completely —and get visibility across all your IaC frameworks and cloud accounts. Then, act on an informed, complete view of what you’re dealing with.

2) Analyze your IaC coverage

After you inventory your cloud, you have to analyze your IaC coverage to understand how much of your cloud is managed or unmanaged. With Firefly, you can also see what’s being deployed with ClickOps, what resources may have drifted, or if you have any ghost resources (meaning a resource that you expected to see in the infrastructure as code, but it's missing from the cloud).

3) Enable a multi-IaC strategy

After you've completed steps one and two, you can enable your multi-IaC strategy (importantly, keeping in mind unified governance, standardization and migration). This will allow you to have the same high standards for everything, from TerraForm and OpenTofu to Helm and CloudFormation. 

You’ll need a unified governance engine, and you’ll probably want to enable yourself to migrate between different frameworks, or to take an environment that is governed and managed with one framework, and move it to another. A solution like Firefly lets you do it all, from one single solution, in a single pane.

4) Use a robust CI/CD system to manage your IaC

Finally, you’ll need to have a robust CI/CD system to manage your infrastructure as code, rather than having a dedicated CI/CD system for every infrastructure as code flavor that you have. 

Note: you only need one CI/CD, preferably your application CI/CD (like GitHub or GitLab or Azure DevOps), to manage everything related to your infrastructure. 

The Verdict? Long Live Terraform

If the question is “Is Terraform dead?,” my answer is: Terraform is here to stay. 

You just need to make sure you adopt it as part of a comprehensive multi-IaC strategy: one that takes into consideration multi-cloud visibility, IaC coverage, proactive governance, and the everything-as-code future we’re headed toward.

We all must remember that we need to make IaC work for us, rather than fit our ways of working around IaC as it stands. Because we know the IaC landscape will continue to change. As cloud practitioners, our goal is not to have the “best” IaC solution. Our goal is not to have zero drift. Our goal is to have a controlled, governed and efficient cloud, and to help our organization recognize IaC as an enabler that lets the business run faster, smarter, and safer.

🔗 For a deeper dive on all things IaC, watch The New Stack x Firefly’s on-demand webinar: Is Terraform Dead? Tips to Revive Your Infrastructure as Code Strategy.