You have 1 article left to read this month before you need to register a free LeadDev.com account.
In the late ’00s, Infrastructure as Code (IaC) promised to transform how developers thought about infrastructure in the cloud age.
Instead of individual servers that needed to be hand-tuned, organizations would define the infrastructure they wanted in (mostly) human-readable YAML or JSON files, and provisioning tools would automatically configure the real infrastructure with that ideal state.
As an added bonus, these IaC configuration files could be created and maintained in code repositories just like application code and managed by DevOps teams, aligning the work of developers and operations into a single unified philosophy.
While many people are reaping those benefits, things haven’t exactly gone to plan. A 2024 survey commissioned by StackGen and conducted by Dimension Research found widespread ambivalence and even dissatisfaction with how IaC has played out in practice. A massive 97% percent of survey respondents said their organization experienced difficulties working with IaC, and 87% thought their organization wasn’t “mature” in its IaC rollout.
Where has IaC fallen short, and where do we go from here?
Flexibility issues
“IaC shines when it comes to integrating into the DevOps process and using code repositories to keep track of changes and make sure they are consistent,” said Arvind Rongala, CEO of tech education firm Edstellar.
After all, if your infrastructure is defined in code, then your code management tools also become your infrastructure management tools: this is IaC’s big promise. But that promise begins to crumble as velocity increases. “The problem usually comes up in cloud settings that are very dynamic and need to make changes quickly and often. IaC works best for structured, predictable workflows, but its rigidity can slow teams down at times, especially when they need to make changes to the configuration right away but the repository lifecycle is still catching up.”
Joey D’Antoni, principal cloud architect at the consulting firm DesignMind, has seen this first hand in his work with clients. He sees the issue become particularly acute when staffing isn’t adequate for the administrative work and the separation of duties necessary to do IaC and DevOps the right way.
“We had a client who wanted to resize something, and in order to do that somebody had to check out a Terraform file from source control, make a change to the file, and commit it,” he says. “It was a major hold up to do a resize on a cloud resource that was under pressure, and somebody really could’ve just gone into AWS, clicked something, and adjusted the code later.”
“It’s not trivial to consider the level of effort [required],” he adds. “It really depends on the number of things you’re deploying, and then the frequency that you’re deploying them.”
Troubling workarounds
That level of effort may not be the first priority of a fast-moving organization. Asif Awan is cofounder and CPO at StackGen, the infrastructure-from-code company (more on that in a moment) that commissioned the Dimension Research report.
A rapidly growing startup may have an overriding focus on deploying their application, with few standard processes or reusable templates. This can lead to code drift, conflict among workers, and overall chaos.
“These are the kinds of things that are happening, because developers want the flexibility,” Awan says. IaC certainly isn’t the only philosophical approach to run into this issue, but it can be a particularly pernicious one.
Developers may end up downloading templates from Stack Overflow or turning to unsanctioned generative AI tools and, without proper infrastructure expertise, they may deploy something without fully understanding or adequately testing it. “Each developer or team ends up maintaining their own local templates that they have downloaded and tinkered with,” Awan says.
Crossing domains
Essentially, IaC puts configuration code into the hands of developers who often aren’t experts in configuration. In theory, IaC was supposed to break down those professional distinctions, and that might be true at megacorps like Google who hire SREs with experience in both worlds.
But for most companies you end up with people working outside their domain expertise, especially when it comes to networking or security, which are key to infrastructure configuration. This has real-world impacts on performance and morale: the Dimension Research report found that 75% of surveyed infrastructure professionals found it frustrating when other teams make configuration changes.
By asking the infrastructure side to align with developer workflows and processes, “you’re putting software development into the hands of people who really don’t do software development,” D’Antoni says. “Getting them on board with those policies and practices and doing them in a good, secure manner is always a little bit of a challenge. You can see it if you look at job postings for cloud engineers. They all like mentioning Terraform or Bicep or various other solutions for IaC.”
Dimension Research found that more than half of developer respondents spend more than 20% of their time on infrastructure management. It’s a recipe for the widespread frustration and perceived lack of expertise reflected in the report.
In practice, IaC is often the responsibility of several different teams, shared among DevOps, cloud operations, or security, with around two-thirds of respondents saying that two more teams have their hand in it. Despite having many parents within an organization, the cross-domain expertise needed to do IaC right means that it often ends up an orphan.
The struggle to keep up is real
If these internal factors aren’t enough, consider the fact that IaC for cloud deployment must rely on multiple vendors or open source projects to integrate with one another. The big cloud providers do provide their own infrastructure management tools, but many customers are wary of vendor lock-in and not in love with the offered features. Instead, they rely on platform-neutral vendors, with HashiCorp’s Terraform, the market segment’s 800-pound gorilla. Their offering was originally open source, but that’s become mired in controversy after HashiCorp shifted the licensing terms, and the company is in the midst of a potentially rocky merger with IBM.
At any rate, dealing with a third-party tool to access your cloud provider has its own difficulties. “It’s hard to keep up with the pace of cloud providers’ future development,” D’Antoni says.
Some shops try to cope with these issues by using multiple IaC tools—54% of those surveyed by Dimension Research are doing so. Awan says that this is motivated by the “hope that something new is going to address that problem. But they’re not actually getting down to the root cause of the problem, which is that we need to let people who are good at doing things do what they are good at doing.”
What can help?
Now folks are looking to generative AI to solve their problems. “I think even GitHub Copilot can do a pretty good job of scripting Terraform for you,” D’Antoni said.
Edstellar’s Rongala thinks AI can also be used in a more formal context. There, project managers can choose preset templates or configurations for typical deployment situations, and the required IaC scripts are generated in the background. “We included AI-driven suggestions into the user interface,” Rongala adds. “Based on past data, these recommendations alert engineers to problems like resource conflicts or security flaws.” Crucially, the system has safeguards to guarantee that deployments follow security guidelines and company regulations, even for non-technical users.
“We’ve seen teams try out AI-enhanced tools that were built on top of Terraform or CloudFormation to make iterations go faster,” he says. “These tools don’t replace IaC but enhance its usability for diverse teams, including those without deep coding expertise.”
But Awan is more hesitant. While generative AI can plug holes, they don’t address the core problems IaC is facing. “If any of these generative AI or LLM-based tools were to spit out IaC code that was 100% reliable, and nobody had to review it, the problems that we’ve been talking about would be solved,” he says.
But a developer grappling with, say, unfamiliar network configuration issues, would not be able to properly evaluate the LLM-generated code. “So I’m going to tap on the shoulder of someone who’s a DevOps engineer, but they already have 10 or 20 different things they’re working on, so they have to create a ticket – and we are back to square one.”
The next generation
Now there are a generation of tools looking to supplement, or even supplant existing IaC tools.
System Initiative, for instance, provides a UI-based platform to make designing infrastructure easier. Users get a visual overview of their infrastructure that they can rearrange and test on the fly. The company was cofounded by Adam Jacob, the former CTO of IaC vendor Chef. Having worked in this space since its inception, Jacob is well placed to argue that not just IaC, but the whole DevOps approach it’s designed to integrate with, has failed to live up to its potential.
Awan’s own StackGen takes a different approach, which they call “Infrastructure from code”. A static code analysis automatically generates an infrastructure plan from the application code itself; there’s visual presentation that developers can easily grasp, but under the hood it generates the typical IaC config files and other artifacts that platform teams can manage as needed, either through the tool or via their own traditional methods. It dovetails with the company’s philosophy of letting people do what they’re good at. Then there’s Pulumi, which has committed to adding generative AI as an integral part of its IaC toolkit, although the results have been somewhat mixed.
D’Antoni makes a somewhat more radical proposal: for smaller organizations, IaC may simply not be necessary.
“If you’re deploying just 20 or 30 resources, it’s cool if you want to do that as code – there are some benefits – but you don’t have to,” he says D’Antoni. Instead, he advocates for ClickOps, an approach that starts with clicking through the default GUIs supplied by your cloud provider. In the end, a noble philosophy isn’t always worth the toil.
