Cloud services catalogs are a centralized resource to both discover and leverage private or public cloud services. An outgrowth of service registries and repositories from the days of SOA (Service-Oriented Architecture), this new and improved technology provides a single gateway for service access for applications and end users. Keep in mind that services are APIs, and APIs are services, in the world of cloud computing.

Services are, in essence, access points to core cloud services. These services include infrastructure services, such as storage and compute, or business applications services, such as gathering a credit rating. We leverage these services, cloud or not, public or private, to create business solutions that use more of an assembly rather than a development process.

Enterprises that lack cloud services catalogs miss out on the advantages of centralized control, centralized discovery, and centralized access. These services soon become distributed and unmanageable.  Not surprisingly, effective governance (including the use of cloud management platforms [CMPs]) becomes the single most important reason that cloud services catalogs exist for enterprises. Indeed, services catalogs come as features within these technologies.

As we move to multi-cloud types of architectures that leverage a mixture of public and private clouds, IT quickly becomes the broker of cloud services. Their services catalogs are typically bound to CMPs, or other resource governance and/or service management infrastructure that leverage these catalogs as the single version of the truth, and include:

• What services are available, and what these services do.
• Security and access polices that determine who can leverage what services, and for what reasons.
• The ability to track dependencies, such as what services are made up of other services.
• The ability to link with core DevOps processes and tools, including continuous integration and continuous delivery.
• The ability to track the changes made to services over time, including those that exist in the public cloud and locally within the enterprise

The cloud services catalog, in most instances I see, is the key to automated provisioning and deployment because it provides a single point of reference for the cloud services. The services catalog defines, in detail, all services—public and private—available to business users or developers.

The services catalog must be kept scrupulously up to date so that users always have a clear picture of the available services and resources. What’s more, the services under management need to be related directly to the needs of the business.

The services catalog of today differs from services catalogs found in the initial days of SOA (Service-Oriented Architecture) in that the underlying technology details are usually not provided to the users. The rationale is that keeping the implementation details behind the catalog, as it were, provides IT with the maximum flexibility to obtain resources from either private or public clouds.

This structure supports the notion of multi-cloud deployments, which seem to be the current direction in the industry, and provides the ability to monitor the use and cost of the services, which allows IT to better manage SLAs for the entire enterprise.

The value of automation

First we need an understanding and inventory of existing services within existing enterprise systems, and newer private and public clouds, or other services that should be identified and listed in the catalog. Next, it’s time to understand how the use of these services can be automated. The automation is a part of core governance systems that can be put in place to enforce pre-defined policies, or other procedures, as to how the services should be provisioned, managed, and utilized, by end users or developers.

There are two paths to consider here: First is resource governance (including CMPs), and the second is service governance.

Resource governance deals with collections of services or resources that exist within major entities, and is also known as macro governance. An example of resource governance would be the ability to allocate groups of storage services that exist in a private cloud environment. Newer cloud management platforms provide resource governance capabilities, including the ability to provision, manage, and de-provision any number of IT assets out of public or private clouds, or traditional systems.

Service governance is the same as resource governance, but at a more fine-grained level, and is otherwise known as micro governance. Instead of dealing with larger collections of services, such as resources, we’re dealing with the individual services themselves. (See Figure 1.) An example would be the service to place an object onto a cloud-based storage server, or a service that provides the ability to check a stock quote.

Figure 1: When considering service governance, polices entered into the “Repository” (a.k.a., services catalog) are controlled through the use of policies that are placed around the services.

Operation of the services catalog must take the use of automation into consideration. This is the step where you plan to automate the use of cloud services, which includes binding them into workflows or applications. The use of automation also covers the application of polices that define access to services, as well as track dependencies.

Operations planning should take the use of services and the services catalog into consideration. This means understanding and dealing with performance and access management issues, as well as having the ability to manage resources using provisioning capabilities to control which resources are provisioned and for what purpose, including cloud services in the catalog.

Creating the initial services catalog means that we list all the relevant services from the candidate services list which are thus selected as services for our problem domain. Moreover, they are decomposed and ordered so all services that are dependent upon other services are understood from the highest level to the lowest. Again, these services can be private or public cloud, or services found in traditional systems.

As you move toward construction of a cloud services catalog, you need to define the value that this concept and its supporting technology bring to the organization. You do this by defining the metrics for success, including service reuse, enhanced business agility, and quicker time-to-market. While these are all valuable concepts, the amount of value they bring depends upon the characteristics of your organization. The results of the step process outlined above will tell you how much value the cloud services catalog actually brings to your business.

The use of cloud services is no longer optional for your business; it has become a fundamental way to approach the creation and deployment of automated business solutions. The use of cloud services allows us to take an assembly approach to building applications, rather than always building these applications from scratch. This provides both speed and agility to the business, and thus provides the value and ROI.

Bottom line: It’s not if service catalogs are in your future, it’s when.