Menu
Menu
The Cloudy Truth about Service Level Agreements

The Cloudy Truth about Service Level Agreements

I was looking through the program for an upcoming cloud computing conference and noted a number of sessions devoted to negotiating contracts and service level agreements (SLAs) with cloud providers. Reading the session descriptions, one cannot help but draw the conclusion that carefully crafting an SLA is fundamental to successfully using cloud computing.

The sessions described at length how they would help attendees with cloud computing topics like:

Definitions of uptime, availability and performance Negotiation techniques in crafting an SLA What factors to include in an SLA: virtual machines availability, response times, network latency, etc. Negotiating penalties for SLA violation Having sat through a number of discussions on the topic of SLAs, these session descriptions ineluctably brought to mind the following truth: SLAs are not about increasing availability; their purpose is to provide the basis for post-incident legal combat.

However, none of the sessions pointed this out. The session descriptions seem to suggest that clever SLA negotiation somehow ensures that one's applications will be immune to outages.

In fact, nothing could be further from the truth.

The reality is that all infrastructures will have outages of one sort or another. While careful assessment of a provider's capabilities may enable selection of a more robust provider and paying a higher fee may ensure faster response or communication with a dedicated response team, there is no immunity to outages. No matter how much time you spend crafting an SLA agreement, it will not ensure 100 percent uptime.

So why do people obsess about SLAs?

For one, it gives people a sense of control. Sitting in a room, insisting on special treatment, redlining a contract and replacing one set of language with another all make people feel like they're asserting their dominion. And that feels great. But don't imagine that you're going to fundamentally change the provider's contract. I learned this at an SLA presentation given by an attorney. After devoting 90 minutes to the minutiae of contracts, he concluded by saying, "Of course, you won't be able to change the standard contracts much, because they're written to reduce the provider's responsibility. What you're discussing is how much of a service credit you're going to receive."

People also obsess about SLAs because they provide a basis for post-outage haggling. Being hard-nosed up front may mean greater compensation later. But keep it in perspective: no matter how much you haggle, you're not going to be fully compensated for the business loss resulting from the outage.

To reiterate: SLA compensation is limited to a credit against the cost of the service--not the user's cost of the outage--and the cost of the service is often a tiny percent of the cost of the outage.

Here's an example that a former employee of one of the largest outsourcing companies shared with me: Their very large retail customer's website crashed on Black Friday. The application was down for six hours, resulting in a loss of $50 million in revenue. The outsourcer's compensation to the retailer? Six hour's service credit--approximately $300.

The morale of this story? Keep the whole SLA discussion in perspective. It's not going to make you whole if your application is unavailable.

The worst thing about investing too much energy into SLA haggling is that it may distract you from the far more important issue: how to ensure uptime. If you're on the Titanic, and it hits an iceberg and sinks, all of the time you spent negotiating the location and conditions of your deck chair isn't going to help your prospects one bit.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

Tags SLACloudservice level agreementscloud computing

Show Comments
Computerworld
ARN
Techworld
CMO
<img height="1" width="1" style="border-style:none;" alt="" src="//insight.adsrvr.org/track/evnt/?adv=bitgblf&ct=0:dn998liw&fmt=3"/>