Infrastructure drift, particularly in Infrastructure as Code (IaC) or cloud environments, typically refers to the deviation between a system's actual state and its intended or defined state over time. This can arise due to manual changes, updates, unrecorded actions, or non-integrated changes outside of the IaC system.

Take for example an organization using a tool like Terraform or CloudFormation to define and manage its infrastructure. If an engineer manually alters a security group setting, a database configuration, or other aspects of the infrastructure through the AWS console (or other cloud service provider) without updating the IaC definitions, a drift occurs.

In other words, the actual infrastructure configuration has "drifted" from the code-defined configuration. Such drift is generally undesirable as it compromises reproducibility and complicates infrastructure troubleshooting and maintenance. This is where Continuous Integration (CI) can minimize risks.

CI is a development practice where developers frequently integrate code into a shared repository, meaning the infrastructure cannot drift far from the repository's definition. But the question remains: how do we keep our IaC updated?

Instead of retroactively monitoring and adjusting, the optimal solution is early intervention. By automating the process of understanding the required infrastructure for our code and pairing it with CI, drift can be drastically minimized.

Automatic infrastructure inference involves a system that can automatically understand the current configuration and state of your infrastructure directly from your application code. When paired with CI, it significantly reduces or even eliminates infrastructure drift.

I've previously described how this works with the Nitric framework in one of my past posts.

When drift does occur, so does toil - on both your ops and your devs to dive into specific app and infra code to determine where the issues are - this isn't great because it often requires your best troubleshooters to burn time.

In a well-designed CI/CD pipeline, every infrastructure change should be code-defined, committed to a version control system, and applied via the pipeline. Therefore, the desired state of the infrastructure is always represented by the latest version of the code in the repository.