Cloud service level agreements (SLAs): What you don’t know can hurt you


Note: This week through Jan. 4, we are posting the top 10 posts of 2012. This post is #6 and was originally published May 22, 2012. 

Everyone is talking about moving some of their services to the cloud. However, who is responsible for the management of the services that will operate in a cloud environment?  Who is responsible for identifying the elements of the agreement? What type of agreement should be in place? These are all questions that should be asked and understood before moving a service to the cloud.

The Cloud Standards Customer Council (CSCC) has developed and published a document called the Practical Guide to Service Level Agreements (SLA).  The guide is a straightforward document that takes a reader through the steps to construct a cloud SLA that meets the cloud consumer’s business requirements.

Let’s dig a little deeper into what we mean.

SLAs are important to clearly set expectations for the service levels between the cloud consumer (buyer) and the cloud provider (seller). Because cloud is an emerging technology, the cloud providers have developed their own SLAs, which are consistent with ensuring that the provider is protected.  Although neither the consumer nor the provider wants problems, issues will occur and it will be the SLA that will be used to guide the resolution process.

Remember, the services deployed into the cloud are really an extension of the enterprise. The same discipline for managing the internal services should be applied to the cloud services.

The Practical Guide to Cloud SLAs should be your starting point to understand the responsibilities of both the consumer and the provider and also who within the consumer’s organization should be the owner of the SLA.

The development of the SLA is a cooperative process within the consumer’s organization. The team will consist of an overall owner, and business and technical leads. Together the team assesses the business level policies for the service. As an example, an assessment of the data-level policies for the service should be done, that is. data preservation, redundancy, and location.

Each cloud service model (IaaS, PaaS, SaaS) and deployment model (private, public, hybrid, community) delivers different capabilities. It is very important for the team to understand the differences in order to develop an effective SLA. It is incumbent upon the team to acquire the knowledge and be able to apply it accordingly.

As with any services, whether in-house or deployed into a cloud, performance considerations of the service must be taken into account. Availability, response times, transaction rates, processing speeds are all elements to consider, especially when the user of the service is external to the organization.

Security and privacy in the cloud have been at the forefront of the discussions for the cloud some time now and rightly so. Understanding the cloud service and the data it manages is the starting point to assigning the security and privacy levels for the data.

With a service running outside the walls of the enterprise, it is very important that the cloud provider and the cloud consumer agree on how to track and manage the overall health of the service. Without the agreement of how to manage the health of a cloud service, assessing the overall performance of the service will be very difficult.

Here is a question to consider. Will your service be available 100 percent of the time? Well, that is your goal, but what happens when it fails? Who is responsible for the notification of an outage? Who has responsibility to resolve the problem? What is the communication process to the users of the service? All questions that need to have an answer and agreed to between the cloud provider and the cloud consumer.

Now let’s take the service outage to the next level. What is the consideration for a major outage, that is, the cloud provider’s site experiences a disaster, natural or otherwise? Can the data be recovered seamlessly? How long will it take to become operational again? Who has the responsibility to re-establish the service? And most important, has the disaster recovery process been tested? This is a step that cannot be missed.

Here’s the final point to consider. What happens if the parties make the decision that the service needs to be moved to another provider? What will be the expectations on the parties to ensure that a seamless transition with no downtime or loss of data? Is the exit plan agreed to and documented?

For a more comprehensive view of each of these steps, download the Practical Guide to Cloud Service Level Agreements from the Cloud Standards Customer Council’s website. For those looking to move their data to the cloud, I encourage you to review the guide, provide feedback, and consider engaging in the CSCC to ensure your voice is heard. You can find more details, including membership information, on the CSCC website. To read a lively dialogue about the topic, you can also find a recap of the recent IBM #cloudchat that examines questions you should ask your cloud service provider.

Comments: 3
Angel Luis Diaz

About Angel Luis Diaz

Dr. Angel Luis Diaz has a diverse background in research & development, product management, and marketing. Currently Angel Diaz delivers interoperability and innovation across multi-vendor environments in the form of open standards and open source initiatives around the world.
This entry was posted in Private Cloud and tagged , , , , , , , , , , . Bookmark the permalink.

3 Responses to Cloud service level agreements (SLAs): What you don’t know can hurt you

  1. @schoutene says:

    Hi Angel, you beat me to it in writing a blog about this! Good read, I would advice all cloud providers and consumers to use the CSCC SLA information to their advantage.

    This information is especially interesting for 'born in the enterprise' cloud consumers that tend to evaluate and implement cloud services the same way as they would evaluate and implement traditional IT services. These consumers first define business drivers, functional and non-functional requirements, than evaluate the possible (cloud) solutions available and implement them for the long term.

    However, I would also like to point out that there are also 'born on the web' cloud consumers who tend to use specific capacities of multiple cloud services available and combine them into a solution. These cloud consumers build in redundancy and overall solution availability into the architecture and implementation. Basically build to 'expect failure', as all IT components will fail sometime. So you'd better architect your solution for this. This type of cloud consumers, in general, tend to focus less on the individual cloud prodiver SLA's.

    A good peice of research on these different ways of using cloud is called "The Power of Cloud", from the IBM Institute for Business Value. In a soon to be posted blog I'll go into detail a bit more.

  2. Bill Curran says:

    Thanks for posting something on this topic Angel. Management of cloud services is only now getting the scrutiny it is going to need. The CSCC paper is a great start for framing areas to consider. I think it does not weigh heavily enough in favor of the importance of response time SLAs however. Because of the abstraction of the cloud resources, availability metrics really become secondary to performance metrics for reporting on service or application viability. No doubt network and storage availability can affect response time, but sometimes response time can be good despite spikes in other areas. Combine that with the ability to shift workloads on the fly and you can see how that response time metric will matter so much. I look forward to the formulation of management approaches for cloud services that build upon performance-centric SLAs and incorporate analytics that will tie that performance with the other metrics available in determining service health and diagnosing abnormal conditions.

  3. M S Prasad says:

    A great paper and very informative. In my opinion it should be made as a defacto standards

Comments are closed.