Cloud Source Blog
In This HP Cloud Source Blog, HP Expert, Christian Verstraete will examine cloud computing challenges, discuss practical approaches to cloud computing and suggest realistic solutions.

Dissecting Cloud Functional Reference Architecture – Delivery Layer (Part 4)

Delivery 3.pngThis blog is the fourth part of the description of the delivery layer within the HP Cloud Functional Reference Architecture. Remember, the demand layer focused on the user, the delivery layer is focused on the service and its service elements. We first discussed how a service is provisioned, we then discussed how the service is accessed and options are changed and we finally discussed how to monitor the service. One question has not been addressed though. How do we design a service so the orchestration knows what to do when triggered by the demand layer?

 

Service offer management

Service Offer Management in the demand layer will describe what the service actually does in a language that is understandable by the user, so he can choose whether this is the service he needs to provision. The options, SLA and eventually the pricing are also described. If the service is part of a product bundle, as we described in the demand layer, that information is also made available to the user in the service catalog and the portal. However, service offer management does not define how the service is provisioned and what actions need to be taken to create, upgrade, manage and monitor the service the user requests. That is done by the service modeling and design function in the delivery layer. So, let’s take some time to discuss this in more detail.

 

Service modeling and design

One very important element to take into account is that to manage a service, one not only needs to have a workflow or automation script to provision the service; many other actions may have to be taken. Amongst them are:

  • Service option changes
  • Service de-provisioning
  • Service patching
  • Service upgrade
  • Service reconfiguration
  • Service failure management

For each of those, a workflow or automation script needs to be developed. That can be done most easily through the use of a graphic design tool, allowing the service designer to build the workflow including decision steps, branches, loops, etc. To run service instances, the service relies on resources. Those resources may be managed by a supply layer managed by the cloud platform or may be consumed from an external service provider. In both cases it is the service broker who interacts with the resource. However the service broker needs to know how that interaction takes place. We will come back to that.

 

The service modeling and design function uses the list of resources maintained in the service model repository. This list is maintained by the service broker for the resources included in the supply layer, and by a separate design function we will discuss later for external service providers. Resources from a supply layer link to a resource template in the resource catalog & repository of that layer.

 

The designer will drag and drop resources, describe how they need to be configured, trigger the installation of software, the changes of parameters, etc. CloudMaps, briefly mentioned in the demand blog entry highlighted earlier, can be used as starting points to build these workflows.

 

Standards that would facilitate portability of service designs between clouds are emerging.  OASIS TOSCA  (Topology and Orchestration Specification for Cloud Application) is probably one of the most interesting ones. EVE is an example of how this could be used in practice.

 

Services and service elements

In the introduction to this series, I described how a service can be developed by integrating multiple service elements.

Each service element has its own workflows. What the service designer must be able to do is to create a workflow that calls upon other workflows, recovering the results of the execution of those workflows. It must have the possibility to wait for the outcome or to trigger multiple workflows in parallel.

 

So, the workflow of a complex service typically calls upon the workflows of the service elements and then uses additional resources to integrate and isolate the service elements.

Ideally you want the graphic designer to keep track of which workflows are used by other workflows so that, when you do a change, you can check the implications.

 

Calling upon external services

If the resources are managed by a supply layer under the responsibility of the cloud platform, there is a one-to-one mapping between the resource as available in the designer and a resource template in the supply layer.

If an external service is intermediated or aggregated, before it can be used, it needs to be described in the service model repository. By the way, the external service may be an IaaS service on which the orchestrator will deploy software. How is that done?

 

First, remember that, if an external service is used, the service broker interacts with the demand layer of that external service. To be precise it will interact with the API services. So, for each action that needs to be performed by the service broker, the interaction with the external service needs to be described. For example, if the external service uses RESTFull APIs, each action will consist in an XML statement that is sent to the API. So, the resource description will include a description of the communication mechanism including the address required to access the service and what actually needs to be sent for each action that should take place. Actions can include amongst others:

  • User connection & authentication
  • Service provisioning
  • Service de-provisioning
  • Service option change
  • Service status
  • Service start
  • Service stop
  • Service suspend
  • Service SLA information request
  • Service billing/metering information request

The onboarding of a new service implies the development of these action workflows as I call them. Once defined, the external service is visible in the graphical design tool and can be used. In the service designer it is considered an available resource.

 

Conclusion

The delivery layer is really the place where the service comes together. This is where all actions associated with the lifecycle of the service and its service instances are automated. Hence the reason I took several blog entries to describe it.

 

In the next blog post we will look at the supply layer and how that supply layer actually manages the resources. 

Labels: cloud| CloudSource
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Christian is responsible for building services focused on advising clients in their move to cloud, particularly from a business process and ...


Follow Us
Top Kudoed Posts
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation