Will DevOps spell the death of the CMDB?
The centerpiece of modern IT management has long been the configuration management database. CMDBs, or configuration management databases, arose as the original single source of truth about the IT environment. IT experts rely on this source to handle change management; maintain security and compliance; manage IT costs and performance; and tackle troubleshooting and incident management. But CMDBs are far from perfect. For example, CMDBs can demand time-consuming manual effort. They are only as useful as the timeliness, accuracy and completeness of the data contained within. The data in a noncloud-based CMDB can become inaccurate or incomplete as IT pros struggle with other pressing tasks. This causes a gradual erosion of asset and configuration data quality. As the pace of IT accelerates, and the IT environment becomes more accessible to DevOps developers and non-IT users alike, the challenges of CMDBs are impossible to ignore. IT organizations must revisit CMDBs and consider alternative practices and tools to close the insight gap. In simplest terms, a configuration management database is a repository that stores lists of information and dependencies about a wide array of IT assets -- called configuration items (CI). CIs include hardware, software, networks, physical location details, documents and other media. Early CMDBs were little more than lists or actual database/spreadsheet tools that required manual data entry and updating. As CMDBs matured, additional discovery and data import capabilities helped simplify and hasten data entry by collecting details directly from CIs or other sources -- such as another database. Ideally, a CMDB possesses a complete set of details about every CI in the enterprise IT environment. The CMDB can accompany tools that query, sort, filter, chart (visualize) and report on CMDB contents. These interactions provide visibility into the IT environment. IT admins ensure that everything operates as-installed or as-intended. Agile development paradigms such as DevOps have sparked a revolution in app and service creation and delivery. Enabling developer and operations team collaboration facilitates more adaptable, effective and higher-quality software. CMDBs have played a role in this revolution, inasmuch as the data and insights they contain enable faster deployments, quicker troubleshooting and incident response, and stronger compliance and change management. As with business leaders and IT admins, DevOps is simply another "user" of CMDB data and insights. But CMDB tools and platforms are buckling under the increasing pressure wrought by the proliferation of resources, demands for faster change and the rise of more relevant management platforms and practices. In these environments, the CMDB clashes with DevOps activities in two key ways: Increased resource types and volumes. The CMDB's original purpose was primarily to track physical hardware, i.e., asset management. CMDBs expanded to accommodate intangible assets, including software and services. Today, most businesses routinely support a range of virtual assets, such as VMs, containers and cloud resources -- all of which DevOps uses for deployments. Now the CMDB must track the 10 VMs running on a physical server and track the dependencies between the VMs and the physical server. Ever-increasing complexity is difficult for CMDBs to handle. Faster change. Not only do CMDBs grapple with vastly more CIs in the environment, those items also appear and change faster than some CMDBs can handle. For example, a traditional physical server is installed in the data center and -- once configured -- runs untouched for up to five years. But a VM created for evaluation and testing runs for only a few months, to be retired and destroyed once the evaluation is complete. And a virtual container can deploy, run and spin down within a matter of minutes -- or even seconds. Even with well-considered automation and workflows, the rate of data creation and change is pushing CMDB technologies to the limit. As with business leaders and IT admins, DevOps is simply another 'user' of CMDB data and insights. DevOps-friendly CMDB alternatives CMDBs are called upon to hold and render enormous amounts of data, including each asset's financial details, performance and configuration profiles, upgrade and change histories, and other details that can be completely unrelated to the asset's actual use. Thus, CMDBs are sometimes expected to do too much and overextend their capabilities. Some IT organizations look to replace the CMDB with a faster and easier alternative, such as application lifecycle management, to focus attention on applications and services, rather than the underlying resources. Ultimately, the modern IT environment changes faster than the average CMDB can handle. This leaves gaps and missed updates in the CMDB's data and allows undesirable configuration drift, which threatens resource availability, performance, security and compliance. Time to modernize the DevOps CMDB IT and DevOps teams still need strong systems and change management, but CMDBs alone might not be enough to meet the scale and operational tempo of modern IT infrastructures. Fortunately, there are some simple strategies that help to address CMDB limitations. Reassess and refocus CMDBs. Determine if a business needs the scope and content of a CMDB. CMDBs arose when data centers were comparatively small and static. A single source of truth that was limited in scope and rarely changed its content was a practical goal -- even when handled manually. The demands of today's IT might mean that it's impractical -- or even impossible -- to establish and maintain that single source of truth reliably. Consider whether a CMDB actually needs to hold such comprehensive detail for the entire environment. IT organizations can trim and refocus CMDBs to address specific attributes or goals, such as tracking only mission-critical components and resources. Enhance CMDBs. Advanced CMDBs can include enhanced discovery functions that better find and interrogate physical and virtual entities. From a process or workflow perspective, CMDB updates tie into authorization, provisioning and lifecycle management, ensuring that any changes to the environment -- such as the VM lifecycle -- are captured in the CMDB. Look for other tools that populate and audit CMDBs. Such tools often include machine learning and AI capabilities, which enable the tool to learn how the environment works and feed data autonomously to CMDBs and other services. Retire and replace CMDBs. Weigh if other management and monitoring tools are more relevant. Today, IT is focused mainly on maintaining applications and services. The underlying infrastructure -- what is deployed, where it is and who owns it, for example -- is often a secondary consideration. A final alternative is to deprecate and retire CMDBs in favor of other highly automated tools that provide discovery, reporting, auditing and change management functionalities the business requires. For example, today's focus on application and service management drives the adoption of application lifecycle management platforms or more comprehensive IT operations management and IT service management frameworks. Look to automated tools, such as Chef or Ansible, to help with discovery, deployment and configuration management.