Many in the DevOps apply the cattle-not-pets mentality by implementing immutable infrastructure and redeploying when changes are needed (instead of modifying).
Configuration management has a similar principle of idempotence. What are the comparative benefits, similarities and drawbacks of immutability vs. impotence and which is more efficient? Can these be used synergisticly (eg, periodic deletion and redeployment of VMs or Docker containers using configuration management?)
The two terms are very different.
Let us start with immutability, which literally means "no mutations" or "no changes". In the DevOps sense, it means that once you created an artifact, be that a container image, or a VM image, or maybe a package from compiled code - you declare that you will never ever change it. Often if any changes are required, you declare that a new version of "thing" will be created instead.
The term idempotence means that when changes are applied multiple times, the state is mutated (changed) just once. First, it already assumes that there are going to be changes applied which means that you cannot have something both immutable and have idempotent actions done to it (no actions are done to it by contract).
In the use of configuration management tools, idempotence is used in some cases when applying the same change multiple times. Like adding the line that says localhost to the /etc/hosts file, you don't really need multiple such lines and if one already exists it is safe to not try to append again.
Also idempotent is a term used to describe actions that attempt to change things, while immutable is used to describe nouns (objects) that are set against changes done to them.
Why is an immutable object useful? Because when you copy it around, for example from a dev environment to qa to production. You already know quite a lot (but not everything) regarding how it is going to behave. In many cases, the parts that are working will be consistent, and the parts that are broken are going to be consistent as well.
Why are idempotent actions useful? Because when you want to change a state of some object, in many cases it is useful to only verify that the change has been applied and apply changes just in case it is required. For example, when a configuration item in a file is missing or has the wrong value, it is useful to add it just once or change it just once while applying the action multiple times. In many other cases, like log files, you don't want to have idempotent actions because you often do want to append another line each time some event happens.
the state is not changed. but instead that the state remains the way that the configuration management system dictates it to be. Hence, one way idempotent systems and immutable systems are similar
Commented
Nov 2, 2017 at 17:08
Once you start changing state - if you change the state with the configuration management system, yes, then it becomes contradictory. The presence and use of a configuration management system is not mutually-exclusive with immutability - it is all in how you choose to use it.
Commented
Nov 3, 2017 at 20:22
Immutable infrastructure is, in my mind, a different pattern to Configuration Management. While they can be used together, they approach problems by nature in two different ways.
The concept of Immutable Artifacts has a long history, Unix systems have been using them for decades to deploy software packages. But once they were deployed the configuration files were changed so things became mutable. Idempotency provides some nice guarantees with mutable files, we can know when things have changed and only update things that need updating. However it doesn't solve all the problems of mutable objects, we still need to cater a seemingly infinite number of edge cases. Because things are mutable and we are being idempotent we need to establish first what changes need to be made, then execute them generally in a very specific order. When deploying software packages, particularly with zero down time deployments, we need to carefully orchestrate changes to prevent any requests being dropped.
This complexity can ultimately be avoided by deploying immutable artifacts instead of mutating them in place, because we simply replace some object with another (whether it be a binary, or a container or a Virtual Machine), bring it into service and retire the old one. This is just one example of a zero down time deployment.
With advancements in tooling to allow us to deploy immutable artifacts to thousands of systems in a very small amount of time we are seeing using immutable tools to manage systems as a lot more feasible than configuration management. However the tooling is not there yet and there is still a use case for both. I did a talk on this subject which explains the linear progression from fully mutable to fully immutable, it's a spectrum and each company will chose where best fits for them.
