Chasing Cloud Computing Quality: It’s Not a Time for Toothless SLAs
SLAs are a seemingly-wonderful idea, a contractual promise of reliability. “Upon receipt of a customer trouble ticket, Bigfirm Cloud Enterprises will resolve the customer issue within two hours of…” Or there are the“nines,” as in three, four, or five nines’ reliability.
March 29, 2011
Let’s continue the discussion about cloud computing with some thoughts about quality of service in cloud vendors, and what prospective cloud customers might consider when choosing those cloud vendors. As I’ve said before, most organizations’ main reason for even considering the cloud lies mainly in hopes of saving a buck or two million. Of course, money talks—heck, it shouts—and so for many, the query, “Should we go to the cloud?” is question one. Since unintentionally becoming something of the poster child for “cloudnosticism,” I’ve gotten a flood of email from people saying, “Help me tell the boss why the cloud isn’t the all-saving panacea that the marketing folks and all of those journalists are suggesting it is,” and basically my answer is service.
Remind the boss about the other cloud services that he/she uses, and ask how he/she perceives their level of quality. When your cable, electricity, telephone or Internet service goes out and you’ve got to interact with your service provider, how has your customer experience been? Did you get to talk to a human? How many times did you have to say “yes” clearly and distinctly before your utility’s automated call director (ACD) system understood that you said “yes” and not “no?” How many times were you put on hold and then accidentally disconnected? Have you gotten that corporate jingle out of your head yet? When you finally got some help, how many hours did they say that you’d be waiting for a resolution?
If you answered at least one of those questions with a rueful nod, then imagine how the boss will feel when the company’s hosted Exchange server decides to take a couple of hours off some Tuesday mid-afternoon. (I recommend preparing for that day by practicing facial expressions in the mirror. Get good at an empathic “yes, I share your pain and sympathize entirely” look so that your naturally-occurring “I TOLD you so!” ear-to-ear grin doesn’t pop out.)
Seriously, let’s say that your organization decides to go to the cloud. You know there will be outages—if Microsoft and Google can’t avoid downtime, I’m not sure that anyone can—and unless you’re one of the cloud vendor’s five largest customers, you know that you’re going to get a cordially worded, “We’ll fix it when we FIX it!” recorded answer from the cloud vendor when the system is down because hey, that’s capitalism. Even if we’re a vendor’s smallest customer, though, we hate the idea of being at their mercy. So take the time to negotiate a decent service level agreement (SLA), and it’s best to do that before you sign up for a piece of the cloud.
SLAs are a seemingly-wonderful idea, a contractual promise of reliability. “Upon receipt of a customer trouble ticket, Bigfirm Cloud Enterprises will resolve the customer issue within two hours of…” Or there are the“nines,” as in three, four, or five nines’ reliability. In case you’ve never done the math on that, those three translate to no more than nine hours, one hour, or six minutes of annual downtime, respectively. After the jump, let's look at a few SLA considerations.
More from Mark Minasi on cloud computing:
SLA Considerations
First, consider your current quality of service—how did you score on reliability these past couple of years? I’ve already discussed the importance of knowing your current quality of service in other articles, so I won’t belabor the point further. But, in short, it’s silly to start insisting on some number of nines if you have no idea what “nine regime” you currently live in.
Second, look for and be wary about unrealistic SLAs. Last year, my email server was down for about 30 cumulative minutes for Windows Update reboots—hurray for me, four nines!—but a flood that put eight inches of water on my road led to being without Internet for two days, blotting my reputation to a mere two nines. Bummer. There really is no other way to get high-speed Internet in the rural area where I live and where my email server is physically located, and given that we get outage-creating floods, ice storms, or hurricanes every other year or so, then it wouldn’t be very reasonable to promise more than 99 percent uptime, if I was a cloud vendor. If I was a mildly unethical cloud vendor, however, I might offer 99.99 percent uptime in conjunction with a bit of fine print about “not subject to acts of God” or something like that. Notice, however, that most people looking at a proposed SLA with an Act of God provision would think, “hey, that’s reasonable, stuff happens” when in fact it would not be reasonable in my case, as you could say that God is a mite more “Act-ive” in my area. Ask the vendor, where are your data centers? What’s the weather like there? Who provides their Internet backbone, and what’s their reliability level? A data center that’s up 99.9999 percent of the time is of no value if it’s connected to the Internet via Bob’s Tae Kwan Do Studio, Bowling Alley and ISP, Inc.
Third, make the penalties and method of restitution very clear and fair. My guess is that losing your Exchange server for two hours would be extremely annoying but not life-threatening to most businesses, but two days of downtime could easily lead to loss of a client or two, a missed opportunity or the like. Again, the whole point of going to the cloud is to save money, not lose it, so don’t be afraid to put some sharp teeth in the SLA and, if you can’t get those teeth, then give the cloud a miss altogether. Your SLA must establish the fact that depriving you of your IT services is the most expensive alternative that your cloud vendor faces in a disaster. Cloud vendors must see depriving you of your email as a larger disaster than a tsunami.
Finally, ask yourself: what will you do if the vendor doesn’t live up to their end of the bargain? Ensure that they can’t essentially hold you hostage. Think like you’re creating a disaster recovery plan—build a step-by-step, well-tested set of procedures to let you move your stuff off the cloud and back on-site in the minimum time possible. And while you’re at it, spend some time looking at the costs of de-clouding, and keep the number in mind when totting up a cloud solution’s purported savings. In both business and life in general, it’s never a bad idea to keep an eye on the exits and to know how far away they are!
Trusting your organization’s lifeblood—its information—to a contract vendor is nothing to take lightly. When negotiating the terms of cloud services, it’s not a time for toothless SLAs. A good SLA ensures that it is your cloud vendor and not you who loses the most sleep over your data and your ability to access it.
More from Mark Minasi on cloud computing:
About the Author
You May Also Like