IT Automation | Mutable vs immutable infrastructure
When it comes to IT Automation we have to decide whether we want mutable or immutable infrastructure. This article will describe the difference and show why it is not always one way or the other.
The traditional way of managing IT Infrastructure was an initial setup and do all sorts of upgrades and changes over its lifetime. It may vary how often we have to change something but in most of the cases the effort needed to do changes exceeds the installation effort mutiple times. Setup is cheap, maintenance is expensive. IT Automation can help reducing that effort but it can also make things worse if done incorrectly.
Mutability is one of the most important factors to consider when planning IT Automation. Mutable infrastructure means that we are doing changes to the infrastrucutre during runtime - our configuration evolves over time. Immutable infrastrucutre refers to the approach of exchanging an entire component againt an updated one.
While mutable vs immutable infrastrucutre refers to an overarching concept that does not mean we are bound to use specific tools or technologies.
Let’s use some examples to understand the difference.
Physical servers
Typically physical servers are regarded as an example for mutable infrastructure. But that does not have to be the case. Rather than booting an operating system from harddisk it can also be on a tftp share that gets loaded on startup. Every time we boot the server we could get an upgraded version. This approach is widely adopted with Hiph Performance Clusters. Another approch could be to automatically reprovision servers during the night with a golden image.
Virtual machines
Using virtual machines gives us more capabilities such as creating VMs from templates. We may treat our infrastructure as mutable when we set up an EC2 isntance and do all sorts of changes over the lifetime of the server. On the other hand we can use the exact same technology to build a new AMI and roll that out once something changes. That would be an example of an immutable infrastructure.
Containers
Containers are often associated with immutable infrastructure but as shown here (http://www.it-automation.com/2021/07/02/docker-basics-kernel-namespaces.html) that is not what makes up a container. We can still do changes within the container and treat it as mutable infrastructure. As long as we do not delete a running container we can do upgrades inside of it. It is up to us how we use this technology.
Ansible
While containers are often used as synonym for immutable infrastructure the same is true for configuration management and mutable infrastrucutre. But that does not have to be the case either. We can run Ansible playbooks on mutable infrastructure but we can als use them to build templates with Packer.
Terraform
Terraform is not one way or the other either. It does both mutable and immutable infrastructure. Think about the output of a terraform plan. It tries to upgrade infrastrucutre in place if possible. But what about doing a terraform destroy before running terraform apply?
Mutable vs immutable infrastructure neither refers to some technology nor does it say that one is superior over the other. It is just an overarching concept we should aware of. In order to do that we have to broaden our view and get away from the details of implentation.
“Most of the mistakes in thinking are inadequacies of perception rather than mistakes of logic.” — Edward de Bono
