Hello and welcome to an intro to infrastructure as code. In this lesson we are going to take a look at what infrastructure as code means and what it offers.

So, what exactly is infrastructure as code? In a nutshell, infrastructure as code is the practice of deploying and managing infrastructure, such as networks, VM’s, and other resources in a descriptive model. This is done through the use of versioning, which is not unlike the versioning that DevOps teams use for source code.

In much the same way that a specific set of source code produces the same outcome within an application, whenever the source code is run in an infrastructure as code model, that code will produce the same environment every time it is applied. Because infrastructure as code mitigates environment drift in the release pipeline, it is a key DevOps practice that is typically used in conjunction with continuous delivery.

Infrastructure as code eliminates the need to manually maintain deployment environment settings, which, by the way, usually results in snowflake environments. Snowflake environments are individual environments that each require a unique configuration that is difficult or even impossible to be reproduced automatically. The inconsistencies that arise as a result of snowflake environments will often cause issues during deployments. These snowflake environments also create administration and maintenance headaches because each infrastructure requires manual processes that are not only difficult to track, but also result in errors. Infrastructure as code solves these problems.

A key principle of infrastructure as code is Idempotence, which refers to the concept that a specific deployment command will always set up the target environment in the same configuration, regardless of the starting state. In other words, Idempotence is the ability to run a specific process or command that produces the same exact result each time. You can achieve idempotency in a couple different ways. You can achieve it by automatically configuring an existing target or you can achieve it by discarding the existing target and creating a fresh environment to start from.

Idempotence is important when trying to create consistently configured environments. To achieve this, the DevOps team makes changes to the environment description and version of the configuration model. The configuration model typically exists in a JSON file. The configuration model is executed by the release pipeline, which in turn, configures the target environment. This means that if a change to the target environment is needed, the DevOps team actually makes the change to the source, which is then rerun to produce the changes on the target end.

DevOps teams will often use infrastructure as code early in the development cycle to produce environments that mirror production. These environments are then used to test applications.

Leveraging infrastructure as code rather than deploying environments manually allows teams to provision multiple test environments on an as-needed basis. Infrastructure as code also allows for rapid and scalable deployment delivery. Infrastructures that are deployed using infrastructure as code are easily repeatable and do not suffer from many of the runtime issues or configuration drift that manually deployed infrastructures suffer from.

The too long didn’t read version of infrastructure as code is pretty simple. It is used to deploy consistently configured infrastructure.