Attribution
During standup the other day, when asked for my update, in a blasé fashion, I said, “I figured out the Terraform I wrote yesterday has a bug — if you run it a second time, it destroys the original resource. Today, first thing, I am going to figure out why it’s not idempotent.”
My Scrum Master looked at me like I had more heads than a hydra…
Desperately trying to avoid devsplaining it to them, the definition of insanity came to mind.
Doing the same thing over and over again, but expecting different results.
Albert Einstein or Mark Twain or Ben Franklin or…
So, idempotency is the exactly that except you’re expecting the exact same thing. Let me explain.
You want get the marble (to the right) in the hole 2ft away. There are (at least) two ways I can accomplish this.
- Roll the ball two feet (defining what to do)
- Roll the ball until it’s in the circle (defining what I want)
Both actions would get the ball to the circle. If I “run the process” again, idempotency because apparent… If I just try to roll the ball 2ft along the same line, the result is shown in the picture below.
Every time I “run that process”, the marble moves 2ft further away from the circle. This is because I’m telling the process what to do. HOWEVER, if I were to tell the process what I want (move the marble to the circle), the marble gets to the circle in step one and stays there in subsequent runs because I already have want I want (the marble in the circle).
THIS IS IDEMPOTENCY
Characteristic of an action that does not change the state of an
unchanged system on subsequent runs.
Now, quickly, let’s discuss why this is such a HUGE deal in DevOps and Configuration Management…
If I say, “I want Visual Studio Code installed,” on a particular computer, I’m defining the “state” that I want that computer to be in. The tools I would use in that situation include Microsoft “Desired State Configuration” (DSC), Chef, Puppet, Ansible… There are a ton of them. Nonetheless, when I tell my tool I want Visual Studio Code installed on a computer, one of two things should happen:
- If it’s not there: install it
- If it’s there: do nothing
If Visual Studio Code is installed, the tool should NOT try to install it again but rather see that the system is in the desired state and then stop.
Visual Studio Code installation is a VERY simple example and, if the configuration management package tries to install it again, really, who cares. HOWEVER, if you create Terraform code to build a cluster and, for example, you decide to add one more compute node to a 20 node cluster, you care a WHOLE LOT about whether the code you wrote is going to add 1 node or destroy 20 and recreate 21.
Just a little ditty to try and raise the digital sensibility…