The CMDB Solves Yesterday’s Problems… the Cloud is Different

I spent many years building CMDBs for companies. The promise was that if we could just get the configuration information into a centralized database we’d be able to better plan, build, and run IT by understanding the landscape of applications and how they work. We had a relatively slow moving technology picture, with the complexity being different teams, working in different disciplines (storage, VM, OS, networking, etc.), all coming together to deliver a technology solution. We thought of the CMDB as a way to document the state of the system, understand what it should be, what it is, and respond/react/manage change. A lot of energy went into building and creating the matrix and the better implementations captured the relationship between applications, servers, and infrastructure/app owners for incident management/change management. What I’m here to tell you is that CMDBs were expensive and rarely accomplished their goal. The litmus test for me was “where do you go to find the most recent information when the system is broken?” Another was… “what is an example of where your CMDB has helped you prevent a disaster. Is there value in tracking application-to-server relationships? Yes, but the money and energy spent on CMDBs rarely passed the sniff test.

This was the typical approach of the CMDB… we can do better.

Modern Structures

The central idea of a CMDB, being able to understand your applications and draw relationships between the configuration and value is not wrong, just the methods are outdated. The modern environments are not constructed on slow moving infrastructures with highly segmented teams. Instead, they are built on modern architectures such as containers and serverless which drive the collapsing structures of teams with multi-skill frameworks. This isn’t to say there aren’t heavy dependencies… there are. The modern frameworks are so fast moving that legacy models of CMDB that barely worked before will certainly not work now.

The modern structure for service and configuration management maintains (1) what is important to the business, (2) who cares about it, (3) that it has technology relationships…. but the location and method for maintaining and understanding its configuration is much more capable. Instead of manual or automated means of updating a configuration database after the change is performed, we instead rely on infrastructure/app/config-as-code approaches to maintain and deploy the healthy state of the system. This is most easily enforced if code is the only way to deploy into the cloud environment, a step which should be made sooner vs. later. The movement to code-based deployment does two things (1) it increases reliability of the release process and (2) it facilitates a trusted source for the known configuration and historical configurations without requiring a separate synchronization back to another tool.

Bringing the Configuration to the Owner – Governance to IT

This approach also facilitates the movement of configuration management to the owner closest to the business need. The organization can enforce the requirement that certain information be maintained, but if the goal is not just passing an audit, but actual discipline regarding the deployed environment, this is the way to drive it. As we see the ownership of technology shift out of the IT department and into the business this shift is necessary to ensure that proper management is executed on.

Role of Service Management Platforms

The service management platform still has a major role to play, but it is more about connecting the dots than being an overplayed source code or configuration repository. This is especially true as IT becomes more about being a center of excellence that enables the business to do its work.

Relationship to Asset Management and End User Computing

The other area prevalent in the CMDB was asset management and end user computing, which had a very clear-cut purpose for maintaining inventory control because of the deployment of devices into user hands. This area will undergo a similar transition as end user computing becomes more commodity driven. When devices are an asset they need to be maintained and tracked. When devices become a commodity, much like your mobile device, the need to perform asset management will reduce. We will still need to understand what devices are in-user and by whom, but more of this will be the responsibility of the platform, especially as a user is free to replace their device at will or are individually accountable for procuring it from a major vendor. The primary controls will be enforced by the platform which implements conditional access to ensure only healthy devices are able to access resources. Think about the model of procuring a mobile device… do you maintain them as an asset? What about iPads? This is the future of device management. Does the Service Management platform have a purpose there? Yes, but it is different than it is today, just as it is in the datacenter space.

Legacy Process:

Modern Process:

Retrieving Information:

The beauty of modern structures is that they are queriable. You can either retrieve information from the infrastructure/app/config as code, or you can query the platform itself. This is the case for both datacenter and end user computing via technologies like the resource graph and the Intune graph API.

This shift both in the datacenter and in the end user computing worlds is very exciting to me because I believe it provides us the opportunity to have a much greater degree of control and certainty around what is running in our operational environments. The results will speak for themselves. The transition will be incremental and won’t be overnight, but the sooner we move to some of these concepts, the sooner we realize the benefits and impact to how we run our businesses.

Nathan Lasnoski