August 21, 2014 | Written by: Mike McGuire
Share this post:
A properly designed and utilized configuration management database (CMDB) provides a foundation for good IT service management. I’ve spoken to several clients who have asked (rightly so) about whether or not to use a CMDB with their cloud provider. They have even asked questions such as “Whose CMDB should my servers and services be described in?” These are great questions, but are often overlooked when creating solutions that integrate cloud services.
A CMDB provides an enterprise with information about its technology components, the interactions and dependencies of those components and its relation to technical and business services, providing greater visibility and control over an environment. The CMDB also facilitates greater benefits from other service management processes: for example, incident, problem and change.
So why, with a CMDB implemented in our existing enterprise, do we consider it no longer necessary for a cloud environment? If anything, the use of a CMDB becomes more important as our components start being spread out among our existing traditional IT environment, and potentially numerous cloud providers. Being able to effectively manage our hybrid services becomes more complex in this situation, not less.
This is partly because keeping the CMDB up to date becomes more challenging. CMDBs are populated today through a combination of manual input, automatic discovery and integration with automation tools. In order to keep a CMDB up to date with the rapid provisioning and de-provisioning of cloud services, there are several approaches that can be taken.
Given that one of the prime benefits of a cloud service is the ability to rapidly consume services, adding manual tasks into the mix should generally be avoided when possible. Therefore, find out if your cloud provider can supply events from its provisioning system that can be used to provide controlled updates to your CMDB. Alternatively, you might find out if they can provide a regular feed (even if it is daily). Granted, daily may be too slow for the rate of change for some cloud consumers, but I’d suggest that for a very large percentage of enterprise cloud customers, a daily feed is probably sufficient.
With the creation and deletion part of a configuration item (CI) lifecycle covered, you may then need to rely on your existing discovery tools to scan your cloud services. The next conversation to have with your cloud provider can then cover greater service management interaction—especially with regards to incident, problem and change.
In the future, as more and more services move to the cloud, our approach to service management will change further. But while we’re integrating with traditional IT environments we often need to integrate with existing service management practices.
What has been your experience with integrating cloud components into your CMDB? Leave me a comment below or on Twitter @MikeJMcGuire.