Designing a Cloud‑Ready CMDB: Lessons from a Decade of Ops Evolution

Preface

While many discussions focus on how to build a CMDB, the more critical question in today’s cloud‑driven era is what kind of CMDB should be built, especially for traditional enterprises that differ from internet companies in operational philosophy and organizational structure.

CMDB Development History

2004 – CMDB 1.0

Initial projects used Excel imports, required a predefined static model, and lacked dynamic extensibility.

2006 – CMDB 2.0

Adopted BMC Atrium, emphasized integration with ITSM processes such as incident, change, and impact analysis, but still relied on manual Excel imports and suffered from delayed updates.

2007 – Automation Begins

Introduction of automated discovery tools dramatically reduced manual data initialization effort.

2008 – Closed‑Loop Change

Industry promoted re‑discovering configurations after each change, improving data freshness compared with CMDB 2.0.

2012 – Comparative Scenarios

Banks began using discovery tools for configuration comparison across disaster‑recovery, production, and cluster environments.

Recent Years – CMDB 3.0

Automation lowered initial data effort, yet discovery tools still face latency, blind spots, and the need for privileged accounts, limiting practical effectiveness.

Cloud‑Era CMDB

With cloud adoption, managing cloud resources proved more complex than traditional assets, leading to a “cloud CMDB 1.0” that adds logical configurations such as LPAR, ports, HBA cards, LV, VG, etc.

Future “cloud CMDB 2.0” is envisioned as an open‑source project.

Common CMDB Implementation Problems

Lack of holistic planning : Unclear scope leads to indecision between breadth vs. depth, and static models cannot keep up with agile IT environments.

Unclear role definitions : Overlapping responsibilities among configuration manager, administrator, and owner cause friction; centralized control hampers flexibility.

CMDB becomes a burden : Massive initial data collection, limited single‑tool discovery, and frequent changes make data stale; solutions include automated collection, multi‑tool integration, and baseline‑driven change models.

Data value not demonstrated : Absence of well‑defined scenarios prevents data from being consumed, leading to decay; a scenario‑driven solution set is needed.

Challenges in the Cloud Era

Dynamic change of configurations, massive scale, and heterogeneity demand new models; traditional CMDB architectures cannot satisfy these requirements.

Typical Features and Paradigm of a Cloud‑Native CMDB

We treat CMDB as a service (CMDB as a Service) composed of five elements: model, items, operations, API, and scenarios.

Cloud CMDB: Consumers can access, maintain, and manage CMDB over the network at any time.

Service Elements

Configuration Model : Defines tags (servers, network, applications), objects, and attribute sets.

Configuration Items : Concrete instances of objects (e.g., IBM Server01).

Configuration Operations : Actions allowed on items (start, stop, restart, configure).

These elements must be exposed via APIs and tied to concrete operational scenarios.

Cloud CMDB Architecture

System Management Layer : Manages organizations, users, roles, and permissions, integrating with external identity sources.

CMDB Service Element Layer : Provides model, data, and operation management functions.

API Layer : Wraps service‑element functions into model‑management, item‑management, and operation‑management APIs.

Scenario Layer : Includes ETL (data extraction, transformation, loading) and visualization scenarios; extensible for custom use cases.

The platform also offers a GUI portal for administrators to maintain models and items.

An open‑source cloud CMDB project implementing dynamic model extension, APIs, baseline, comparison, ETL, and visualization is slated for its first release in July.

Interactive Q&A Highlights

Q1: The biggest cloud‑era challenge is the dynamic nature of configuration data, which quickly becomes stale if updated manually.

Q2: Large‑scale comparison is performed at the text level, detecting added, modified, or removed attributes and items.

Q3: Migrating an existing asset‑focused CMDB to a cloud‑native approach generally requires a rebuild.

Q4: Active discovery should be event‑driven rather than purely polling, integrating with provisioning workflows.

Q5: CMDB is essentially a database; ETL techniques resolve conflicts when ingesting data from multiple sources.

Q6: A model is the schema; a scenario is an application that consumes the data.

Q7: RESTful APIs are becoming the de‑facto standard for cloud CMDB services.

Q8: Cloud providers now offer configuration management services (e.g., AWS Config) that centralize resource metadata.

Q9: Beyond visualization, cloud CMDB supports real‑time configuration updates during VM provisioning.

Q10: Early value comes from scenario‑driven usage and high automation coverage of CI attributes.

Q11: In non‑cloud environments, data accuracy relies on post‑audit correction; in cloud environments, configuration changes are captured automatically, providing near‑real‑time snapshots.

Q12: Logical relationships are modeled as special CI attributes and must be supplied by automation tools.

Q13: Commercial solutions (BMC ADDM, IBM TADDM) exist for automated discovery; open‑source alternatives are limited.

Q14: For more details on Apache Kylin, see http://www.oschina.net/p/kylin-olap .