Idempotent configuration management sets things right -- no matter what
Idempotency ensures a system won't stray from its designated desired state, sending alerts to systems administrators if a requested change would cause a disruption.
Traditionally, systems architects manually provision software applications by building up knowledge about a system's needs and making IT resources available from development through testing to operations. It's not the best approach.
As systems architects are not perfect, many systems end up woefully underutilized -- wasting hardware, power, licences and maintenance costs -- while others lack necessary resources -- leading to performance issues. Even with the elastic resources of cloud computing, systems administrators must still ensure that the operational environment is configured correctly to optimally host the workloads.
This is where idempotency comes in. Based on a mathematical concept introduced by Benjamin Peirce in 1870, the term now applies in multiple areas of computing. This does lead to confusion, as idempotency within a database is different from that in a Java program, which is different again from idempotent configuration management, which concerns modern DevOps and IT administrators.
Idempotent configuration management gives administrators the ability to repeatedly carry out a set of actions to the same result. This is particularly important as organizations move toward a DevOps approach based on continuous delivery (CD). Continuous delivery enables a continuous stream of new incremental functionality for implementation, with DevOps streamlining the movement of these incrementally updated workloads from development and testing environments to operations. Rapid updates and DevOps synchronization isn't possible when the IT team manually sizes and sets up the production environment. Idempotent IT systems are garnering great interest to operate complex hybrid cloud systems with CD and DevOps.
Benefits of idempotent configurations
The aim of idempotency is a desired state that is defined and then created -- time after time.
In a DevOps organization, the systems administrator can provision a highly defined and audited workload in the operational environment using configuration management, CD and DevOps tools, such as Jenkins and Chef or Puppet. However, without an idempotent provisioning tool, the administrator cannot guarantee that the same results will occur every time that workload is provisioned in production. This lack of repeatability affects workload portability, as in multicloud environments or cloud migrations.
Even without portability requirements, users find that some configuration management tools result in major issues caused by phantom remnants of previous scripts and processes. Phantom script fragments affect memory and storage; sometimes scripts slow down or time out due to these artefacts.
An idempotent configuration management system ensures that such problems do not occur. The idea is to turn any systems administrator into Star Trek's Captain Jean-Luc Picard: Decide what is required and "make it so."
The aim of idempotency is a desired state that is defined and then created -- time after time. Where a system has already installed a function successfully, it should not have to install it again. If something happens that moves the platform away from the defined desired state -- a systems administrator takes a manual action for example -- then an idempotent system will do what it can to return to the desired configuration.
In essence, idempotent systems know the desired state and maintain this configuration in perpetuity.
Idempotent configuration management's strength -- and weakness -- is that it prevents uncontrolled changes that could destabilize a production environment. The downside for administrators comes when a basic, easily fixed flaw is identified. In an idempotent configuration, this manual change goes against the defined desired state. The fix requires a more complex process to let the idempotent configuration management system understand that the desired state must change, what that change is and how to make it so.
The right idempotent configuration management tool
Effective idempotent IT management systems build up libraries of scripts that are agnostic to the infrastructure platform against which they operate. They must ensure that a workload is provisioned to the correct IT resources and with the correct versions of components every time. A configuration management tool should ensure that changes to the environment are logged, and alert someone for any necessary response. For less reactive management, look for systems that can automate the remediation that will return systems to their desired states.
Idempotent configuration management tools should also prevent redundant actions and foster improvement. Scripts and processes resulting in non-ideal states must be logged and sent for review so that developers and systems administrators understand what is and is not acceptable to change.
Most IT organizations will make changes to a software application or server's desired state. Look for an idempotent configuration management system with user-friendly change definition and input. The tool should verify that changes to create a new desired state are possible and that achieving that state will not affect other workloads on the platform -- the desired states of all existing workloads cannot fail due to new or changed workloads.
Idempotency can be powerful, yet at this stage of idempotent configuration management, there are still areas lacking maturity. Nevertheless, start looking today at idempotent approaches to manage the complexities of hybrid platforms.
