A History of CMDBs

Originally published on CloudQuery's Blog.

tl;dr

CMDBs were designed for older infrastructure management eras. Cloud computing introduced ephemeral resources, high-volume asset management, and multiple abstraction layers — requiring a fundamentally different CMDB approach.

40 Years of Trying to Track Infrastructure

Before the AI boom, cloud migration dominated technology discussions roughly two decades ago. Historically, companies operated physical infrastructure they owned outright or leased in colocation facilities. Beginning around 2006, vendors introduced computing services on-demand: S3, EC2, and later RDS, along with supporting infrastructure primitives like IAM and security groups.

These services were disaggregated into elastic, scalable components that companies adopted during the 2010s cloud transition. Previously, organizations managed servers, drives, racks, network interface cards, switches, routers, power systems, and cooling infrastructure — a complex but traceable landscape managed through specialized tools called CMDBs. Many 1990s companies transitioned from mainframes to distributed commodity hardware systems, requiring new management approaches.

What is a CMDB?

Configuration management databases emerged in the late 1980s and early 1990s to help organizations track computing assets and their settings. As companies accumulated numerous physical servers, storage systems, and networking equipment across data centers, management became increasingly difficult. Previously, teams relied on spreadsheets, paper records, or nothing structured at all.

Regulatory pressures and audit requirements intensified alongside infrastructure sprawl. ITIL frameworks, developed by UK government agencies, promoted standardized configuration management practices. Vendors including BMC, IBM Tivoli, and HP OpenView built solutions around this methodology.

Traditional CMDBs prioritized top-down governance and manual documentation, designed for data center environments. They emphasized accuracy through procedural discipline rather than real-time configuration monitoring or usage snapshots.

CMDBs are dead?

Cloud migration fundamentally disrupted CMDB relevance for several reasons:

Scale: Cloud platforms enabled dramatically increased resource consumption and architectural complexity
CI/CD: Configuration declared through code with near-instantaneous change evaluation eliminated static database maintenance
Shifting left: Developers gained infrastructure control through declarative tools like Terraform, creating resources without updating CMDBs

CMDBs grew stale because they prioritized process adherence over actual infrastructure reality.

CMDBs are back?

Second-generation CMDBs like ServiceNow and Flexera gained traction during the 2010s by integrating ITIL service management workflows, automated discovery capabilities, and compliance frameworks. They served organizations operating virtual machine fleets subject to regulatory requirements reasonably well.

By the late 2010s, cloud environments became increasingly complex: AWS alone offers thousands of SKUs, specialized vendors proliferated, and AI workloads introduced ephemeral, serverless, and managed resources creating sprawl.

Companies recognized the need for comprehensive environmental inventory without reverting to process-heavy legacy approaches. Modern cloud environments demanded transformation.

Cloud CMDBs are for modern cloud environments

Contemporary CMDBs function differently than predecessors — they operate as real-time cloud infrastructure graphs spanning entire environments. Modern cloud CMDBs fundamentally serve as data pipelines, automatically consuming thousands of cloud provider APIs and presenting normalized data through standard SQL interfaces for customer analysis and integration.

Modern cloud complexity presents significant challenges:

Continuous updates required due to ephemeral resources
Complex API interdependencies across multiple accounts and regions
Rate limiting constraints
Non-normalized, poorly documented data structures

Building proprietary modern CMDBs presents unexpected complexity.

The Modern Relevance

Amid AI enthusiasm, cloud sprawl, and platform engineering developments, CMDBs have become foundational infrastructure. Organizations require authoritative configuration and asset insights for governance, security, cost optimization, automation, and reporting purposes.

Legacy CMDBs may be obsolete, but their cloud-era successors represent dynamic, continuously updated infrastructure inventories rather than static databases. The concept wasn't fundamentally flawed — it was simply built for an outdated era. Process-centric burden has given way to real-time visibility.