This article is based on reporting originally published at searchitoperations.techtarget.com (2017). Tool versions and feature sets referenced reflect the state of the ecosystem at that time.
The Infrastructure-as-Code Landscape Was Evolving Fast
By mid-2017, IT operations teams were leaning heavily on infrastructure-as-code (IaC) tools to keep pace with the demands of DevOps. But the tools themselves were advancing almost as quickly as the applications they were meant to support — bringing both capability improvements and painful breaking changes.
Established players Chef and Puppet had recently restructured their products to support containers and the underlying infrastructure changes that came with them. Chef refactored its codebase into three major open-source projects and introduced Habitat, which many users were still trying to understand. Puppet published a roadmap for improved container support and was working toward a container management API. AWS CloudFormation, released in 2011, had been receiving roughly monthly feature updates in the preceding year.
Among newer entrants, Ansible — launched around 2012 and acquired by Red Hat in 2015 — had added network automation integrations and Red Hat CloudForms support for multicloud environments. HashiCorp Terraform, first released in 2014, had gained momentum quickly but had not yet reached a stable 1.0 release, leaving users to absorb breaking changes with each pre-1.0 update.
“It’s a rapidly evolving area, and a lot of companies are just getting into this space. Most of the people working with these tools are sys admins who are trying to figure out how to scale, rather than developers.”
Brandon Cipes, Managing Director of DevOps, cPrime
Most Teams Mix and Match IaC Tools
Few organizations relied on a single IaC tool. Most combined two or more, which added its own layer of complexity. A common pattern was to start with AWS CloudFormation — a natural first choice for companies building on AWS — and then layer in additional tools as infrastructure needs grew more complex or extended to other cloud providers.
CloudFormation’s verbosity and configuration demands were a recurring complaint. Its JSON (and later YAML) templates require precise parameter configuration, and a misconfigured template will often fail entirely rather than partially recover.
“It’s just not the most friendly tool in the world. It doesn’t use an easy-to-read language, it requires a lot of parameters to be set, and all of those parameters and details have to be very particularly configured or it will break.”
Brandon Cipes, cPrime
Despite its friction, CloudFormation couldn’t simply be abandoned. Its ubiquity within the AWS ecosystem meant teams had to remain fluent in it to collaborate effectively with the broader AWS community.
“CloudFormation is the lingua franca to exchange ideas about infrastructure and AWS resources. We definitely need to know the technology to be able to exchange ideas with the rest of the community because of its ubiquity.”
Joaquin Menchaca, DevOps Engineer, goBalto Inc.
Ansible’s Appeal — and Its Gaps
Ansible’s YAML-based approach made it attractive to teams that wanted their infrastructure definitions to sit naturally alongside application code. Its agentless architecture and low barrier to entry made it popular with sysadmins transitioning into DevOps roles.
However, some practitioners felt that Ansible’s investment in new areas — particularly network automation — was coming at the expense of progress elsewhere. Container support, for example, was seen as underdeveloped. Ansible Container, a project intended to give operators a familiar interface for container workflows, saw limited adoption in practice.
“Their efforts with Docker have been disappointing, as they focus more on Ansible Container projects. It begs the question, ‘Why not just use shell?'”
Joaquin Menchaca, goBalto Inc.
Terraform: Easier to Use, Harder to Upgrade
HashiCorp Terraform had built a following among DevOps teams who found its HCL (HashiCorp Configuration Language) significantly more readable than CloudFormation’s verbose JSON templates. Its cross-cloud provider model was another major draw: teams could manage AWS resources, Google Cloud infrastructure, monitoring services like Datadog, and more — all from a single, consistent configuration language.
“Terraform is a general language for working across clouds and various resources so that we can work with things like Datadog alerts, AWS resources or potentially spin up parts of Google’s cloud infrastructure, all from one place with one uniform configuration language.”
Calvin French-Owen, Co-founder, Segment
“CloudFormation makes you want to poke your eyes out, whereas Terraform is much simpler to understand.”
Calvin French-Owen, Segment
The trade-off was instability in pre-1.0 releases. HashiCorp’s 0.9 release, for example, significantly changed how remote state was stored and managed — a change that was necessary for teams sharing infrastructure, but required substantial rework to adopt.
“We have to reimplement a few things on our side as far as our workflow and re-educate ourselves to move our state as it is now to the 0.9 version.”
Dale Ragan, Senior Software Engineer, SAP Concur Technologies
Teams using Terraform Enterprise also reported bugs in remote state management, leading some to prefer self-managed state stored in Amazon S3 rather than relying on the managed offering.
“In some cases, we’ve found it’s not quite a first-class citizen compared to when we were managing state ourselves and putting it on S3.”
Calvin French-Owen, Segment
The Stateful vs. Stateless Debate
Terraform’s use of state files to track real-world infrastructure was one of its defining characteristics — and one of its most polarizing. Tools like Ansible, Chef, and Puppet had traditionally taken a stateless, declarative approach: describe the desired state of the system and let the tool reconcile the difference. Terraform broke from this convention by maintaining a state file that records what infrastructure exists.
Proponents argued that state tracking was genuinely useful: it let teams know exactly what resources existed, enabled remote state sharing across teams, and allowed infrastructure to be built incrementally on top of resources managed by others.
“Knowing about the resources you have is important, and state gives you that. Also, remote state is tracked to allow teams to build on top of infrastructure they may not control.”
Dale Ragan, SAP Concur Technologies
Critics were more cautious. A corrupted or out-of-sync state file could lead to destructive outcomes — including accidental deletion of infrastructure with a single command.
“Terraform is scary, because if the state is incorrect, you can destroy your entire organization’s infrastructure with a single command. Stateless has always been the preferred way to manage configuration, from CFEngine to Puppet, to Chef and to Ansible; Terraform broke away from this and tries to sell it as a feature.”
Joaquin Menchaca, goBalto Inc.
The mitigation, according to practitioners who had adopted Terraform at scale, was modularization. A well-structured, modular Terraform configuration limits the blast radius of any single operation — a monolithic configuration is far more vulnerable than one broken into composable, independently managed modules.
Where Terraform Fits — and Where It Doesn’t
The consensus among practitioners at the time was that Terraform was not a wholesale replacement for Chef, Puppet, or Ansible — it occupied a different part of the stack. Terraform excelled at provisioning and managing cloud infrastructure: spinning up VPCs, compute instances, DNS records, load balancers, and similar resources. Configuration management tasks — installing packages, managing services, applying OS-level configuration — remained the domain of Chef, Puppet, and Ansible.
“You could call Terraform a subset of Chef, Puppet and Ansible. It’s a tool people like to get infrastructure up quickly, cloud-agnostically, without having to build out all the other stuff those other products necessitate.”
Brandon Cipes, cPrime
In practice, many teams used Terraform to provision infrastructure and then handed off to Ansible or Chef for configuration management — combining the strengths of each tool while accepting the overhead of maintaining expertise across multiple systems.
Key Takeaways for IaC Practitioners
- No single tool does everything. Most mature DevOps shops combine IaC tools, using each where it fits best. Plan for multi-tool complexity from the start.
- CloudFormation’s ubiquity matters. Even if your team prefers other tools, understanding CloudFormation remains important for communicating infrastructure intent within the AWS ecosystem.
- Ansible is approachable, but watch the gaps. Its YAML syntax integrates well with application code, but container support and specific integration areas may lag.
- Terraform’s pre-1.0 releases carry real risk. Breaking changes between minor releases require disciplined upgrade processes and thorough testing before applying to production state.
- Modularize Terraform configurations early. Monolithic configurations amplify the risk of state-related failures. Decompose infrastructure into small, independently managed modules.
- State management is a first-order concern. Whether you store Terraform state in S3, Terraform Cloud, or another backend, ensure it is versioned, locked, and backed up before operating at scale.