If you have been responsible for creating and maintaining application infrastructure and configuration in the past, you have most likely experienced what is called configuration drift. Configuration drift is the name for the phenomenon where the configuration between servers in acceptance and the production environment differs. Or, even worse, when having multiple servers in the production environment, it might be the case that the configuration of these is not always the same.

The most common cause of configuration drift is manual change. When making changes manually, maybe under the pressure of a production issue, there is always the risk that you apply different settings to different servers or hosts. And if you ever need to scale out and add another server to your production environment, the chance of that server taking on the same configuration of all already existing servers is very slim.

With Infrastructure as Code (IaC) and Configuration as Code (CaC), you no longer make changes to application configuration and infrastructure by hand, but only through automation. The first step to do this is specifying the desired state of configuration and infrastructure. The desired state is then fed into configuration management tooling that enforces this configuration on your infrastructure. Specifying only the desired state is called a declarative approach, which differs from an imperative approach, where you specify all of the steps that need to be taken.

These tools are often also capable of checking the current state of your infrastructure and configuration on a regular interval and reapplying your desired state if any deviation is detected. This is possible due to the declarative approach. This makes applying configuration an idempotent operation. An operation is idempotent if it can be repeated one or more times, while the outcome will remain the same.

When adopting IaC and CaC, you can even go so far as to recreate the complete infrastructure before deploying an application, deploy the application on that new infrastructure, and then disregard the old infrastructure after switching to the new deployment. This is an extreme form of immutable servers. The added benefit of this approach is that you are now guaranteed that there will be no traces from any configuration or binaries from the previous deployment.

In the following sections, you will learn about different IaC technologies and how to use them. It is important to understand that they are complementary and are often used together. For example, ARM templates can be used to create virtual machines in Azure and, once that is done, PowerShell DSC or Ansible can be used to configure those virtual machines.