DevOps, Software-Defined Infrastructure, and the CMDB’s Perception Problem
At the 2017 Configuration Management Camp, in Ghent, I helped to instigate an impromptu group discussion on CMDB.
The very name of this conference highlights a gap that exists between the ITSM world and the agile and DevOps ecosystem: “Configuration Management” here does not refer to any ITIL definition of the term. The focus of the conference is open-source infrastructure configuration tools such as Puppet and Chef, and the communities surrounding them.
The initial growth of these technologies was in web startups and pioneering cloud infrastructure providers. However, they are now being driven ever-more into the mainstream in established enterprises, through the adoption of DevOps, the growth of cloud infrastructure, and the increasing number of acquisitions of technology startups by non-technical companies.
As a result, it has been notable that an ever larger proportion of the attendees of Configuration Management Camp (and other conferences like it) are employed by established enterprises.
Many of those people now find themselves interacting with enterprise technical support channels… and enterprise complexities. This is a world where their new application, whether they like it or not, is likely to have multiple dependencies on pre-existing systems which might be running across multiple stacks of infrastructure, from mainframe to multi-cloud.
In the enterprise, there is a greater number of failure surfaces, a more complex set of potential regression challenges, and a larger and broader range of people asking for help (at the 2015 event, Puppet founder Luke Kanies pointed out that the enterprise world “doesn’t move slowly because they’re stupid or they hate tech. It’s because they have…what’s the word?…Users”).
From the outset, the participants in this conversation were very negative in their perception of the state of the ITSM CMDB:
- “ITIL isn’t working where you’re doing 20 releases a day”
- “If you start calling it a CMDB, people draw the wrong conclusions”
As software-defined infrastructure professionals, these are people who see their environments in terms of builds and deployments much more than bare metal servers or VMs. The objects they work with are more dynamic and abstract than the things they perceive to be the contents of a classic CMDB. As Forrester’s Charles Betz observed in a September 2017 article:
I have heard DevOps professionals say, “GitHub is our CMDB.”
In fact, conversations with DevOps and cloud people about the CMDB often take an even more explicitly negative slant, as reflected in these recent Tweets:
“Oh gosh — the CMDB is still ‘a thing’?”
“The corporate world is still clinging to [CMDB] and ITIL — meanwhile modern IT operations moving on to dynamic containers + serverless …”
And yet, as the people around the table talked about the challenges that faced them in dealing with support issues, it was fascinating to listen to the kind of information they were seeking. Here are some examples:
- Being able to understand drifts, timelines, discrepancies: “The person who is on call at 4am needs to know who has been doing what”… “A slider of the timeline of events”… “If you’re dropped in the middle of something, how did you get here?”
- Knowing what is actually deployed on an environment? “When you change a value you need to know what is actually running”
- Understanding business and service information related to the thing that is happening: “Context is a trigger word for me… in a company of 4000 people, things can get out of hand really fast if you don’t have context”… “Here are the links, here are the performance graphs, here are the people…”
The most striking thing about these asks is that they so closely resemble the wishlists underpinning countless large CMDB initiatives over the last decade or two. There is nothing here that is not a goal enabled by ITIL’s vision of Configuration Management. One could decompose these asks into two key needs: the requirement to understand the customer better, and the desire to have a clearer picture of the wider infrastructure context. These are things that ought to be in ITSM’s sweet spot.
So why the perception problem? I’ve explored this challenge in many conversations with DevOps and software-defined infrastructure professionals, and some common themes tend to emerge:
- There is a strong perception that CMDBs are for modelling legacy on-premise infrastructure and traditional enterprise software, rather than the “new stack” of cloud and software defined infrastructure, and the modern workflows hosted on it.
- There is also a widespread feeling that the discovery tools that populate CMDBs work on a periodic data-collection cycle which is too infrequent to be useful in a highly dynamic modern infrastructure.
- There is a broad view of ITSM processes, including those surrounding the CMDB, as a barrier rather than an enabler. “Have you updated the CMDB?”
- Additionally, the historical failure rate of CMDB projects has created a major “branding problem”.
In other words, “The CMDB isn’t relevant to us”, “the CMDB adds no value”, and “CMDBs don’t work anyway”.
Clearly, the ITSM community needs to do a better job of showing the value it can provide in these areas. If ITSM is done properly, there should be a significant and real-time resource of information on the customers impacted by an issue. When a support engineer picks up an issue which is impacting an application or infrastructure element, effective ITSM ought to provide understanding of the wider context, at a business and technical level. These are not new outcomes for ITSM.
And yet, as devops and software-defined infrastructure teams get drawn into the enterprise support system, they increasingly need the things that ITSM should be great at providing. There is much to be offered in areas such as multi-cloud discovery from the most sophisticated tools, which would be of huge and immediate value here. The age-old problem of reconciling from multiple sources into a single viewpoint is even more relevant in a fast-paced multi-cloud environment. This is a key capability of the best CMDB technology.
However, there are several big challenges to overcome.
From a tooling perspective, a lot of ITSM technology, particularly in the crowded mid-market, really is significantly out of date, with some CMDBs tools amounting to little more than asset repositories, data structures fixed on legacy physical infrastructure, and discovery tools unable to react to fast change.
Additionally, many ITSMs practices simply fail to engage the DevOps and software defined community. The ITSM community needs to realise there are genuine reasons for this. The three-tier support team structure, for instance, while ubiquitous in enterprise support, is seen as siloed and slow, particularly when Devops and software-defined infrastructure teams find themselves at the foot of it. This perception was affirmed by multiple attendees of devopsdays Edinburgh in October 2017, when I presented about swarming as an alternative.
Unfortunately, the ITSM community often seems to suffer from a collective lack of awareness and understanding of the history and culture of DevOps. There is little dialog between the communities (worryingly to me, I still typically find myself being the only ITSM person at almost every one of these events). The debate is frequently bogged down in a semantic analysis of process compatibility (a problem I wrote about a year ago) rather than a genuine exploration of potential value.
It’s critical in the short term that there is more outreach from ITSM to the new technology and practice communities (and, conversely, it was refreshing to hear Devopsdays Edinburgh’s keynote speaker Maria Gutierrez making the equivalent suggestion to the DevOps community, urging them to talk more frequently with customers and frontline support teams).
Only with better dialog between the two communities can we clearly understand the opportunities that exist for ITSM to create and sell-value to the DevOps and software-defined infrastructure world, and to solve problems such as those I heard in Ghent. There will still be work to do in terms of tooling, practices, and shared knowledge. CMDB technology in particular might have to evolve rapidly (and in some cases, it already is). For example, it was pointed out in Ghent that infrastructure automation scripts rather than humans, might be the primary CMDB consumer. As DevOps and automation grows, there are clear unmet needs which ITSM should be targeting.
A big improvement in mutual awareness is the critical starting point. Let’s talk to each other much more.