<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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 href="https://www.youtube.com/watch?v=I3DuUzGC-SU" rel="nofollow noreferrer">a talk</a> 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.</p>

CC BY-SA 3.0
2017-11-14T16:48:44.053Z
Do you happen to have video of the talk you could link to?
James Shewey
CC BY-SA 3.0
2017-11-15T03:11:14.370Z
It's linked in the post https://www.youtube.com/watch?v=I3DuUzGC-SU
Robo
CC BY-SA 3.0
2017-11-14T09:48:57.430Z
2017-11-14T09:48:57.430Z
Robo
<p>The two terms are very different.</p>

<p>Let us start with <code>immutability</code>, 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.</p>

<p>The term <code>idempotence</code> means that when changes are applied <strong>multiple</strong> times, the state is mutated (changed) just <strong>once</strong>. 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).</p>

<p>In the use of configuration management tools, <code>idempotence</code> is used in some cases when applying the same change multiple times. Like adding the line that says <code>localhost</code> to the <code>/etc/hosts</code> file, you don't really need multiple such lines and if one already exists it is safe to not try to append again. </p>

<p>Also <code>idempotent</code> is a term used to describe <em>actions</em> that attempt to change things, while <code>immutable</code> is used to describe <em>nouns</em> (objects) that are set against changes done to them.</p>

<hr>

<p>Why is an <code>immutable</code> 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.</p>

<p>Why are <code>idempotent</code> 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 <em>log files</em>, you don't want to have idempotent actions because you often do want to append another line each time some event happens.</p>

CC BY-SA 3.0
2017-11-02T17:08:54.630Z
idempotence also implies pesudo-omnipotence because of it's repetitive nature. If a user changes something outside of the configuration management system, it likely will be changed back (if the configuration management system runs as root). So it doesn't just mean `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*
James Shewey
CC BY-SA 3.0
2017-11-02T17:46:35.390Z
You describe a property of configuration management systems, maybe “promise theory”. But it is not what idempotence means, idempotence is just a tool in the configuration management system’s arsenal. Once you start changing state, mutating stuff either way, it cannot be in any way similar to immutability. It is a contradiction.
Evgeny Zislis
CC BY-SA 3.0
2017-11-03T19:24:09.707Z
@JamesShewey omnipotence means unlimited power, I doubt that idempotence means anything related to that.
Evgeny Zislis
CC BY-SA 3.0
2017-11-03T20:19:07.807Z
onmi=many | idem=repeated | potence=power. They both share the same root indicating something (a configuration) done. Thus, in doing the same thing over and over, if a change is attempted it is overridden by the configuration management system making it's potence omni. (and I'm sure this could be hacked by, say, disabling the configuration management service, thus not *truly* onmi). This property can be used to set an immutable state.
James Shewey
CC BY-SA 3.0
2017-11-03T20:22:01.517Z
`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.
James Shewey
CC BY-SA 3.0
2017-11-03T20:26:33.430Z
Often a configuration management system of some kind (Dockerfile) is used to create the immutable artifact, but once it is created no future changes are done to it. In such a case idempotence is not really so useful, since it it often that the initial state is the “base” or “unchanged” state (like the image coming from a vendor or third party). And applying some state changes to it can benefit from idempotence actions, but these are often not required. In other hand when mutable systems are concerned, idempotence has the advantage of changing the state towards the desired state (promise theory
Evgeny Zislis
CC BY-SA 3.0
2017-11-02T16:58:08.153Z
2017-11-03T19:19:54.060Z
2017-11-03T19:19:54.060Z
Evgeny Zislis
<p>Many in the DevOps apply the <a href="https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets">cattle-not-pets</a> mentality by implementing <a href="https://devops.stackexchange.com/questions/109/what-role-do-configuration-managment-tools-play-in-immutable-infrastructure">immutable infrastructure</a> and redeploying when changes are needed (instead of modifying).</p>

<p>Configuration management has a <em>similar</em> principle of <a href="https://puppet.com/blog/idempotence-not-just-a-big-and-scary-word" rel="noreferrer">idempotence</a>. 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?)</p>

<configuration-management><immutable-servers><cattle-vs-pet>
A comparison of idempotence and immutability
James Shewey
# A comparison of idempotence and immutability

(Asked by: username_0 on 2017-11-02)

Many in the DevOps apply the [cattle-not-pets](https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets) mentality by implementing [immutable infrastructure](https://devops.stackexchange.com/questions/109/what-role-do-configuration-managment-tools-play-in-immutable-infrastructure) and redeploying when changes are needed (instead of modifying).

Configuration management has a *similar* principle of [idempotence](https://puppet.com/blog/idempotence-not-just-a-big-and-scary-word). 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?)

**Tags:** configuration-management, immutable-servers, cattle-vs-pet


---

## 2 answers

### Answer by username_2 on 2017-11-02. Score: 10

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.

> **Comments:**
> **username_0**: idempotence also implies pesudo-omnipotence because of it's repetitive nature. If a user changes something outside of the configuration management system, it likely will be changed back (if the configuration management system runs as root). So it doesn't just mean `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*  
> **username_2**: You describe a property of configuration management systems, maybe “promise theory”. But it is not what idempotence means, idempotence is just a tool in the configuration management system’s arsenal. Once you start changing state, mutating stuff either way, it cannot be in any way similar to immutability. It is a contradiction.  
> **username_2**: @JamesShewey omnipotence means unlimited power, I doubt that idempotence means anything related to that.  
> **username_0**: onmi=many | idem=repeated | potence=power. They both share the same root indicating something (a configuration) done. Thus, in doing the same thing over and over, if a change is attempted it is overridden by the configuration management system making it's potence omni. (and I'm sure this could be hacked by, say, disabling the configuration management service, thus not *truly* onmi). This property can be used to set an immutable state.  
> **username_0**: `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.  
> **username_2**: Often a configuration management system of some kind (Dockerfile) is used to create the immutable artifact, but once it is created no future changes are done to it. In such a case idempotence is not really so useful, since it it often that the initial state is the “base” or “unchanged” state (like the image coming from a vendor or third party). And applying some state changes to it can benefit from idempotence actions, but these are often not required. In other hand when mutable systems are concerned, idempotence has the advantage of changing the state towards the desired state (promise theory  

---

### Answer by username_1 on 2017-11-14. Score: 2

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](https://www.youtube.com/watch?v=I3DuUzGC-SU) 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.

> **Comments:**
> **username_0**: Do you happen to have video of the talk you could link to?  
> **username_1**: It's linked in the post https://www.youtube.com/watch?v=I3DuUzGC-SU  

---

