With a few exceptions, discussions around private clouds do not include IT Infrastructure Libraries (ITILs), configuration management databases (CMDBs) and service catalogs, but that is quickly changing. Steve
A service catalog and a CMDB should be complementary.
Typically, private cloud equals virtualization plus automation plus self-service. A private cloud with automated services via a self-service portal allows users to request servers without worrying about the virtual server configuration, the operating system or the software.
Others may want to be more specific; a staffer ordering an Exchange mail server might want to run it on Windows Server 2008 with 4 CPUs and 8 GB of memory, along with various security requirements. Regardless, these two requests are made with automated services and self-service user portals, features of real private clouds.
But what effect do these types of requests have on IT organizations? The rapidity of change due to automation and self-service in private cloud environments requires a more efficient approach to configuration management and change management -- processes that live inside the IT organization. IT organizations, in turn, have ITIL and tools like service catalogs and CMDBs available to improve efficiency.
What are ITILs, CMDBs, and service catalogs, and where do they intersect with private clouds? First, a few definitions and descriptions:
- The ITIL is a process framework of more than 20 processes. It was created by the UK government in the early 1990s to provide control and structure over IT infrastructure and to provide a set of best practices or recommendations for implementing service-oriented processes within an IT organization.
- A CMDB allows an IT organization to track and manage all hardware and software assets comprising their network and manage the location and configuration of each asset as well as the dependencies and relationships between assets. The CMDB is focused on systems, assets, CIs, and their relationships. It is the source of record for IT systems and assets and supports key ITIL processes such as configuration management and change management.
- A service catalog contains a list of services being automated and available via a self-service user portal. It is the source of record for the services that IT offers to its internal users. In the context of a private cloud, a service catalog is the self-server user portal that provides a list of automated services available for use with the private cloud. Generally, a service catalog contains the name, description, cost information, etc. for a service.
EMC, for example, is deploying a CMDB in its efforts to build a private cloud. Its CMDB is viewed as a key piece of its private cloud software architecture: all of EMC's private cloud planning, discovery, control, monitoring, and audit flows through its CMDB. Its CMDB contains:
- The private cloud services provided by IT to customers (Note: other enterprises articulate private cloud services via a service catalog. This is discussed below.)
- Configuration items (CIs), which are any components within an IT infrastructure, that can be managed to deliver a set of services (contained in the service catalog) from the private cloud.
Other companies such as Concur also have ITIL-based CMDB implementations underway. Concur views the CMDB as a part of a strong architectural foundation for its private cloud.
Ideally, you need to separate CMDB services from private cloud automated services. When Suncorp, one of Australia's leading financial services organizations, began planning and strategizing for the creation of its private cloud, it created a service-based operating model and a service catalog.
Some vendors weigh in on the side of service catalogs, stating that a well-designed service catalog is an essential ingredient of either private or hybrid cloud computing. The argument is that service catalogs are necessary for enterprises to reap the full benefits of cloud computing: users must be able to request the private cloud services they need, and IT must respond quickly to the requests.
The differences between CMDBs and service catalogs
What are the differences between a CMDB and a service catalog? They both deal with services, but at different levels and for different audiences within an enterprise.
In the context of a private cloud, a service catalog is used by customers. CMDBs, however, are typically used by change managers, configuration managers, and operations teams in IT organizations. When a user needs to provision a new Web server, he would use the service catalog of automated services for the private cloud. When an IT manager wants to view the status of various CIs, then he would use services provided by the CMDB. Service catalogs are user-centric and CMDBs are IT-centric .
Ideally, private clouds include an integrated CMDB and service catalog. For example, when a specific change affects a CI, the impact of this change can be reflected in how it changes things like service-level agreements (SLAs). For example, if you have used the service catalog to provision virtual servers and a change in physical servers impact the number of CPUs available for said virtual servers, then this impact would be reflected via the service catalog.
We have argued that a CMDB and service catalog are important components of private clouds that support automated services with a self-service portal.There are some that believe, however, that you do not need a CMDB, only a service catalog.
Service catalogs are user-centric and CMDBs are IT-centric.
If an enterprise already has a CMDB and a service catalog, then it may be in good shape private cloud-wise. If you have only a CMDB, then you can work through the appropriate services in the CMDB to more easily provide the private cloud-specific automated services for your existing, or to be created, service catalog. If you are using IT service management/change tools to help deploy your CMDB, then using services in the CMDB to help populate the service catalog can be easier. Some suggest providing the private cloud-specific automated services via the CMDB, but we do not recommend that approach.
If you have only a service catalog, then it can be used to place a focus on the services provided by a CMDB. We do not totally agree with this top-down approach, however, because IT organizations are interested in CMDB services that do not derive from service catalog services. Do not expect to use this top-down approach to fully populate the CMDB or to create all of the services required at the CMDB level.
Starting from scratch with a CMDB or service catalog
If you are starting from the beginning with a CMDB and a service catalog, then how should you proceed? As you might expect, there are several options. A service catalog and a CMDB should be complementary, and a company's service catalog should publish available IT and business services to end-user customers. These services should be built on the CIs and IT assets tracked in the CMDB. They are comprised of interrelated CIs.
Baldree, Bhupal, and Widen provide a good discussion on how to approach implementing a CMDB and a service catalog base on the following three options:
- Implement the CMDB and then the service catalog.
- Implement the service catalog and then the CMDB.
- Implement both together.
The preferred approach depends on where you are with respect to planning and implementing your private cloud. If you have already started implementing a private cloud without either a CMDB or service catalog, then implement the service catalog first and use it to drive the implementation of the CMDB. This should speed up the implementation of the CMDB, but building a CMDB can be a daunting task and generally takes a minimum of two or three years.
ITIL, CMDBs and service catalogs were in use before private clouds became a common topic. It is likely that tweaks to existing CMDBs and service catalogs would have to be made to satisfy some of the private cloud-related automated services. If you have neither a CMDB nor a service catalog available when you begin the implementation of a private cloud, then you are in for a lot of work.
BILL CLAYBROOK'S BIO:
Bill Claybrook is a marketing research analyst with over 30 years of experience in the computer
industry, with the last 10 years in Linux and open source. From 1999 to 2004, Bill was Research
Director, Linux and Open Source, at Aberdeen Group in Boston. He resigned his competitive
analyst/Linux product marketing position at Novell in June 2009 after spending over four and a half
years at the company. He is now President of New River Marketing Research in Concord, Mass. He
holds a Ph.D. in Computer Science.
This was first published in August 2010