Deep Thought: DevOps CMDB – Connecting Marvin’s Depressed Brain

What was it Marvin said from Hitch-Hikers? “Here I am, brain the size of a planet and they ask me to take you down to the bridge. Call that job satisfaction? ‘Cos I don’t”. Marvin was one of a series of robots that was given a singular personality to make them seem more real. For him, I’m afraid it was depression. However, the saddest part was that here was a huge, rich source of information, and yet he was only used for menial tasks such as parking cars. What a wonderful comparison that is for the greatest unused data we have at our disposal, the Configuration Management DataBase, or CMDB.

When the IT industry talks of latest trends such as DevOps, the Cloud and Big Data, they often miss the trick that supporting all of this is usually one thing that has been around for decades, the CMDB. The CMDB is the DevOps Big Data. For me, however, there is a greater frustration, and something of a personal one. My first toe-dipping into the world of process improvement was in Configuration Management, and to be precise, Software Configuration Management. Some years later, my perspective, learning and experience had somewhat expanded and I learnt about frameworks such as CMMI and ITIL. Each of these frameworks took an opposing principal view of the IT world. CMMI from Development and ITIL from Operations. That is not to say they weren’t exclusive of the others perspective, however, neither did they quite fit together.

It was around Configuration Management that I had my greatest source of frustration, and still do today. Each framework clung desperately to its view of what Configuration Management was and that is a truth still held by many today. The CMMI view was that it was a database for the control of source code. A method for managing the process of change to these assets to the point at which it was ready for production. The ITIL view was that it was repository for the cataloguing and association of assets in the production area to be managed for a support purpose. Here then is our ultimate silo wall in DevOps, the Great Wall of CMDB you may say.

If we are to truly have DevOps with no silos then this wall must be breached. Yet even today, in many organisations that have gone so far towards a DevOps culture, there will be a Software Configuration Management repository for source code, and there will be a separate CMDB for production assets. I spoke in a previous blog on the Total Perspective Vortex, and that discipline must be applied here. We must find a unified view of the CMDB that both Dev and Ops can be appreciative of.

I view a CMDB as this – “The CMDB is a Big Data repository for all Configuration Items key to the recreation of a production system, from the point of inception, to the point of decommission, identifying relationships, versions, dependencies and baselines”. Further to this, we must identify a Configuration Item as any “thing” that can be classed as part of that system. To this end, that must include all requirements, designs, tests, results, source code, compiled code, servers, infrastructure, blah, blah, blah... and in fact the list could go on forever. Nothing in that states that this is purely a tool for production support or development change. The state of a Configuration Item is merely where it is at as part of its flow. So recording the state of a Configuration Item, and any baselines it is part of, is important. But that is the way we must distinguish between the production and development assets, be where they are in the flow, not by placing them in isolated repositories.

It is at this point that you can begin to see the scale of a true CMDB, whether that is for our own Data Centre or for the Cloud, the relationships and dependencies span our entire enterprise. The CMDB is, therefore, our map of our universe, and if we wish to navigate that universe without incident, then we need to have a care to ensure it is maintained and complete, its information updated in real time to reflect the true nature of our universe. Updating with new creations as they are built and recording their state as they are maintained and updated, right to the point we no longer require them and they are removed. Our CMDB must be used for the brilliant brain that it is, not used for menial tasks like parking cars. That just sounds depressing.