When I read articles about contracting with cloud service providers (or other IT service providers such as colocation providers) often I see a lot of emphasis on Service Level Agreements (SLAs). That’s the wisdom that they offer you: make sure you have a solid SLA with your cloud service provider. The only problem with SLAs is that while, theoretically, they should be a useful tool for managing your cloud vendors, in practice they are a bit weak. Here’s why:
1) The standard penalties you are likely to get in your contract with a cloud vendor if they miss their SLA are miniscule compared with the pain and suffering you are going to experience if the service goes down. One cloud provider with whom I’m familiar (I won’t name them, but their SLA is pretty typical) will provide a 5% credit if their uptime is between 99-99.5% (their SLA guarantee is 99.5%). So let’s say you are spending $5000 per month with that service provider, and that during one month they are down for 7 hours, and you can’t service your customers for most of a business day. What do they give you? Let’s see….a month with 31 days has 744 hours in it. So if they go down for 7 hours, we’re just above 99% uptime. So they owe you 5% of $5,000, which is $250. ARE YOU KIDDING ME??? Your business is out one day’s revenues, the CEO is on the phone asking to speak with “shithead”, and your cloud service provider is going to give you $250?
2) Typically, cloud vendors lowball the SLA. A typical number you’ll see in the marketplace now is uptime SLAs in the range of 99.5%. So over the course of a year, they could be down for…365*0.005 = 1.825 days? There’s a good chance I could hit 99.5% hosting your software on my laptop. (Well, as long as I promise not to fire up iTunes, which seems to crash my Windows 7 laptop. Yeah, yeah, I know. It rocks on a Mac.) By the way, that 99.5% target doesn’t include scheduled downtime. So as long as they announce the downtime ahead of time, it doesn’t count. By the way, ask your vendors how much notice they provide. Some vendors only give about a day’s notice for maintenance windows, which makes it difficult if you have users that use the system during off-hours, when the vendor is doing the maintenance. So anyway, the cloud vendors just aren’t setting very aggressive SLAs. If you ask the vendor, they’ll probably admit that they are lowballing the SLA, or at least they’ll say, “Well, our long run average is certainly better than that.”
3) Some cloud vendors won’t even provide an SLA. Salesforce.com is an example. At least they won’t give you one if you’re not a mega-customer. And apparently even for big customers they try to avoid doing so, to the point where according to some sources (http://www.online-crm.com/sla.htm), they won’t even call you back if you call and ask for an SLA! So they are really just saying “look, we think our service level is good enough, but we’re not going to guarantee it, so just try it out and if you aren’t happy, then just leave.” For certain kinds of services that’s probably good enough, but for “mission critical” services, it’s not a very reasonable answer. One thing Salesforce does that I like a lot, though, is give you transparency to their current system status, and recent history. Check this out: http://trust.salesforce.com/trust/status/. So you can have some feeling that they’ll be honest with you if there is an issue. However, they don’t provide data on their long-run historical performance and they aren’t making you any promises.
So what do you need to do to? Forget about SLAs? Not entirely. I’ll talk about some ideas for managing SLAs in my next post (people have been telling me I put too much information in my posts and I need to chop it up!)
CamiApp 