Keeping the data center’s inventory or configuration management database (CMDB) up to date proves one of the more challenging tasks in data center management. Vendors from HPE, CA, and ServiceNow have all invested an untold amount of money in solving the challenge with products and tools.
CMDBs are the systems of record for the enterprise data center, but they can also prove a major stumbling block to managing a successful cloud implementation. Before undertaking any private cloud implementation, data center managers must first understand the health of their CMDB.
Orchestration and automation
Self-provisioning reduces the friction in delivering IT services. Self-provisioning is also one of the hallmarks of cloud computing. End-users leverage either a self-service portal or API to consume IT infrastructure and services. To enable self-provisioning, IT managers deploy automation and orchestration. After an end-user selects an IT service from a service catalog, orchestration tools coordinate the tasks required to implement the service. The mechanism for task execution consists of automation tasks.
SEE: Special report: The cloud v. data center decision (free PDF) (TechRepublic)
Why is the CMDB so important for orchestration and automation? The simple answer–the CMDB represents the “what” of automation and orchestration. The CMDB represents the inventory and configuration of existing and new configuration items (CI). Configuration items include simple things such as a physical server or a complex object such as an enterprise application.
If the CMDB isn’t accurate or up to date the best-case scenario defaults to the failure of an automation script. The worst-case scenario is a service-request resulting in a system outage or data corruption. An accurate CMDB reduces the risk of an adverse impact from automation.
Multiple sources of truth
Complex environments require extremely robust CMDB solutions. I’ve not worked for a webscale cloud provider, but I’d assume that the CMDB of a company like Amazon Web Services, Microsoft Azure, or Google Cloud consists of custom code and systems. The enterprise presents a unique challenge for a single system of record for the CMDB.
Most enterprise data centers designs don’t account for automation. Each infrastructure silo has one or more CMDB. For example, the server virtualization system deploys a CMDB to keep track of inventory and system movement. The same data center may have a CMDB for firewalls and yet another for data center switches and routers. Couple these four with CMDBs for enterprise applications and storage systems. Each one of these configuration sources must update the central CMDB. In turn, the central CMDB may need to update each of these independent inventories.
Anyone who has performed any real-time extract, transform, and load (ETL) processes between two systems understands the pain of maintaining state between CMDBs with completely different database schemas and architectures.
The way forward
IT service management is just one of many reasons I’m not a fan of private cloud in the non-tech enterprise. Even the most well-engineered systems break at scale. Data center managers still wanting to pursue private cloud must first tighten their CMDB technologies and processes.
The starting place is understanding the CMDB sources and the dependencies of CIs in-scope for orchestration. Once the dependencies are identified, engineers must work with orchestration and automation vendors to understand how potential products integrate with existing CMDBs. Take automation slowly, starting with simple tasks such as deploying virtual machines in test and development and gradually working up to non-critical production systems.
Depending on the size and complexity of the environment, be prepared for a long journey to the private cloud.