When studying infrastructure as code tools such as Ansible, Chef, Puppet, and Terraform, you'll come across two key concepts: "mutable" and "immutable" infrastructure. If you are new to infrastructure automation, these terms can be a bit difficult to wrap your head around.

Don't worry, though. In this blog post, I'll break down these concepts in a simple, straightforward way. Let’s get started!

Immutable Approach

Let's say you have a web server running with an older version of NGINX and you want to update it to the newer version. To do this under an immutable approach, you would follow these steps:

• Create a new server image with the newer version of NGINX pre-installed. This could be done by installing the newer version of NGINX on a clean server and then creating a snapshot (copy) of that server.
• Test the new server image to make sure that it works as expected.
• Once you have confirmed that the new server image works correctly, you can use it to launch new servers or replace the existing servers with the new image.
• The old servers that are running the older version of NGINX will be terminated and replaced with the new servers that are running the newer version of NGINX.
• Once the process is completed, all servers will be running the newer version of NGINX.

It's important to note that the immutable approach provides a more consistent and predictable environment. This makes it easier to roll back and recover from errors. Also, the new image can be used as a base image for future instances and can save you the time of installing and configuring the software on new servers.

Mutable Approach

Under a mutable approach, you would update the existing servers in place. You wouldn’t have to create a new server image or replace the existing servers. Here are the steps you would take to update the NGINX servers under a mutable approach:

• Connect to the existing servers where the NGINX package is installed.
• Use a configuration management tool such as Ansible, Chef, or Puppet to install the newer version of the NGINX package on the existing servers.
• The configuration management tool will handle the process of upgrading and configuring the servers with the new version of NGINX, preserving previous configurations.
• Test the updated servers to ensure that they are working correctly
• Once you have confirmed that the updated servers are working correctly, you can proceed with the update process. This could be done by applying the changes to all of the servers.
• Once the process is completed, all servers will be running the newer version of NGINX and previous configurations will be preserved.

It's important to note that this approach allows for more flexibility and the ability to roll back changes if necessary.

Here's an analogy that can help you understand the distinction between mutable and immutable infrastructure more clearly.

Imagine you have a house and you want to change the front door. With the immutable approach, it's like building a brand new house just for the sake of changing the front door. You'd construct the new house with the new door already installed, test it out to make sure it's working properly, and then move in. The old house (with the old door) gets demolished and you're left with only the new house (with the new door). It's a bit like starting from scratch, but it ensures that everything is consistent and predictable.

With the mutable approach, it's like just changing the front door on the existing house. You'd remove the old door, install the new door, test it out to make sure it's working properly, and then call it a day. The rest of the house stays the same, and you're able to keep any of the previous configurations. It's a bit more flexible and allows you to roll back changes if necessary.