Are you concerned about managing cloud service level agreements (SLAs), and what impact they might have on your use of cloud systems?
The first question, of course, is do you really need an SLA? Is there an SLA for Facebook or Google – if so, have you even read it? If you do believe SLAs are necessary, do you leave it to the service provider or are you looking for best practices for SLA Lifecycle Management?
What is an SLA?
There is no standard industry definition for an SLA.
While the concept is not new, the name has been popularized and promoted by the ITIL/ITSM standards. An SLA fundamentally represents a documented agreement between a service provider and a service consumer for the provision of one or more services that have specific characteristics and target levels of quantity, quality, and performance.
The tricky parts are: How are the services defined? How are service levels specified? How does the SLA relate to other parts of a customer relationship agreement?
You might also ask if a “cloud SLA” is materially different from any other IT SLA. Wikipedia does distinguish between an SLA for outsourcing (a full transfer of responsibility) and for cloud (a sharing of responsibility).
If you don’t have an explicitly agreed-to SLA for a service, then it is either implicit in the offering or the service is deemed to be best efforts without any promises.
IBM states the following definition:
“A service level agreement (SLA) is a contract between a consumer and a service provider that specifies the expectations for the level of service with respect to availability, performance, and other measurable objectives. The SLA records a common understanding about services, priorities, responsibilities, guarantees, and warranties between the parties. The SLA can also specify levels of availability, serviceability, performance, operation, or other attributes of the service.”
The SLA is not, however, meant to be a complete contract for service (it does not usually include prices or acceptable use policies, for example).
Some Examples of existing SLAs
To date, SLA development has been largely provider-driven, with SLAs being designed to suit each provider’s needed and circumstances and service capabilities. To be fair, since many services may be provided to millions of users, it would be unreasonable to expect custom-designed SLAs for each customer.
Some examples of cloud SLAs re: Microsoft Azure, Amazon AWS EC2, Google Compute Engine, HP and Rackspace. As is obvious, there is no standard format or presentation for cloud SLAs (yet).
In 2012, Gartner stated that the SLAs for some popular cloud providers were “practically useless”. See also the original blog from Lydia Leong here. Hopefully, significant progress has been made since those articles were written!
Standardization for Cloud SLAs
A number of SLA standardization initiatives are underway. For example, the European Commission, for its Digital Agenda for Europe, has developed Cloud Service Level Standardisati0n Guidelines. In April 2015, the Cloud Standards Customer Council published Version 2 of its paper entitled “Practical Guide to Cloud Service Level Agreements”.
The TMForum has also been active, with its “GB917, SLA Management Handbook, Release 3.1 Best Practice” (available to members only).
ISO/IEC JTC1/SC38 is actively working on a standard (to be called ISO/IEC 19086-1) for “Cloud computing – Service Level Agreement (SLA) framework and terminology – Part 1: Overview and concepts”. This document is restricted to committee members while it is going through the development and balloting process. Other parts of the standard will address such things as metrics.
This ISO standard takes an interesting approach that has been designed for wide applicability without restricting the format, structure or contents that a service provider may choose to include. An SLA consists of a set of “components” that may be grouped into “content areas.” Components are essentially sections of an SLA document that cover specific topics including what services are covered, the division of responsibilities, applicable definitions, the specific service objectives, etc. Each component includes a description, a relevance statement, service level objectives (SLOs) – quantitatively measurable characteristics – and service qualitative objectives (SQOs) – qualitative objective statements.
Other topics covered by the standard will include:
- Relationships between a master service agreement and one or more SLAs;
- Cloud SLA management best practices;
- Common definitions; and
- An initial set of content areas.
It is expected that this ISO standard will be finalized in 2016.
Five things to watch out for
It is not hard to run into significant complexities when working with cloud SLAs. Here are five areas to watch out for:
- Allocation of responsibilities – this can get quite complex in a hybrid cloud scenario, for example, when services have split responsibilities; also, the terms can change whenever private clouds are being employed;
- Sub-ordinate providers and multi-cloud solutions – some cloud providers subcontract functions (such as the infrastructure) to other cloud service providers; and, in cases such as Disaster Recovery there may need to be specialized cloud service providers;
- Business-oriented objectives and metrics – relevant and useful business-focussed metrics and measurements are important to every SLA, especially when they are tied to financial remedies or contract termination clauses;
- Completeness of objectives – the SLA should include all of the required descriptive material and service level objectives needed for proper governance – such as performance (e.g., availability, capacity), security (e.g. access control, incident monitoring, auditing and compliance), data management (e.g., backup, classification, portability), and personal data protection (e.g., Retention and Disclosure, Location, Openness); and
- Monitoring tools – the tools and techniques for obtaining and analyzing SLA measurements must be spelled out clearly, including who does the calculations, who initiates the resolution process and how the results are validated.
Changes over time
Just as a final thought, it needs to be understood that SLAs will evolve over time, along with the provider and its services. An SLA should not be a static document that sits on the shelf of the contact manager!
In fact, in the future, it is expected that many of the SLA terms will be part of a management system that generates the measures and performance indicators automatically.
These are my thoughts, what do you think?
