========================================================================================================================
README
Willie Wheeler (willie.wheeler@gmail.com)
Copyright 2011-2012 the original author or authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
========================================================================================================================
From a high level, Skybase is an open source configuration management database, or CMDB. As such its goal is to support
runbook automation, especially deployment and operations use cases.
Technically Skybase explores the use of Neo4j in building a configuration management database. We're trying to address a
few challenges we've seen building another CM system (one that's based upon a relational backend):
1) When the CMDB's scope is large (e.g. spanning multiple global data centers), the underlying schema becomes complex
and over time resists change. But we need to be able to change the schema as business requirements evolve (e.g., new
customers, new vendor relationships, etc.).
2) Corresponding to the schema complexity, the UI becomes pretty complex too. We end up having to invent new terms, or
assign very specific meanings to existing terms, like "application", "farm", "instance", "package", "environment",
"logical environment", "physical environment", etc.
3) Defining, viewing and navigating relationships in the UI requires significant database, service and UI development.
The thought is that we can use a generic data representation--a graph--to address these issues. For example, instead of
building custom tables, services and UI for individual entities and for entity navigation, we can use generic graph
operations to establish these. Adding a person to a team, say, is the same sort of operation as adding an instance to a
farm.