In my last blog entry, I described how a service was provisioned. Let’s now review how we use a provisioned service and how we change options for an already provisioned service.
A user demands to access a service instance that he or she has provisioned. The service instance is identified through the service identifier that was given to the service request by Request Processing and Activation during the provisioning process. Remember, the demand layer is centered on the user and the delivery layer around service instances. The service identifier, maintained against the user in the service repository, provides the link between the user and the service instance.
Order management will request service instance lifecycle management to prepare the service for the user. Three things can happen:
- If the service is delivered by the cloud platform: The service instance lifecycle management will request the service broker to reload the saved virtual machine in the appropriate supply layer. This will orchestrate the required security elements to ensure the user/service instance is shielded from other tenants.
- If the service is delivered by an external service provider: The service instance lifecycle management will recoup the credentials of the service instance maintained in the service model repository. Using these, it will request the external service provider make the service instance available. It will also orchestrate the appropriate security elements to ensure the appropriate level of multi-tenancy.
- If the service instance is for an aggregated service: The service instance lifecycle management will do one of the above two actions for each of the service elements. It will then orchestrate the appropriate integration and isolation between the service elements.
Once the service instance is available to use, the service instance lifecycle management will provide the order management function with the appropriate information so the user can access the service via the portal.
Let’s now imagine the user wants to change an option of an already provisioned service. To keep things simple, let’s assume he/she needs more memory or disk space. Once the demand layer has checked whether this is an acceptable request, order management triggers request processing and activation to perform the configuration change.
Request processing and activation will first obtain the configuration model (template) from the service model repository and then check whether the provided parameters are correct. If correct, service instance lifecycle management will be triggered and receive the service identifier.
Here again three things can happen in this situation:
- The service is provided by the cloud platform: Then the service broker is invoked to trigger the configuration change in the appropriate supply layer. If successful, information is returned, stored in the service model repository and the action is reported as successful to order management. In case of failure, a roll-back procedure is invoked and the failure is reported to order management.
- The service is provided by an external service provider (intermediation): Service instance lifecycle management will recoup the service instance credentials from the service model repository and will trigger the service broker to request the configuration change. The external service provider will report whether the activity completed successfully or not. If successful, the new situation is stored in the service model repository and the successful action is reported to order management. In case of failure, one can hope that the external service provider automatically performs the roll-back, but if that is not the case; the roll-back procedure should be initiated. The availability of that function will have to be checked when interfacing with the external service provider.
- The service consists of multiple service elements: The first thing service provisioning and activation has to do is to understand whether the requested configuration change affects one or multiple service elements. For each of the service elements, one of the above actions has to be performed. However, the operation can only be deemed successful when all the affected service elements have been changed successfully. If one of them fails, they will all have to be rolled-back to their original situation. For service elements provided by an external service provider, this may have to be triggered by service instance lifecycle management because the external service may have been reconfigured successfully and the failure may be elsewhere. Again, if the operation is performed successfully, the information is stored in the service model repository. The result of the operation is transferred to the order management function.
The user will find the result of the request through usage reporting in the demand layer.
During the lifecycle of a service instance, the resources running that service instance may have to be changed. This may be the result of a failure of a physical resource, a performance problem or a security breach. Such an event could be triggered by service monitoring. Depending on the implementation and the intelligence available in the supply layer, these actions may be fully handled within the supply layer, and be transparent to the delivery layer. In some situations there might be an issue by fully relying on such mechanisms because the supply layer does not have an understanding of the end-to-end service, Because of this lack of understanding it is not capable of judging the effect of (for example) the migration of a virtual machine to a different availability zone on the overall service performance.
If the change is initiated at delivery layer, it is handled by the service instance lifecycle management function. Policies may have to be provided to ensure appropriate action is taken if there is an operational change. To stick to the above example, a policy pointing to the fact that all resources associated with a specific service/service element have to be in the same availability zone. If one of the resources fails—forcing a virtual machine associated with the service/service element to migrate to another availability zone—service instance lifecycle management may initiate the migration of all other resources.
If an external service fails there may not be an alternative and in that case service monitoring will have to report the failure of delivery of the service to the user. For IaaS services, one would ideally want to keep the possibility to change IaaS provider. If feasible, this will imply Service Instance Lifecycle Management provisions a new service with the alternate service provider and re-installs the applications on the service. As in the previous blog entry, the interaction with the service provider is performed by the service broker. Everything is available to implement with this approach. Whether it is practical in the current status of cloud, where there is no IaaS standard in place, remains to be seen.
The Service Instance Lifecycle Management and the Service Broker function are central to the cloud platform. They orchestrate the resources, ensure the security and networking integration between the resources and service elements and they implement multi-tenancy. In the next blog post we will look at how they are configured and then address health management, service management, quality of service and service usage.