Multi-cloud drift detection on AWS, Azure and GCP
Driftctl is going multi-cloud and soon multi IAC
Announcing initial driftctl support for Azure and GCP
After focusing for a long time on AWS to understand precisely all the issues related to infrastructure drift and gathering solid proof of the value of the tool, we are thrilled to announce that driftctl is opening support for both Azure and GCP clouds in September. Driftctl is going multi-cloud and is on the road to becoming multi IaC as well. Indeed the foundational work to support CloudFormation (the AWS-specific infrastructure code) as an additional IaC language after Hashicorp’s Terraform has started.
Going multi-cloud: a demand from our community
Within our community, the battle to prioritize the next IaaS provider that driftctl should support has been raging for months. Right after its initial release back in December 2020, we already got the first GitHub issues from early users asking for Azure and GCP support.
Driftctl is open source and we listen a lot to feedback from our community to sort through our roadmap and decide on our next steps. GitHub discussions directly related to the product are a great help. As requests for additional cloud providers kept flowing we decided to open discussions dedicated to upvote those existing topics and thus keep track of demands and eventually decide on which one we should tackle first.
As this blog post is being written, GCP support requests are slightly ahead of Azure, but the podium keeps changing on a quasi-daily basis. As the amounts of requests for each of those IaaS providers were very close, we decided to go for both at the same time, allowing our users to catch drift outside of their infrastructure code from their preferred IaaS providers.
Moving forward after achieving the first stage of maturity and a steady increase in the volume of users
While our daily commitment to the project is such that we sometimes forget about the time spent working on it, driftctl is a young tool. The initial release of the CLI happened mid-December 2020, and we really started showing it around at the end of January 2021. During those 7 to 8 months, we were solely focused on making sure the tool was really useful for DevOps teams and working to the best quality level we could achieve. We were lucky enough to quickly have a lot of users when driftctl was only just released. Comments from those early adopters from the open-source community were incredibly helpful to build a better tool and we cannot be grateful enough for their trust throughout our journey.
Over time came tons of feedback from users and we are now pretty confident that driftctl solves a real issue for all teams interacting with and automating cloud-based infrastructures. Their input also confirmed our vision of how we should make the tool evolve in the near future.
Since last spring, we’ve seen a steep and steady increase in both the volume of users, the number of daily runs, and the variety of geographies where driftctl was run from. (Did you know that the tool was being run in close to 600 different places all over the world?) Bug reports have been also steadily decreasing along with requests for additional resources to support from the AWS cloud. Although we still have some tough nuts to crack like adding EKS support, we finally have reached an initial level of maturity and are confident enough that we can build upon it and expand the tool beyond the AWS cloud.
Call for contributions from the open-source community
This initial multi-cloud support is released with a first resource made available for each of the cloud providers recently added (Azure and GCP). A simple resource is not much, but we decided to go for the standard “release early, release often” OSS approach. We could have waited until we had a fairly significant amount of resources available before making this multi-cloud version public, but we preferred to go for an early release even if this means that we will probably be constantly shipping new versions at a quick pace in the coming weeks. Indeed, there is still some work to be done before the CLI reaches the same level of resources coverage on Azure and GCP as it has on AWS, and we will be working very hard in the coming weeks to cover the ground and add as many resources as possible to those new clouds.
The good news is that this tool is open source and you are more than welcome to make a contribution. If there is a specific resource that we do not support so far, and that you’d like to add, it is very easy to do so. We are calling out for contributions from the open-source community to continually add resources to the tool as needed, and thus make driftctl as comprehensive as possible.
Feel free to open a discussion, or add an issue on GitHub and propose to grab it yourself. You can also directly chat with the core team of maintainers on our community Discord. All engineering discussions are held live on the #dev channel which is open for all to join. There are many ways you can contribute to the project. Our community page will tell you more about it.
Multi-IaC is coming: soon adding CloudFormation support along with Terraform
Starting with Terraform support was an obvious choice for us. First of all, we are big fans of Hashicorp and heavy-duty users of Terraform in the team, so going for it first was a no-brainer.
But there are also a lot of CloudFormation users out there, and many of our users are using both CloudFormation and Terraform, depending on their environments, the teams related to them, and their own business constraints. Some of them even use generated CFN from another tool (like the Serverless Framework or Convox). This is why we have started foundational work to add AWS CloudFormation support along with Hashicorp’s Terraform. This is incredibly exciting to us as going multi-IaC is the next natural step for driftctl after achieving multi-cloud support.
Stay in touch
Get product updates and occasional news.