In the era of cloud computing and XaaS, the IT environment has changed dramatically. Is CMDB still a relevant solution?
The concept of Configuration Management Database (CMDB) was introduced and popularized by Information Technology Infrastructure Library (ITIL) V2 in 2002, and promoted by tool vendors during those early days. This was the time of client server computing, when the the cloud and even virtualization were practically non-existent. Those traditional ways of service management found some purpose and usefulness in CMDB, and the service management world was revolving around CMDB, which was the center of the Service Management universe.
During the first decade — and some time even after that — all organizations attempted to build CMDB but could not succeed because they underestimated the complexity and the importance of data maintenance, and practically all CMDB implementation became tool implementation. (Actually hijacked by tool vendors.)
In ITIL V3, CMDB was upgraded to CMS, and complexity was significantly increased, so it became even more difficult to realize ITIL CMS (it was a non-viable concept anyway — refer my book on this subject). Around this time, virtualization was very well adopted in all organizations. However, the virtualization was merely the replacement of physical machine with static virtual machine, therefore the CMDB remained useful.
In the era of cloud computing and XaaS, the IT environment has changed dramatically. Instead of CMDB, service catalog has become the center of universe, and the computing infrastructure has become extremely dynamic. Traditional ways of server management, system management, and network management have absolutely become irrelevant because now you are buying infrastructure, platform or software as a service, not as individual components that need to be managed by you.
Contemporary IT environment includes:
- Legacy environment for legacy client server business application
- Multiple clouds (Amazon, Azure, AWS)
- ERP systems largely SAP
- Virtualized environment for all other purposes.
The Virtual platform produces a new class of dynamic data that requires defining and capturing additional attributes for these CI’s. In virtual environments, a new set of relationships between hosts, hypervisors, guests, virtual networks, and virtual storage are created. Traditional CMDBs are not designed to handle these kinds of relationships. The lifecycle of the data is comparatively shorter as new information is created at a very rapid rate, and the typical data update process and frequency for updates in traditional CMDB implementations are unable to handle this. We believe that virtual environments are managed by modern tools (like vRealize), and maintain OMDB (Operation management database — a super set of CMDB specifically for the virtual environment). Therefore, a separate CMDB is not warranted for virtual environment. Similarly, ERP landscape like SAP does maintain its own database like LMDB (Landscape Management Database). There is no point in making external CMDB for SAP environment.
CMDB will still be relevant for the legacy environment with client server business application, but this is rapidly shrinking and therefore, CMDB is also approaching irrelevance. The image below explains the old school approach to service management vs. the new school, where RFC and CMDB are non-existent.
In the 21st Century Enterprise, we feel that the more that Infrastructure are being deployed in a Model Driven/Blueprinted approach, the larger the gap between Design time and runtime, and the greater need for an Operational Database (OMDB). The OMBD is based on the current state of the environment like a Navigation Map, and would become the source of Operational Truth. The CMDB, alternatively, would become the Ground Truth in terms of having the Surveyor Map. We see the CMDB, in true sense, a Graph Model that would store the Service Map Information across a Hybrid Enterprise; and we see the OMDB being evolved, using extensive Machine Learning and Graph Algorithms (tools like Moogsoft) to be able to process real-time service models from various sources — and be continuously referencing the Service Map for the greater benefit of the Enterprise. We see Asset Management being a completely independent data model, which shouldn’t get mixed up with CMDB, causing more confusion. The Open Group IT4IT Forum is making a really good effort to get an open ecosystem and a prescriptive model for implementing IT Value Chains.
A Case For a Graph Database for Next Gen CMDB
elational database management systems (RDBMSs) cannot model or store data and its relationships without complexity, and performance degrades with the number and levels of data relationships and data size. What’s more, adding new types of data and data relationships requires schema redesign that increases time to market. For these reasons, RDBMSs are inappropriate when data relationships are valuable in real time. Having discussed the lacunae of a relational DB, we want to present a case for suitability of a Graph Database for building the CMDB.
Graphs are used to model many types of relations and processes in almost all genres in life including physical, biological, social and information systems. Especially in information systems, graphs are used to represent networks of communication, data organization, the flow of data or any other kind of information. A well understood example is a website graph representing the link structure of a website where the vertices represent web pages, and directed edges represent links from one page to another. If you are storing the information in tabular form and viewing the information in graphical form then you need to add an additional layer of processing to create the views. Why not store the information directly in the form of a graph and have a native view? That is what a Graph Database can do.
The importance and the need for visualization in a CMDB are very well understood. It improves the usability of the CMDB significantly. CMDB tools now add a visualization layer, but in many cases, charge extra for the feature. A graph database makes it simple and saves potential costs.
Graph database is a NOSQL (Not Only SQL) database, but not all NOSQL databases are graph databases. NOSQL is a very wide category for a group of persistence solutions which don’t follow the relational data model, and who don’t use SQL as the query language.
NOSQL databases can be categorized according to their data model into the following four categories:
- Key value stores
- BigTable implementations
- Document stores
- Graph databases
A graph database is a database that uses a graph structure with nodes, edges and properties to represent and store information. We always want to see the CI and their relationships in graphical form, and this is exactly how it is natively stored in a graph database. Therefore a graph databases, by design, are the best medium to build a CMDB on.
For the purpose of illustration, depicted below is the view of a CI in a graph database. This is a straightforward view of discovery via Nmap (“Network Mapper” is a free and open source, or licensed, utility for network discovery) and Neo4J — a graph database.
Additionally, Graph databases are designed in a more event driven fashion and are massively scalable by design, which can be leveraged to address the high rate of change of CI data/attributes/relationships that are dynamic in next-gen IT operations.