While CMDBs still have value, they no longer dominate IT management. See what CMDB integration options remain and why IT admins should look beyond the repository software.
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. How can a developer provision resources and services quickly for an incoming application build if the CMDB is outdated or inaccurate -- if not missing altogether? Practices like DevOps demand more flexibility than the standard-issue CMDB can provide, which begs the question: Under DevOps, is the CMDB obsolete?
IT organizations must revisit CMDBs and consider alternative practices and tools to close the insight gap.
What is a CMDB?
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.
DevOps poses challenges to the CMDB
How do CMDBs and DevOps interact?
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.
Look past CMDBs for DevOps
As more developers manage operations-related tasks, it's vital to understand the resources and services present in the business, as well as how those assets are configured. This kind of information helps IT pros provision new resources and deploy new software builds accurately and securely. CMDBs have long been a bulwark of such efforts, but CMDBs might no longer be the best single source of truth in busy, dynamic IT environments. DevOps organizations look past CMDBs to embrace leaner and more versatile platforms, such as ServiceNow, Now Platform, CloudBees CI, Red Hat Ansible Automation Platform, SaltStack, TeamCity and others.
Dig Deeper on Systems automation and orchestration
