Exploring Immutable Code & the ITIL Configuration Management Database

Over the last two decades, configuration management tools, i.e. those that effect and/or record a change, have multiplied in number however the associated thinking doesn’t seem to have changed much. But are we on the cusp, finally, of a big change?If cloud is changing what we manage and DevOps is changing how we manage it, in the middle of it all we are not only seeing new, different tools but also new methods such as immutable infastructure and infastructure as code. Put them all together and ITIL configuration management feels like it’s due for a serious overhaul. But what is really changing? Everything!

So, What’s Configuration Management?

From AXELOS, the custodians of ITIL processes, best practice we understand that configuration management is:

“...about having a record of your systems, what’s happened to those items and the details of the relationships between the items on your list.”

And configuration management process tools can cover a spectrum of capabilities – from recording configurations (in a configuration management database (CMDB) or configuration management system (CMS)), through deploying new configurations, to checking the production environment matches the configuration model.

However:

Immutable infrastructure changes “what’s happened to those items” because changes are not applied “in the wild,” they are baked into immutable images.

Infrastructure as code changes the record and the relationships by moving that information into the system that builds the infrastructure, by developers who know the code, not configuration managers in another team.

You can sense the DevOps-iness of this – it’s like moving from artisan hand-crafted IT to “Toyota Production Line” IT, and one senses that Deming would approve. And just as ITSM is becoming the customer interface to DevOps, these code configuration considerqations are critical for traditional ITIL-based organizations to have better visibility over their system changes.

Learn how ChangeGear supports DevOps and ITIL Change Management

The serious problems with Mutable Infrastructure?

For the past twenty years, configuration management tooling has made changes to infrastructure “in place.” Using either a pull or push mechanism, new changes to a piece of infrastructure like an application, a server, or a switch are made via a script, and perhaps the server is restarted to effect the change.

A periodic check is made by the configuration management or discovery tooling for any changes made to the actual configuration in place, because changes can be made outside of the process, and these are compared to the model configuration. If there’s a discrepancy then the running configuration is updated in place, remediated to match the model. This is mutable infrastructure, it changes over time.

Mutable infrastructure is at risk of configuration drift and technical debt, where a component is the victim of unrecorded administrator changes. The situation might become so bad over time that the running state has drifted so far from the configuration management-held model that the server becomes a snowflake server, so fragile and delicate people are afraid to touch it. Thus making small changes to running production systems is fraught with danger, stress, and anxiety.

This drift and debt slows down change and release management significantly – as everyone tiptoes around the snowflake infrastructure and applies more and more process and hand-off “band-aids.”

The solution to this is moving from mutable infrastructure to immutable infrastructure and to move configuration details from separate configuration management systems into code.

Melt Snowflakes and Sooth Brows with Immutable Infrastructure

Immutable infrastructure is not changed in place, while it’s running. Nobody can log onto immutable servers, and traditional configuration management tools do not apply changes (though they can deploy new immutable instances). Changes are baked into images which are then deployed and never changed while running – infrastructure component changes are made by deploying the whole component, and even the whole environment, again.

An example is updating a three-tier web application. If the web server software needs to be upgraded because of a security patch, the patch is not applied to the server that’s running. Instead, the patch is applied as part of a virtual machine image build. That image build is then tested. On success, that image will be deployed to production. The proper procedure is to deploy a canary release to handle a small amount of load, and if that’s okay then to replace (not update) the remaining components with the new image.

Think of this as replacing written documents and diagrams, and the use of low-level configuration items in CMDBs, with coded configurations of what the target system should look like.

In essence, engineers code the configuration into the system components, including their relationships – into a file inside the application folder that lives in a version control system such as GitHub or AWS CodeCommit. An example would be using AWS CloudFormation, Hashicorp’s Terraform, Red Hat’s Ansible, or one of the many other tools.

An excellent visual of this can be found in the infrastructure as code SlideShare from AWS:

To deploy an infrastructure as code system the engineers either raise a pull request or press a build button to trigger a continuous integration/continuous deployment (CI/CD) pipeline build – there is no graphical user interface (GUI) or command line interface (CLI) hand-crafting. The configuration management tool – such as AWS CloudFormation – will consume the configuration file and build the target system; or update it by replacing (not updating) components that have changed.

Discover the 25 Key Requirements for a Change Management Solution.

How Will Your Configuration Management Be Impacted?

The change from nursing a fragile infrastructure to an immutable and coded infrastructure means that you need a lot less and a much different set of change, configuration, and release management processes:

Immutable infrastructure eliminates the fragile snowflakes that are notorious sources of technical debt (and that trigger more process band-aids and slow down the business).

Infrastructure as code puts configuration management into the system so external CMDBs are less important to make relationships between systems by hand.

However, doing this requires skillsets that organizations may not possess, specifically in DevOps CI/CD, cloud systems, and tools like CloudFormation, Terraform, or Ansible. It’s also the case that existing systems might not be suitable for this approach as they’re not programmable (unlike a cloud system).

Therefore, it’s highly likely that while no-legacy organizations can just run with this new approach, more-complex organizations with older IT systems will have to decide case-by-case on its adoption and the co-ordination with existing ITSM people, processes, and technology.

Contributing Author: Stevie Chambers

Previous Article

10 Tips For Selecting an ITSM Software Solution

So you’ve been tasked with selecting a new IT Service Management (ITSM) tool solution? Whether you’re upgra...

Next Article

10 Service Desk Metrics, Shift-Left, and AI Nuggets from HDI 2017

The annual HDI Conference is done and dusted for another year, although I’m unsure what the Washington equi...