The Strategic Service Broker and the Cloud Architecture

Lately we worked with a small team on the development of HP’s cloud functional reference architecture, with the objective to ensure it supported the service broker vision I described in a previous post. Indeed ensuring both aggregation and burst capabilities require the architecture to be structured in a specific way. We also believe there is need for a cloud platform on which IaaS, PaaS and SaaS services can be delivered. The architecture we worked looked at the functional blocks required to build this platform. All XaaS services are running within the cloud platform. This approach allows service providers to propose a mix of services, going from infrastructure to software.

Early on we realized there are a number of IT functions that are specific to cloud, or need to have specific functionality in a cloud environment, and others that are applicable to both cloud and non-cloud environments. For that reason we separated the functions in the ones that are specific for cloud and the others. Let me give an example, identity management. Any enterprise needs identity management, but in a cloud environment a lot more information will have to be attached to the user identity than in a traditional environment. Certificates, encryption code to access specific virtual machines used by the user are a couple examples. Service Desk on the other hand is no different whether it supports a cloud environment, a traditional environment or both. Such functions we called enterprise functionalities and located them in the blue plane on the diagram. The cloud specific functions are in the green plane.

Architecture.pngWe then divided the cloud specific functionality into three main groups.

  • First, the ones interacting with the user, whether a physical user or applications through API’s. We called that layer the demand layer.
  • Second, the ones responsible for the provisioning, configuration and activation of the service and its service components. We called this layer the delivery layer.
  • Third, the ones interacting with the resources that will ultimately have to deliver the service to the user. We called this layer the supply layer.

When a user logs on to the system (through the portal) he will have to provide credentials which are checked against the identity management function. The user’s role is identified and the services he is eligible for will be shown to him. The service descriptions are maintained in the service catalog. He makes his choice and requests the service. When all approvals are obtained, the order management function initiates the service provisioning.

If a service is provisioned through an external service provider (aggregation), the demand layer will expose the service to the user in the same way as any other service. In other words, the service will be configured in the service catalog. But when the user requests an instance of the service, the order management function will not invoke the delivery layer, but rather the demand layer from the service provider who, after checking the validity of the request would in turn contact its delivery layer. This function will be invoked through the service provider’s service access API’s. Those API’s will also be responsible for sharing billing and service level information.

If the service is provisioned by the cloud environment, the order management function will trigger the service and application configuration and activation function in the delivery layer.

As we mentioned, the delivery layer takes care of orchestrating all service components required to deliver the service. The service will only be available when all components have been provisioned properly. The delivery layer will contact the supply layer for the availability of the required resources for each service component. If there are not enough resources available, the delivery layer may decide to shift some workloads to an external service provider (burst). Which workloads are actually moving depends on the policies that have been defined. These can take into account the sensitivity of the data, the strategic nature of the workload etc. It may be that already provisioned workloads are moved to make space for the requested service as this one has to run in the private cloud for example.

In the case of burst, the delivery layer will contact the demand layer of the supplier to request the resources required by the workload. After checking the validity of the request, the supplier demand layer will contact its delivery layer to provide the appropriate resources. And we are back at the same point.

The supply layer has the responsibility of the provisioning of each of the required resources. These resources include not only servers, storage and networking but also application licenses, IP addresses etc. The orchestration happens in the delivery layer. The supply layer manages the interaction with the infrastructure and the workload across the resources. As companies look at making their data centers more efficient from an energy perspective, this function is becoming increasingly important. Indeed, through a dynamic workload management function, the supply layer may balance the workloads across the resources to ensure optimal use of energy and minimal need for cooling for example.

In the infrastructure we included the network. We were not only thinking at the data center network and its converged infrastructure, but also at the physical network with the point of consumption. For some services, particularly heavy content driven ones, managing workloads in the data center is not enough. It is the combined “supply chain” between the data center and the network that needs to be optimized to ensure an appropriate quality of experience. Decisions of which data center to put the workload in may be affected by the availability of bandwidth and latency aspects.

Obviously we went into more detail in developing this architecture; this is just a short overview. If you are interested in more details, let me know and I’ll walk you through it.

 

Related Links

Take a look at the video : Data center of the Future, today

Instant-On Enterprise

HP Cloud Solutions

 

Labels: Cloud| cloud advisor
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
Featured


Follow Us
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.