Last November I started dissecting HP’s cloud functional reference architecture. I also described the specifics of cloud service portfolio management. I then reviewed the demand layer in two posts, the first one focusing on provisioning/de-provisioning, the second one on usage and reporting. Let’s continue the analysis by looking at the demand layer.
By now we have an order for a service (using our previous examples). The order is approved and in line with policies. The delivery layer will manage the provisioning/de-provisioning of that service, allow the user to use the service, and collect consumption, health, SLA, data of the resources used to deliver the service, etc., with the objective to deliver a service-oriented view.
Remember, when we started describing the functional reference architecture, we highlighted the concept that a service can consist of multiple service elements (aggregation). Where the demand layer maintains the relationship between the service and the user, the delivery layer maintains the relationship between the service and its service elements and identifies the supply layer or external service provider used by the service instance.
In this post we will focus on the provisioning of a service. In the next blog post I will discuss usage and reporting.
Request processing and activation
The order management function in the demand layer triggers the request for the processing and activation function to deliver the service requested by the user. With the request it will receive a number of parameters corresponding to choices made by the user when requesting the service or product.
First, the service template will be received from the service model repository and the conformance of the parameters will be checked. This cannot be done by the demand layer as the detailed information on how the service is structured is only available at this level.
Then the service identifier is assigned. That information is provided to the order management function and will allow the user to be reconciled with the right service instance once provisioned.
If the function is provided by the cloud platform, the request processing and activation function may check whether capacity is available to deliver the service. It is doing that by contacting the supply layer(s) through the service broker. However, at this point in time, the supply layer that will be invoked to deliver the service is not yet identified.
Lastly, the service instance lifecycle management function is invoked.
Service instance lifecycle management
This function is central to the provisioning of a service. It receives the request with all the parameters required for the initiation of the process. It works with the service broker, containing the actual “drivers” to interact with the supply layers and the external service providers. The service instance lifecycle management function focuses on the decomposition of the service in service elements and the orchestration of these elements and their isolation/interconnection. The service broker focuses on getting the supply layers and service providers performing the appropriate functions to deliver each service instance.
When receiving a request, the service instance lifecycle management function will extract the service blueprint from the service model repository. That blueprint describes:
- the structure of the service (its service elements and how they are interconnected)
- the service attributes (e.g. class of service parameters; instructions given to the service provider or supply layer to meet customer expectations)
- the policies associated with where the service elements can be provisionedfor this particular user (taking into account the user organization and role)
- the definition of the integration/isolation that needs to be established between the service elements
Multiple scenarios are possible:
- If the service is an intermediated service, the function will use the service broker to contact the service provider who will perform the action and return credentials and appropriate information. That information is stored in the service model repository. If requested, special security elements will be put in place to ensure a secure pipeline with the service provider and separation for the user. It links the provisioned instance to the service identifier.
- If the service is performed by one of the supply layers directly under the responsibility of the cloud platform, the function will use the service broker to interact with the appropriate supply layer, ensure the provisioning of all resources and orchestrate appropriate integration between the resources. It receives specific configuration information about the resources provisioned and stores that in the service model repository. It links the provisioned instance to the service identifier.
- If the service is an aggregated service, this function synchronizes the provisioning of all the components (as done in one of the previous two bullets, depending if the service is performed by a local supply layer or an external service provider) ensuring transactional atomicity. If one of the service elements fails in its provisioning, a roll-back mechanism de-provisions all other elements for example. It then orchestrates the appropriate integration/isolation between the service elements. It links all service elements to the service identifier.
In the demand layer we also talked about products and service bundles. That structure is specific to the demand layer. In the delivery layer they are seen as separate, not interconnected services, each of which is identified with its own service identifier.
Once the service (and all its service elements) has been provisioned, the request processing and activation function is notified of the fulfillment of the service request.
The service broker is truly complementary to the service instance lifecycle management function. It isolates that function from the intricacies of the multiple supply layers and service providers. It really serves as a meta-layer, and essentially performs two functions:
- Based on the information received from the service instance lifecycle management function, the service broker identifies which supply layer or service provider will actually be invoked to deliver the service/service element requested. It will base that definition on the information received and on predefined parameters provided either by the service modeling and design function or by governance. Decision criteria can vary greatly, going from the region in which the user is located to the actual load of a particular supply layer for example.
- It then translates the requests received from the service instance lifecycle management function into instructions that can be understood by the target supply layer/service provider. It receives information back once the provisioning action has been taken from the supply layer/service provider, and translates that information to a format understood by the remainder of the cloud platform.
In this entry we have focused on the provisioning of a service. But obviously, the user can request other actions associated with a provisioned service. (For example, increasing the memory or disk space provided, de-provisioning, backup, etc.) And the platform itself may for example migrate a running VM from one resource to another in case of self-healing, performance issues, etc. The service instance lifecycle management and the service broker function are intimately involved in both of those requests. That’s something we will describe in the next blog post.