While we all probably think we're doing all the DevOps stuff the right way (and we do, don't we?), drift happens.
Even as an experienced Terraform user, as your infrastructure team and codebase grows, it often becomes harder to track drift.
I'll share here war stories from different teams, and show common pitfalls of popular commands we use when we want to know what's changed in our infrastructures.
While we all probably think we're doing all the DevOps stuff the right way (and we do, don't we?), drift happens.
Even as an experienced Terraform user, as your infrastructure team and codebase grows, it often becomes harder to track drift.
I'll share here war stories from different teams, and show common pitfalls of popular commands we use when we want to know what's changed in our infrastructures.
There are a lot of juicy stories from the trenches to be told on infrastructure drift.
Sure enough, we all do GitOps by the book! Or we all have the right processes in place. But we also have to interact with other teams. We also have to grant some level of access to our infrastructures to some services or tools that may eventually generate uncontrolled changes. What if we couldn't catch them all? What if all drift reporting so far was faulty?
You can't efficiently improve what you don't track. We track coverage for unit tests, why not infrastructure as code coverage? How can we make sure our infrastructure code matches our actual infrastructure state? In this talk, using Terraform with AWS resources, I will show how infrastructure drift can go undetected despite our best efforts or tooling and cause issues and end the talk by showing our own tool driftctl, (just released under Apache-2.0 licence) that tracks IaC coverage and warns of infrastructure drift.