A cloud platform: the base for all cloud services

[#1]

I often see cloud architectures having three layers, the first one labeled IaaS, the second one PaaS and the third one SaaS. Even the NIST architecture has this embedded in their model. There seems to be an understanding that you need infrastructure services to deliver platform services and then platform services to deliver software as a service. I disagree with that approach. Salesforce.com started with SaaS, without delivering IaaS or PaaS services. Yes, today they have PaaS services, but they came much later.

So, in my mind, you require a cloud platform that delivers the functionality that is common for IaaS, PaaS and SaaS services. Using that platform, develop the services you want to deliver, whether they are infrastructure, platform, software or any combination of those.

This cloud platform needs to integrate into your overall IT environment. So, it needs to function with the overall management, governance, business management and security frameworks you have in your IT department. Functions such as identity management should cover both the cloud platform and the legacy environment, that way you can manage your users from one place. That integration is missing in most cloud implementations as if cloud was something that is totally isolated from the remainder of the IT environment.

The real question is about the functionality that is covered by the cloud platform. In my mind there are three key sets of functionalities included in a cloud platform. IT Candor actually developed a good representation of the HP Cloud Functional Reference Architecture. Here are the three layers of the cloud platform in a little more detail:

• User Interaction—The user accesses the cloud environment through a portal. After being authenticated, a role is assigned to him by the identity management system. In accordance with that role, the services he is allowed to provision are shown to him. The description of these services is found in the service catalog. Some of those services are delivered by the cloud platform itself, while others may be provided by external clouds (aggregation). Some services may be very simple (e.g. A virtual machine), while others may be extremely complex—as described in my previous blog entry about cloud services. The user can choose a service and request its provisioning (potentially after an approval process has been executed). Once the user has provisioned services, he will use the same portal to access the provisioned services. The service repository keeps track of the services provisioned by the user and their status. When the user no longer needs the service, he uses the same portal to de-provision the service.  The user can also receive information on what services he uses, what service levels he has received, and if the service is charged for, the billing information. So all interactions with the cloud are managed through this layer, we typically call the demand layer. One element to note is that, in line with the hybrid delivery approach discussed previously, this cloud can also be accessed automatically from another cloud. For this reason, the demand layer exposes a number of API’s allowing the user functions to be accessed programmatically.
   
• Service Orchestration— As the user requests the provisioning of a service, the provisioning of all service elements has to be performed. The service model repository contains the detailed description of the service and all its service components. As the user is not interested in receiving 50 percent of the service, it’s important for the service orchestration first to check whether all service elements can be provisioned prior to do so. That’s the first task of this layer. Obviously, this is quite simple in case of the provisioning of a virtual machine, but in case of the provisioning of a project collaboration environment, as discussed in my previous blog entry (cloud services), it may be quite complex. The second task consists in provisioning all the service elements. If the service is provided by an external cloud service (aggregation) the provisioning of the service is initiated in the external cloud. If the service is provisioned within the cloud platform, resources are allocated by the third layer. Once the resources have been allocated, the appropriate software packages are installed (if necessary) and configured to deliver the service. The links between the service elements, the vLAN’s etc. are configured to ensure a proper working of the service. When the user de-provisions the service, all VM’s required to deliver the service instance are shut down and the resources are returned to the pool of available resources. This layer also monitors the health of the service as well as the consumption of all service elements to provide the required information to allow the billing to be performed (if required). We call this layer the delivery layer as it delivers the end-to-end service.
  
  
• Resource Operations. The delivery of services requires resources. These resources include servers, storage, networking but also vLAN’s, firewalls, license keys, IP addresses etc. These resources need to be managed. Now, there can be multiple pools of resources within one cloud platform. A data center may be divided in multiple zones or there may be multiple datacenters. The cloud may manage the datacenter and the network to the user, and both may be managed separately. We call this layer the supply layer as it provides the resources to the service. There may be one or multiple supply layers, each with one or multiple resource pools. Each supply layer will optimize all resources across the resource pools. So, if one set of resources are IT infrastructure focuses, while another are network focused, we may want to implement two supply layers. If the service has one datacenter in North America and one in Europe, two supply layers may be used. On the other hand, if the service uses two datacenters located nearby and closely coupled with each other, both may be managed by one supply layer. At request of the delivery layer, the supply layer will check for the availability of resources and reserve them. It will then provision the resources (using virtual images that are in the resource pool catalog and repository), test them and make them available to the delivery layer for final configuration. The supply layer will also release the resources when the service is de-provisioned. During operations, the supply layer checks the health of the resources and meters resource consumption. It is also the supply layer that manages the workloads, decides where to locate a particular workload and potentially relocate workloads for load balancing or hardware failure reasons. 

Using the three layers described here, the cloud service provider can now configure a variety of services, being it simple infrastructure services or complex ones such as the R&D project collaboration environment. To do that, he will design how a service is configured in the delivery layer. He will call upon service elements he may have designed earlier, to create the service he wants to offer. In that process he will refer to resource templates that describe the resource types he needs. If the appropriate type is not available he may create new resource templates in the supply layer. When all this is done, he makes the service visible by describing the offer in the service catalog, and that is done in the demand layer.

But provisioning the service is simple; managing the service lifecycle has many other aspects to it. Indeed, an existing service may need to be reconfigured; a virtual machine may be patched or upgraded to a new version of the operating system or the application software. The orchestration function in the delivery layer handles this, triggered by the responsible of the service.

A cloud platform is a key element in the set-up of a cloud, but it is often forgotten. Depending on the type of cloud implemented, more or less functionality is required. Make sure you can set-up all the functions you need and make them available sooner rather than later. Don’t just think about what you need now, as this may limit you drastically in the future. I don’t want you to be one of these CIO’s suddenly discovering they can provision a VM, but are unable to orchestrate an application on top of it.

When HP developed the HP Cloud Functional Reference Architecture, we painfully went through all the details to ensure we had a complete set of functionality available to us to address the common cloud requirements we were seeing. Feel free to comment and let me know if you wish more details.

[#2]

Hey! Nice blog, I am so impressed with your blog. Keep it up. Hope to learn more from you.