Immutability & loose coupling: a match made in heaven

When it comes to infrastructure and deployment automation, two opposite approaches share the podium: mutable vs immutable management.

Mutable Systems
 

Mutable systems usually have a long life cycle, typically in the order of weeks to years. As their requirements change (new files, configurations, users, packages, etc.), the systems are modified to match a new target state. When left unmanaged, mutable systems tend to drift away from their target state, in a divergent dynamic.

Automating mutable systems is often referred to as Configuration Management, and leverages tools such as Cfengine, Puppet, Chef, or Ansible. This tooling uses principles based on the concepts of target state, idempotence, and somewhat related to Mark Burgess’ Promise Theory. Configuration Management aims to make the system convergent, by running a tool on a regular basis, in order to resynchronize the system with its target state. Some of these tools (e.g. mgmt) also attempt to reach congruence by adopting a reactive approach, triggering corrective actions on events.

However, immutability comes with a high cost: in order to be done properly, it must be strict. Any change to the state involves a complete replacement of the artifact. A lack of abiding to that rule results in a convergent system (at best), which cannot be managed in an immutable manner.
 

Mutable vs Immutable
 

If immutable systems are easier to maintain, what are the reasons for not using them?

The system’s complexity is probably the main justification. A traditional mutable system features multiple layers (Operating System, Middleware, Applications) that are usually strongly coupled. For example, the flavor and version of the Operating System define which version of a Middleware (e.g. Tomcat, Apache) is available for installation. In turn, the Middleware version defines which libraries are available for the Application. On most Unix-based systems, shared libraries are at the root of strong links between software versions, based on the underlying ABIs required to run them.

If such strongly coupled systems are to be managed in an immutable manner, then the whole system is the immutable artifact. In the majority of organizations, this implies managing tens to thousands of artifacts, and rebuilding them from scratch on a regular basis. Such complexity is too much of a cost.

Enters decoupling technologies: Over the years, new technologies have surfaced, which allow to decouple system components and ease their management in an immutable manner.

Container Orchestration is to Containers what IaaS is to Virtual Machines

Immutability & Convergence
 

Now that we have a full Immutable System, does it solve the problem of convergence?

Immutable artifacts in themselves are not supposed to evolve, but their target state does evolve. In this regard, the situation with containers is similar to that of Golden Images for Virtual Machines: though the artifact is immutable, it can easily be used as a template leading to an unmaintained, divergent system.

There is thus still a need for convergence tools in the container world. However, this is not because the objects themselves drift from their target state. Rather, the target state evolves while the objects —supposedly— are stuck in their original state.

Where Configuration Management tools ensure a convergence of states for mutable systems such as VMs, packaging tools such as Helm and Helmfile can be used to periodically re-synchronize containers and other immutable objects with their target state.

Finally, congruence is also achievable, with tools such as Argo CD. Argo CD not only deploys immutable objects to a Kubernetes cluster, but also keeps them synchronized with their last known target state, ensuring a continuous management.

Conclusion
 

Containers and Container Orchestrators enable fully immutable workflows for infrastructure, middleware and applications alike:

• Nodes can be managed as virtual machines, with immutable VM images deployed dynamically using IaaS;
• Middleware and applications can be managed as containers, with immutable OCI images deployed dynamically using Container Orchestrators.

Are immutable systems always the best answer? As we’ve seen, the cost in artifact management and orchestration is far from negligible. Due to the transient nature that comes with their immutability, containers are better suited for stateless applications that easily scale on clusters of neutral nodes. For this reason, highly stateful applications with long life cycles, such as databases, are still better maintained as mutable systems most of the time.

Choosing an immutable vs mutable architecture depends a lot on an organization’s software architecture and culture, and is not a light choice to make.