DevOps teams have a pretty wide variety of Infrastructure as Code tools at hand. The range goes from so-called “configuration management tools”, such as Ansible, Chef, Puppet… mainly used to install and manage software on existing servers, to “provisioning tools” designed to spin up resources themselves like Terraform or Pulumi, not to mention cloud providers proprietary tools like AWS CloudFormation, ARM for Azure, or Google Cloud Deployment Manager.
If you add to that dev tools like AWS CDK, Terraform CDK, the serverless framework or even tools like Kubernetes that will spin up bits of infrastructure themselves, the possibilities and combinations are almost endless.
Building driftctl, a fully open-source tool that catches drift outside of infrastructure code, we have often come across use cases where users would have multiple IaC tools on the same infrastructure (mainly CloudFormation + Terraform as we only support AWS at this stage). This community feedback led us to a question: is this a common setup that has to be supported in our open source solution? So we decided to create a poll.
The question we asked was a simple one:
Looking at your IaC setup (or your customer’s), would you say that you use:
After posting this poll, we immediately got reactions on the question by itself : people would come up with comments and reactions on the first results because we did not mention all solutions at hand. Typically, the combination of configuration management tools and provisioning tools is still a classic:
We asked this question on several channels, like various Slacks dedicated to DevOps topics, LinkedIn, our Twitter account, and our community Discord server where our users discuss everything related to infrastructure drift. The very first thing we noticed was the fact that we gathered close to 350 responses within a couple of days, with results quite consistent across all channels. The topic is an interesting one and practitioners are eager to discuss it.
A single IaC tool
62% of respondents declare using a single IaC tool: a common setup that we expected to emerge as the main one.
As we wanted people to answer the poll in under a minute, we kept it short and simple, and have no indication as to what tool emerges the most. Some people did give us a hint on their preferences, though…
While the number of answers collected comforts us thinking the poll was representative of reality, we are still wondering if there was a slight bias in this answer being more wishful thinking than a reality.
Multiple IaC tools on purpose for different resources/use cases
32% declare using multiple IaC tools on purpose for different resources/use cases. We’ll come back in detail on the reasons why teams embrace a variety of IaC tools, but it is already interesting to note here that for a significant number of organizations the hegemony of one single tool is not a goal to reach for.
Several tools today but planning to migrate to a single tool
6% of respondents declare using multiple tools today but planning to migrate to a single tool at some point. The reasons for that are various and can be directly related to the performances of the tools themselves and/or the skills of the team using them.
The question is legit. There are several reasons why you would think that the usage of a single IaC tool is more convenient: one single standard for the whole team makes it easier to manage and track. Consequently, it makes your infrastructure simpler to check for compliance and security. There are also probably gains to be had on the training of the team, etc…
The funny thing about short polls is that they frustrate passionate people. They’d like to say more but the closed questions of the poll won’t let them. Some comments gave us very useful insights on why they use multiple Infrastructure as Code tools. Here are some quotes that we can probably categorize as patterns:
Many teams have a preferred tool for their core infrastructure, and are open to other tools for applications and non-core items:
This pattern also exists when 3rd party tools rely on a specific IaC language.
Organizations also have to take into account the skill level of their teams and their ability to use one tool or another:
And obviously, there is the special case of Kubernetes and the several ways it interacts with our infrastructures :
Reflecting on those elements, we see that teams often use different Infrastructure as Code tools for different usage, and there is no reason for this to change. In this context, CloudFormation support is an obvious priority to bring our first users the best possible experience on their AWS infrastructures.
A natural next step after this one would probably be to focus on a prototype of driftctl supporting multiple layers of Terraform states, CloudFormation and shared, dynamic and static resources from Kubernetes.
Get product updates and occasional news.