What is Infrastructure as Code?

Infrastructure as code(IaC)

What is Infrastructure as code?
TL;DR,

1. Infrastructure as code describes the infrastructure in executable text format.
2. The short-lived infrastructure can be used and then discarded. Servers are built on demand, through automation.
3. Rather than patching a running container, immutable delivery modifies the container image and then redeploys a new container.

Infrastructure-as-code is the practice of describing infrastructure in text format. This is not about documentation, I'm talking about an executable text format, which is also called code. You want to be able to configure your infrastructure in a textual description that you can give to a tool to execute.

Configuration Management Systems

So, the configuration, AKA code, will be stored in somewhere and executed later when in need. You want to be able to configure your infrastructure with textual descriptions that you can give to a tool to perform. The tools that accomplish this are called configuration management systems. These tools, such as Ansible, Puppet, and Chef, allow you to describe your infrastructure in code, and then they create that infrastructure and maintain its state.

You never want to manually make system changes to the software configuration. This is not reproducible and is extremely error-prone. You want to use templates and scripts that describe how to install and automate configuration elements, such as systems, devices, software, and users. You can then take this text code and store it in your git so that you have a history of all changes. That way, everyone knows which version is the latest and what the infrastructure should look like. This way everyone knows which version is the latest version and how the infrastructure should look. Docker, Vagrant, Terraform, and even Kubernetes, also allow you to describe your infrastructure as code, and this code should be checked into version control.

Ephemeral Immutable Infrastructure

The reason this is so important is that server drift is a major cause of failure. Over time, servers are updated for a variety of reasons, and not always by the same people. This causes them to drift from their initial configuration. Sometimes the accumulation of these changes can cause failures in unpredictable ways. Worse, there are servers that should be the same, but one of them keeps failing due to a misconfiguration somewhere. I think that the servers should be considered as cattle, instead of pets. You see, cattle there are thousands of them, it is waste of time to name and care each one of them. But the pet on the other hand? When they get sick, they are lovingly pampered and cared to keep healthy. The message here is to not lovingly handcraft servers or spend too much time debugging them when they don't work. You want to be able to replace them with an identical server that works properly. This means you have to think of your infrastructure as something ephemeral or transient. It only exists for as long as you need it, and then you remove it when it is not in use.

Immutable Delivery via Container

Application are packaged in containers

Docker is a packaging technology that allows us to bring things up and down in a consistent way in an isolated environment called a container.

Same container that running in production can run on your laptop

Docker supports infrastructure-as-code, allowing you to specify how to build images from code called Dockerfiles. These Dockerfiles build the same images the same way every time. Docker then creates a container from that image in the same way each time it is deployed. This means that the same container running in production can be run on the developer's laptop. This is the ultimate development-production parity.

Immediate rollback and rolling update

You're not installing the application, seeing if it works, and uninstalling it if it doesn't. You're just starting it with a new version of the Docker container. If it starts having problems, you stop it, shut it down, and take out the previous version that's already installed in its own container. It's literally a matter of seconds. You can use the same approach for containers that start misbehaving. You delete this container and create another one to replace it. The new container will be exactly the same as the old one was on the first day it appeared. The reason for this is simple: if you patch a container, it dies, a new container is brought up to replace it, and the new container is unpatched.

So, IaC is an important part of the DevOps process that describes service facility in text and then executes that code to create environment. In practical development needs, by combining technologies such as webhook, through automated testing, and then CI/CD pipeline to release code, developers can release code faster and more efficiently.

Thanks for reading!