Why CI/CD Alone Won’t Cut It for Infrastructure as Code
Let’s be honest, Infrastructure as Code (IaC) was supposed to make everything easier.
And for a while after you start using it, that’s what happens. The first time you swap manual provisioning for Terraform or Ansible, it feels like magic. No more clicking through cloud dashboards. No more “who made this change?” mysteries. Everything is version-controlled, repeatable, and, in theory, collaborative.
But at some point, the honeymoon ends.
Your infrastructure scales, your team grows, and suddenly, that neatly organized IaC repo turns into a sprawling, interconnected mess. Engineers start stepping on each other’s toes. A single typo in a shared module can take down production (don’t ask me how I know). Your DevOps team becomes a bottleneck instead of an enabler.
And here’s the kicker: this isn’t just your team’s problem.
In a recent survey commissioned by Spacelift, 45% of organizations believe they have a high level of infrastructure automation, but only 14% do. There’s a huge gap between perception and reality. Companies think they’re operating at a mature level, but in practice, they’re still running into the same pitfalls: inconsistency, governance struggles, and the classic tradeoff between speed and control.
So, how do you know where you stand? And more importantly, how do you level up?
The 4 Stages of IaC Maturity
Infrastructure automation isn’t binary — it’s a spectrum. Some teams are just starting, while others have built robust, self-service platforms with guardrails and automation-first workflows.
To map this out, we used the survey results to build an Infrastructure Automation Leadership Index. It breaks maturity into four stages:
- Experimenter – You’re testing the waters. Some automation, lots of manual workflows.
- Adopter – You’ve committed to IaC, but standardization is a challenge.
- Optimizer – You’ve streamlined deployments, but gaps remain in security, compliance, and scalability.
- Leader – Infrastructure is fully automated, self-service is the norm, and security is built-in.
Most organizations fall somewhere between Adopter and Optimizer. They’ve seen the value of IaC, but they’re struggling to scale it.
And this is where IaC orchestration comes into play.
When Does IaC Orchestration Make Sense?
IaC orchestration isn’t for teams just experimenting with automation. If you’re still figuring out Terraform basics, you don’t need orchestration yet.
But once you’re in Adopter territory, you start seeing patterns: Some good — hey, we can spin up entire environments in minutes! Some not-so-good — why does every team have a slightly different way of provisioning infrastructure?
At this stage, teams often misapply DevOps best practices to IaC. They treat infrastructure like application code, running it through general-purpose CI/CD pipelines. And for small-scale deployments, this might work.
But as complexity grows, you hit a wall.
IaC is not like application code.
Application deployments are stateless — today’s build doesn’t care about last week’s. Infrastructure is stateful. Your Terraform config today includes the database you created last year, the DNS entries from last month, and the load balancer from last week.
That’s why treating IaC like app code fails. It’s why infrastructure requires dedicated orchestration, just like databases have schema migration tools.
So if you’re an Adopter trying to become an Optimizer, orchestration will give you the most significant boost. And if you’re aiming for Leader status, it’s a must-have.
Two Big Misconceptions About IaC Orchestration
I’ve had a lot of conversations with DevOps leaders who hesitate on orchestration. Usually, they bring up one of two concerns:
1. ‘Can’t we just use our existing CI/CD tools?’
I get it — why add another tool when you already have Jenkins, GitHub Actions, or whatever your team prefers?
But here’s the thing: CI/CD pipelines weren’t designed for infrastructure. They’re optimized for quick, stateless deployments — not for managing dependencies across thousands of interwoven cloud resources.
Teams try to brute-force through this by bolting on custom scripts and workarounds. But eventually, they run into race conditions, drift, or — worst case — accidentally take down a live production database.
The reality is that once you reach a certain scale, you need an orchestration layer built for infrastructure, not application code.
2. ‘Won’t this create lock-in?’
No one wants to be trapped in a proprietary ecosystem. That’s why the best IaC orchestration solutions use open standards—storing Terraform state externally, using Docker for execution environments, and leveraging Open Policy Agent for governance.
Lock-in happens when you build a fragile, in-house solution that only your team understands. Good orchestration reduces lock-in by standardizing workflows, not boxing you into a specific vendor.
Avoiding the Common IaC Traps
Even with orchestration, DevOps teams fall into two common pitfalls.
1. The ‘IaC Monolith’ Problem
Some teams consolidate all their infrastructure into a single massive project. That sounds efficient, right? One place to manage everything?
Wrong.
Monoliths become impossible to manage at scale. They take forever to sync, get throttled by cloud APIs, and eventually crash. A common example is a Terraform monolith, also known as a Terralith: it sounds like a good idea at the start, but it becomes complicated and troublesome as your infrastructure grows.
But the opposite extreme — breaking everything into tiny, fragmented IaC projects — is just as bad. It adds too much overhead and makes dependency management a nightmare.
The key is finding the right level of modularization for your team’s needs.
2. Overly Prescriptive vs. Wild West
If you’re rolling out self-service infrastructure, you need guardrails. But too many restrictions frustrate developers, forcing them to constantly ask DevOps for special exceptions.
On the other hand, too much freedom leads to chaos. Teams deploy infrastructure in entirely different ways, security vulnerabilities creep in, and costs spiral out of control.
The sweet spot? Provide open-ended building blocks with built-in policies for security and cost control.
How To Move Up the IaC Maturity Curve
So, where do you go from here? Consider these steps to make forward progress:
- Assess your current stage. Are you an Adopter struggling with standardization? An Optimizer working through governance challenges? Be honest about where you are.
- Identify your roadblocks. Are you dealing with infrastructure bottlenecks, compliance headaches, or constant rework? Prioritize what’s slowing you down.
- Adopt a gradual approach. Don’t try to build the perfect IaC setup from day one. Start small, iterate, and adjust as you go.
- Invest in orchestration when you’re ready. If you’re hitting scaling challenges, now’s the time to move beyond basic automation.
At the Leader stage, automation isn’t just about speed — it’s about control, security, and developer enablement. That’s where the real ROI comes in.
Final Thought: The ‘Speed-Control Paradox’
One of the most interesting findings from our survey was what we call the Speed-Control Paradox.
Teams early in their IaC journey focus on speed — deploying infrastructure faster. But as they mature, they realize the real challenge is control — governance, compliance and security.
The best teams — the Leaders — balance both. They build fast, but with governance built into every process. They enable developers while keeping security and compliance in check.
And at the end of the day, that’s the goal.
