In the year 2002, the idea of Configuration Management Database (CMDB) was promoted by ITIL V2. During that time, virtualization was non-existent in the enterprise environment. However, VMware was making its debut in the beta stage. What’s more, even Cloud was practically unheard of. This was the era of the monolithic application infrastructure of the client-server architecture. The fundamental concept behind Configuration Management Database was that the service is produced by Cloud Infrastructures (CIs). The IT infrastructure was almost static and it was important to know the impact of any change in a CI within the static infrastructure.
How is the XaaS world different?
XaaS is a collective term that stands for ‘X as a service’, where X can be anything and everything. This is a rapidly expanding model that developed from utility service. Eventually, it started getting applied to IT and non-IT services. XaaS is the essence of Cloud Computing and its most common examples include, Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS).
These are the new delivery models that warrant new approaches to service management. The infrastructure is virtualized/Cloud-based and very dynamic.
| Old World | XaaS World |
| Monolithic application infrastructure. | Cloud infrastructure. |
| Service is produced by CIs. | Service is composed by micro-services. |
| Technology management mindset with focus on system architecture and system integration. | Outcome management mindset with focus on service architecture and service integration. |
| CMDB is the center of ITSM world around which everything revolves. | Service catalog is the center of service management world around which everything revolves. |
| SLA, OLA, UC concepts for SLA management. | OLA and UC concepts are not applicable. |
Service Composition Database is the Upcoming Wave
The paradigms of the XaaS world lead towards the concept of Service Composition Database (SCDB), the equivalent of CMDB database in the ITIL world. CMDB and SCDB differ in the following ways:
| Configuration Management Database | Service Composition Database |
| CMDB is the database of CIs and their relationships that produce a service. | SCDB is the database of micro-services and their relationships with a service. |
| CI is a part of ICT Infrastructure that needs to be managed individually as well as collectively. | Micro-service is an independent service focussed on specific function/outcome exposed through API and needs to be managed individually. |
| CMDB deals with CI classes and CI attributes with relationship types for CI to CI relationship. | SCDB deals with micro-service classes and service properties, and here micro-service to micro-service relationships are not applicable here. |
| CMDB has n:n relationships between CIs. In multitier CI hierarchies, this will turn out to be very complex. | SCDB has a 1:n relation between services and micro-services. In multitier hierarchies, this will turn out to be relatively simple. |
Arrival of XSMDB
SCDB is needed in XaaS service management as much as CMDB database is needed in ITIL world”
This proves that SCDB is needed in XaaS service management as much as CMDB database is needed in ITIL world.
CMDB and SCDB are both needed to address different kinds of needs
A typical enterprise landscape is a hybrid, which includes classic IT and Cloud-based IT. Therefore, CMDB and SCDB are both needed to address different kinds of needs. With the rise of ‘As-a-Service’ model and Cloud adoption, the scope of Configuration Management Database would decline. Consequently, we bring in the concept of XaaS Service Management Database. XaaS Service Management Database comprises two parts:
- Service Composition Database (SCDB) – To support the management of applications designed with microservices architecture
- Configuration Management Database (CMDB)- To support the legacy monolithic application designed in client-server architecture
The structure of XSMDB would consist of the hybrid environment, which includes:
- XaaS model enabled by natively designed Cloud applications in containers in Cloud
- XaaS model enabled by natively designed Cloud applications in containers in enterprise private Cloud
- XaaS/traditional service supported by Cloud-enabled applications running on managed IaaS Cloud
- Legacy applications running in unmanaged IaaS Cloud
- Legacy applications in legacy infrastructure
When you drill down a service into microservices and further, you will have touch points with in-house infrastructure as well as Cloud. Thus, a drill down of SCDB will have a touchpoint with CMDB.
I believe that XSMDB should be formed with two distinctive database technologies. Traditional CMDB in Graph database that would eliminate the need for external service mapping tools. It should not include non-discoverable data (owner and supporter) would be a part of catalog and portfolio. On the other hand, SCDB should be built in NOSQL database and service properties derived from service architecture.
