Cloud SLAs 'fall short,' says user advocacy group

The Cloud Standards Customer Council says SLAs are so confusing and rigid as to be problematic for customers

Service level agreements in the cloud computing market are skewed in the favor of providers, can be difficult for customers to decipher, and in some cases are rigid and non-negotiable. Those are some of the findings from the Cloud Standards Customer Council, a user advocacy group that recently reviewed SLAs from some of the industrys largest providers.

SLAs typically cover the terms and conditions of using the providers cloud, fees, liability and security, as well as uptime and data management, among a variety of other topics.

[ Stay on top of the cloud with InfoWorld's "Cloud Computing Deep Dive" special report. Download it today! | From Amazon to Windows Azure, see how the elite 8 public clouds compare in InfoWorld Test Center's review. | For the latest news and happenings, subscribe to the Cloud Computing Report newsletter. ]

[CLOUD ADOPTION: How big is the cloud's impact? Depends on who's asking]

CSCC, which is a consumer advocacy group backed by dozens of the largest cloud providers, did not disclose which public cloud provider contracts were examined, but it noted that its findings are based on a review of publicly available agreements from leading public cloud providers.

A lack of commonality across SLAs from various providers makes it difficult for users to conduct an apples-to-apples comparison, the CSCC found. Important language about key service level guarantees can be scattered across several documents and be difficult to understand.

Generally, the SLAs are weighted heavily in the providers favor, leading to the vendors liability being limited. The burden is usually more likely on the consumer to recognize breaches of the SLA, notify their service provider, and request a credit.

CSCC has advice for users who are evaluating public cloud service providers. The most critical thing is for customers to understand their business uses for the cloud and any critical performance objectives, then search for those in the document.

For example, if a user is evaluating a public cloud option for disaster recovery and business continuity, they may be especially concerned about how the data is backed up by the provider across multiple sites to ensure availability and uptime. If the cloud is being used for test and development of products and services, perhaps uptime is not as important of a factor as ensuring security features, such as data isolation and deletion upon termination of the service.

During a recent webinar, researchers who compiled the report said the findings reinforce that its critical for enterprises to do their homework before jumping into the public cloud. In many cases, businesses evaluate their public cloud based on performance, price and other apples-to-apples benchmarks among providers. But, in some cases cloud SLAs could have terms and conditions that are non-negotiable that may prevent a business from using the service. Steven Woodward, who helped write the report, recommend to start by looking at the SLAs, then move into the other benchmark evaluations. If the SLAs do not meet the users' requirements, perhaps a private cloud, managed hosting, or collocation option would be better option.

We definitely expect that as the industry matures, and as there are more and more discussions about use cases between providers and users, we'll start seeing more educated consumers, says, Claude Baudoin, an IT consultant who helped compile the report. He's hopeful these better buyers will push vendors into amending their SLAs to be more clear, concise, standardized, and user-friendly. The CSCC's full whitepaper can be read here.

Network World senior writer Brandon Butler covers cloud computing and social collaboration. He can be reached at BButler@nww.com and found on Twitter at @BButlerNWW.

This story, "Cloud SLAs 'fall short,' says user advocacy group" was originally published by NetworkWorld .

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies