Project / configuration management

Zkybase CMDB

A configuration management database for applications, environments and deployments, built on a graph model.

Why a graph model

Configuration management involves many kinds of entities: regions, data centers, environments, farms, instance types, machine images, instances, applications, middleware, packages, deployments and more. Those entities are connected in many directions, which makes a rigid relational schema expensive to change.

Zkybase moved the backend to Neo4j, a graph database, with Spring Data Neo4j handling persistence. The goal was schema agility: the ability to experiment with different CMDB approaches without rewriting a data migration for every change.

The design notes cover both the domain model and the tradeoffs. Start with Why I am pretty excited about using Neo4j for a CMDB backend and Domain Modeling with Spring Data Neo4j.

Configuration management flow diagram — Configuration management flow, from the schema design notes.

The API comes first

One lesson from building CMDBs is to separate the user interface from the web service API. In the Java world, that means the API should be its own package or WAR file, with the UI as a separate client. The original note lists four reasons:

It keeps everything automatable. If the UI is just another client of the API, anything the UI can do can be automated.
It makes the API more robust. A UI change cannot accidentally break the API.
The UI and API can scale independently. Automation will eventually produce far more traffic than people do.
It facilitates testing. There are fewer UI interactions to account for.

Read the full note: When building a CMDB, separate the UI from the API.

Schemas and closed loops

The schema notes compare unconstrained and constrained schemas. The argument is that a useful configuration management schema should describe both the environment being managed and the infrastructure for managing that environment and its state.

Collecting the data is the other half. The closed loop approach connects configuration management data to deployment data so that the system keeps itself current, rather than depending on a periodic survey. The two notes that lay this out are How NOT to collect configuration management data and Closed loops: the secret to collecting configuration management data.

GitHub integration

Zkybase connected to GitHub so that application lists and other data could be sourced once and shared across development, test, release and operations. The integration used Spring Social GitHub for authorized access.

Read Zkybase/GitHub integration and Zkybase now supports authorized access to GitHub via Spring Social GitHub.

Build notes

These entries document the design and the work in progress. They are a record of the thinking, not a product manual.

Project status. Zkybase CMDB was an active work in progress in 2011 and 2012. The notes remain online as a record of the design work and the questions behind it.