Cloud computing is traveling along the hype cycle quickly, cloud technologies are maturing, and cloud adoption is accelerating on a global scale. Most IT managers now agree that cloud computing is both a new generation of system architecture and also a new form of IT service provider/user partnership. Hybrid cloud solutions also successfully link in-house systems with the new provider-based “as a service” offerings.
One consequence has been an increased focus on systems management, especially the automation of change and configuration management processes. Hybrid clouds and multi-cloud systems are creating additional requirements for management integration. As a starting point, cloud customers need a good record of all the resources/services being used, the service levels desired and being achieved, and what is being moved, added or changed (especially with self-service provisioning and automated scaling). Providers must also manage and optimize their infrastructures across multiple tenants.
An accurate, well-maintained Configuration Management Database (CMDB) can help to reduce the risks of the cloud transition and support day-to-day operations and maintenance processes. A Google search of “CMDB and cloud computing” illustrates how many different views of the role and importance of a CMDB there can be. These differences, however, are as much related to the acceptance of ITIL/ITSM as a framework for cloud management as they are to the intrinsic value of a CMDB.
A CMDB is a database of a assets/resources, which are called Configuration Items, or CI’s in ITIL-speak. The CMDB can include many different types of object including stakeholders, contracts, documentation, devices and services. While the CMDB must contain all relevant details of the CI’s themselves, it is becoming increasingly important to also track the relationships among the CI’s.
The ITIL/ITSM CMDB should not be confused with the configuration management concepts used in the DevOps movement, which is more focused on software delivery, or systems engineering. Examples of configuration tools for building systems include Puppet (open source software for configuring UNIX and Windows systems) and chef. Software deployment, configuration control and orchestration are also key to service delivery automation, with Ansible and Salt being two current examples.
A CMDB for cloud computing will be even more valuable when microservice and container architectures are deployed in complex, dynamic, ever-changing cloud configurations. Documenting the relationships among CI’s is paramount when performing any type of compliance assessment, threat impact assessment, or troubleshooting efforts.
IT managers need a complete view of ALL their managed elements and how they interact – it doesn’t matter who owns them, where they are, whether they are virtual or physical, or how permanent they may be.
To meet these requirements, the most obvious technology is a graph database. One example of a graph-based CMDB that is well-suited for cloud computing environments is available from LightMesh Inc. of Toronto. From their website, we learn:
“LightMesh gives you the tools to easily design public and private cloud integrations, giving your entire organization visibility into what cloud services you rely on and how they are implemented. Whether it’s a single VM instance to get a new initiative to market or a full VPDC spanning multiple availability regions, LightMesh helps you quickly generate a fully documented design that can be instantly used by operations and support.
Beyond Cloud Design, LightMesh offers fully automated cloud provisioning for API driven cloud providers. With a completed design you are just one click away from a fully spun up implementation. This helps IT organizations improve their agility and customer responsiveness while maintaining control and supervision of the environments that they are responsible for.”
LightMesh’s CMDB is available as a cloud-based service or as a private on-premises implementation.
Various deployment scenarios for a CMDB can be considered. For example:
- A single CMDB with a management portal that could discover CI information from all sites and systems may be available from your cloud provider or a third party (i.e., CMDB as a Service);
- An existing in-house CMDB could be expanded to collect and consolidate management information from the cloud provider (or multiple providers) via standard or custom APIs; or
- In-house and cloud CMDBs could be linked together to create a single authoritative view of all resources wherever they reside. This is analogous to the concepts and goals that are being promoted with Master Data Management.
The “five essential characteristics” of cloud computing described in ISO/IEC 17788-2014 and by the NIST would be supported by using a CMDB as part of the solution:
- On-demand self-service – The CMDB can track services, service qualities and service components and be used to populate a service catalogue and support self-service provisioning.
- Broad network access – A CMDB would include network, security and linkage information that can be used for compatibility, accessibility, security and privacy, and could also interface to identity and access control systems.
- Resource pooling – The CMDB could document resource pool contents, capacity allocations, and assignments to tenants. Dynamic changes in user resources should be tracked both by the provider (as part of multi-tenant operations) and by each tenant for audit, accounting and performance planning.
- Rapid elasticity. Services that are elastically provisioned and released, in some cases automatically, should be tracked using a high performance, realtime CMDB.
- Measured service. Cloud systems automatically control and optimize resource use by leveraging a metering capability. Resource usage can be monitored, controlled, and reported using a CMDB that has discovery and monitoring functions, thereby providing transparency for both the provider and the consumer of the service.
The CMDB was originally conceived as a simple repository of long-lasting and essentially static configuration information, which basically reflected the state of the systems of the day. Cloud computing has changed the “ballgame” with systems that are agile, dynamic, continuously evolving, and multi-provider. The CMDB needs to be the nexus of information for a wide range of cloud-oriented configurations.
This is what I think. What do you think?
