ServiceTechMag.com > Issue LXIII, June 2012 > Cloud Is The Buzz, But What About The SLA?
Howard Cohen

Howard Cohen

Biography

Howard “Howie” Cohen is currently a Community Manager and Consultant System Integrator for the US Department of Defense. He works for a company called Steelthread Inc which provides engineering solutions to the DoD and the Federal Government. Howie has worked as a consultant in the defense industry for companies like Booz Allen Hamilton and Lockheed Martin. In his previous position, he worked on cloud strategies and IT strategies for US Joint Forces Command. He recently moved on to Steelthread to work on a defense oriented application lifecycle management platform called Forge.Mil. Forge.Mil is one of the most aggressive agile oriented projects in the DoD. It provides a multi-tenant software as a service platform serving the DoD Enterprise at large. Howie’s role as a Community Manager is to bring senior leaders, program managers, developers and IT staff together. This position requires an understanding of people, process, methods and an understanding of services and tools.

He can be reached at: howardscohenmba@gmail.com

Contributions

rss  subscribe to this author

Bookmarks



Cloud Is The Buzz, But What About The SLA?

Published: June 26th, 2012 • Service Technology Magazine Issue LXIII PDF
 

Abstract: Everyone is talking about cloud computing but a great deal of writing is spent on the advantages of the technology. Moving services off premise can create a great deal of savings but there are risks that should be considered. Most of the risks are associated with the fact that services and service agreements favor service providers. The key to lowering the risk is thinking about the right questions to ask up front and considering the implications of the service-level agreement (SLA). Cloud is the buzz, but what does that mean to you? Understanding what is in an SLA and what questions should be asked of service providers is key to the stability, sustainment and future of any cloud based consumer. What should we consider?


Introduction

The cloud is the buzz! Now go out and get yourself some cloud. But what does that mean to your business or organization? It is critical to ask questions of service providers up front and understand the implications of doing business with them. The service-level agreement (SLA) should be considered up front as part of the business case. The idea behind this article is to spark some thinking concerning the SLA. In addition to seeing answers, implementers and decision makers should think about the best questions to ask. Before jumping into a cloud without a parachute, take some of these ideas and concepts into consideration.

Recently the Cloud Council [REF-1] released a practical guide to cloud SLA's. It looks at 10 steps to evaluate cloud service level agreements [REF-2].

Online, you can find various calculators and planning tools to help identify and define the various properties and areas of concern with SLAs. What you don't see is a lot of information concerning the implications of services, regardless of the SLA. One example of this could be international law as ub what happens when you do business with China [REF-3].

Does the SLA specify where cloud service transactions will take place? Should it? What kind of legal implications are there for doing business in the cloud? What are the costs of having legal representation overseas? What about downtime? How much will it cost to have more than one company with managed services? How many companies have lawyers involved during the evaluation and purchase phase of acquiring cloud services? How many companies have shadow IT involved in cloud services without even knowing the implications?

What about the US Government? How many experts are actively engaged at the program or project level in understanding the implications of cloud resources?

You need to understand what legal questions to ask as well as the technical questions. Today, SLA's are heavily weighted in favor of the providers and that will need to change in order to meet the needs of service consumers.

Cloudbus offers up many considerations [REF-4]. What the agreement does say is that you can terminate the agreement. However, what it doesn't say is what happens to your business or work.

There is a problem and it is a serious one; consumers are not controlling the market. The idea of this doesn't make much sense, but it is the reality and you need to know what can be done about it, if anything. You also need to know what questions should be asked from the boardroom to the lab.

How many times have you installed a piece of software and scrolled down through 60+ pages to install or use the product? Let's get this straight. Generally you go someplace or purchase something and you have "no say" in the conditions of the exchange other than if you don't like it, you don't accept. What if your husband or wife agreed and you didn't know? What about your children? Just say, maybe, they click faster than you.

In the past, it was common to negotiate a price on an item and the conditions of sale. To a degree you can still do that! This is very important because it directly correlates to your ability to make choices on what you are willing to purchase, and what you aren't. If I told you that somewhere in the agreement that you didn't read, it says "If xxx.inc finds out that you have died, xxx.inc has the right to recover software sold under licensing and any hardware or media that software resides on." Would that be okay? This may seem like a far-fetched example, but it can actually be shocking what is "technically" in some agreements, so read them.

This applies to the service level agreement as well. This is critical because lawyers are not making these agreements on your behalf; they are making these agreements on behalf of the service provider. It is like going to court without representation against a sort of 'legal' mafia.

Last year, I bought a phone from a phone service provider that buys its service from another phone service provider. I had to pay for the phone outright because this was a no-contract deal. Interestingly enough, they had unlimited voice and data with a payment model that would decline over time as long as I paid on time. What they didn't tell you was that if you made payments early it didn't count. They also didn't tell you that the price would decline every six months, not every month. They didn't tell you outright and clearly that the service they offered had bandwidth limitations. They didn't tell you clearly that any of the phones offered for this service were going to be of the lowest quality compared to the parent services.

I started the service in December and the phone was only for business use. The first problem I had was the Bluetooth headset wouldn't operate properly. I bought the headset with the phone as part of a package. You would think that the commands from the headset would work with the phone. I spent about $250.00 US on the package for the phone and about $55.00 US for the service. At this time I was primarily working from my home where I didn't get service on the phone. I had to use the Google phone service and give everyone the Google number so that it would ring either my home office phone or my cell when I was out of the office. In other words, I had to use a service to use my service and in extremely limited conditions.

Frequently while driving from point A to B I would lose signal. I had been on some business calls and they calls were dropped. Not only was it embarrassing, it disrupted my business. Ironically, this service was not purchased from a small local carrier; it was an international service.

I called the company and asked for help. It was a challenge to get through to a person; it took time out of my day. I actually had to call back several times because I couldn't wait on the phone as I had other things I needed to do. I had to find alternatives and work around the situation. And, of course, when I finally was able to talk to a human being, they were unable to help me.

Of course I am not going to name the company but here is an excerpt from their service level agreement:

"YOU AGREE THAT WE ARE NOT RESPONSIBLE FOR CERTAIN PROBLEMS:

YOU AGREE THAT NEITHER WE NOR OUR SUBSIDIARIES, AFFILIATES, PARENT COMPANIES, VENDORS, SUPPLIERS, OR LICENSORS ARE RESPONSIBLE FOR ANY DAMAGES RESULTING FROM: (A) ANYTHING DONE OR NOT DONE BY SOMEONE ELSE; (B) PROVIDING OR FAILING TO PROVIDE SERVICES, INCLUDING, BUT NOT LIMITED TO, DEFICIENCIES OR PROBLEMS WITH A DEVICE OR NETWORK COVERAGE (FOR EXAMPLE, DROPPED, BLOCKED, INTERRUPTED SERVICES, ETC.); (C) TRAFFIC OR OTHER ACCIDENTS, OR ANY HEALTH-RELATED CLAIMS RELATING TO OUR SERVICES; (D) DATA CONTENT OR INFORMATION ACCESSED WHILE USING OUR SERVICES; (E) AN INTERRUPTION OR FAILURE IN ACCESSING OR ATTEMPTING TO ACCESS EMERGENCY SERVICES FROM A DEVICE, INCLUDING THROUGH 911, ENHANCED 911 OR OTHERWISE; (F) INTERRUPTED, FAILED, OR INACCURATE LOCATION INFORMATION SERVICES; (G) INFORMATION OR COMMUNICATION THAT IS BLOCKED BY A SPAM FILTER; (H) DAMAGE TO YOUR DEVICE OR ANY COMPUTER OR EQUIPMENT CONNECTED TO YOUR DEVICE, OR DAMAGE TO OR LOSS OF ANY INFORMATION STORED ON YOUR DEVICE, COMPUTER, EQUIPMENT, OR COMPANY A STORAGE SPACE FROM YOUR USE OF THE SERVICES OR FROM VIRUSES, WORMS, OR DOWNLOADS OF MALICIOUS CONTENT, MATERIALS, DATA, TEXT, IMAGES, VIDEO, OR AUDIO; OR (I) THINGS BEYOND OUR CONTROL, INCLUDING ACTS OF GOD (FOR EXAMPLE, WEATHER-RELATED PHENOMENA, FIRE, EARTHQUAKE, HURRICANE, ETC.), RIOT, STRIKE, WAR, TERRORISM, OR GOVERNMENT ORDERS OR ACTS. YOU SHOULD IMPLEMENT APPROPRIATE SAFEGUARDS TO SECURE YOUR DEVICE, COMPUTER, OR EQUIPMENT AND TO BACKUP YOUR INFORMATION STORED ON EACH."

"YOU AGREE OUR LIABILITY IS LIMITED - NO CONSEQUENTIAL DAMAGES:

TO THE EXTENT ALLOWED BY LAW, OUR LIABILITY FOR MONETARY DAMAGES FOR ANY CLAIMS THAT YOU MAY HAVE AGAINST US IS LIMITED TO NO MORE THAN THE PROPORTIONATE AMOUNT OF THE SERVICE CHARGES ATTRIBUTABLE TO THE AFFECTED PERIOD. UNDER NO CIRCUMSTANCES ARE WE LIABLE FOR ANY INCIDENTAL, CONSEQUENTIAL, PUNITIVE, MULTIPLE, OR SPECIAL DAMAGES OF ANY NATURE WHATSOEVER ARISING OUT OF OR RELATED TO PROVIDING OR FAILING TO PROVIDE SERVICES IN CONNECTION WITH A DEVICE, INCLUDING, BUT NOT LIMITED TO, LOST PROFITS, LOSS OF BUSINESS, OR COST OF REPLACEMENT PRODUCTS AND SERVICES."


What Does This Have To Do With Cloud Computing?

The situation is the same for cloud services. Imagine if you will, for a moment, that this was a service you purchased for your corporation and you had a corporate agreement. When you buy cloud services, do you consult a lawyer? Do you present the service provider with a contract or does the service provider present a contract to you? Would you enter into a contract with someone that you don't know with no mediation and no active discussion on terms? Would you enter into a contract with an international company without understanding the implications? We do this all the time and don't realize it.


What Are The Implications?

Last year Amazon had a service outage that put companies down hard, but it didn't violate any SLA and further there was no remedy offered to these companies [REF-5].

According to Ray Wang [REF-6]:

As calmer heads prevail, most CIOs, business leaders, and analysts realize that:

The intent concerning my phone service was to save my company money. I was under the impression that if I went with a global carrier that my service would meet my expectations. I also believed that if I had a problem, it would be resolved through a call to the organization. The result was that I spent more money up front, I lost money over time and I adversely impacted the relationship with the people I conducted business with due to service disruptions. While I was able to return phone calls and apologize, it was at minimum embarrassing. I wound up changing services to another global provider that had a good reputation and my overall service costs more than doubled. While the total costs of services are now more expensive, the tradeoff is that I have lowered risk. I have a better quality phone and rarely lose connectivity. The fact is that even with this carrier, I can suffer some of the same issues. My current carrier has a service level agreement similar to the other carrier. As we move towards geographically dislocated services we have to consider the service and legal implications. Having a service level agreement will do no good if it is weighted to the service provider and if there is nothing you can do to take action to remedy poor service.

Some folks say, "Just change your service." Let us think about that for a moment. If you spent a lot of money moving to cloud services and you found yourself leveraging some of the proprietary options, you may find yourself in a bind. As a consultant, I have seen companies moving into cloud solutions without consideration of the SLA and without a lawyer in hand. Why? Because not unlike my effort to save my company money, a lot of cloud services are approached by people with good intentions from the bottom up. As these teams work to come up with cost savings and prove that leveraging cloud services can really cut costs and improve services, they may not have the expertise to understand the implications of the total cost (monetarily or otherwise) of implementation to the business.

  • Cloud outages are rare but can happen. While most organizations cannot deliver 99.5% up time let alone 90% performance, disruptions can and will happen. The massive impact to so many organizations last week highlights potential vulnerabilities of betting 100% of capacity in the cloud. More importantly, it showed that broad adoption does not equate with bullet-proof reliability. Most organizations lacked a contingency plan.
  • Cost benefit ratios still favor cloud deployments. For most organizations, the cost of deploying in the cloud remains a factor of 10 cheaper than moving back to the traditional data center or even a private cloud. Capital costs for equipment, labor for managing the data center, excess software capacity, and the deployment time required to stand up a server create significant cost advantages for cloud deployments.
  • Current service level agreements lack teeth and should be improved. Most organizations lack teeth in the cloud/SaaS contracts to address service level agreement failure. Despite all backups and contingency plans, clients should consider scenarios where core business systems go down. What remedies are appropriate? What contingencies for system back up are in place? Who is responsible for disaster recovery? Will the vendor provide liability and for what?

The bottom line is that you must proactively account for breaches In service level agreements In SaaS/cloud contracts. This can be done through a combination of contract provisions and contingency plans. Here are some suggestions recommended to clients:

  • Apply provision from the SaaS/Cloud bill of rights [REF-7]. Though written in late 2009, this document remains a best practices guide to SaaS contracting. Key provisions to apply include: Quality guarantees and remuneration, stipulate data management requirements, and on-going performance metrics.
  • Include service level agreements with teeth. Credits for free licenses for down time sound good on paper. In reality, down time when critical systems fail could result in massive financial losses. Contracts should apply risk on the potential business loss. Some clients include a provision that identifies compensation for a percentage of average daily business revenue during the time period of down time.
  • Reevaluate your Amazon deployment strategy. Believe it or not, Amazon technically did not violate its service agreements [REF-8]. To deploy a true backup strategy, organizations should add copies of their server instance in multiple regions and data centers as an added layer of protection. This ensures that a proper fail over occurs even if multiple regions experience outages.
  • Implement a real disaster recovery strategy. The Amazon outage exposed that many start ups failed to have a disaster recovery strategy [REF-9]. A number of solution providers now provide cloud disaster recovery. More importantly, these providers can recover physical or virtual machines in a cloud within minutes. Whether organizations can fire up a backup server in time remains the open question.

How many organizations are responsible for more than just themselves? Local, state, and federal government are moving into cloud strategies, banks and financial institutions are making groundbreaking moves on cloud computing and finally medical communities are moving "to the cloud."


Conclusion

It is critical to take into consideration the SLA and have a clear understanding of any user agreements. Most of us have the end in mind when we look to leverage technologies but we have to take into account the legal ramifications of glossing over these agreements. The SLA is generally presented by the vendor but there is no reason that an organization has to agree to terms without discussion or additional interaction with an organization. The bottom line is that consumers are responsible to make sure that the SLA is fair and that it meets their needs. The SLA should be addressed as part of the technology analysis while evaluating cloud services. If the SLA is overlooked a catastrophic technical event could make for a catastrophic business event.


References

[REF-1] Cloud Council, http://www.cloud-council.org/

[REF-2] Cloud Standards Customer Council., http://cohenovate.files.wordpress.com/2012/04/pgcloudsla040512mgreer.pdf

[REF-3] James Fallows, "Doing Business in China ," The Atlantic.

[REF-4] Linlin Wu and Rajkumar Buyya. "Service Level Agreement (SLA) in Utility Computing Systems," CloudBus, http://www.cloudbus.org/reports/SLA-UtilityComputing2010.pdf

[REF-5] Arnal Dayaratna, "Why Amazon's Cloud Computing Outage Didn't Violate Its SLA," Cloud Computing Today, April 29 2011, http://cloud-computing-today.com/2011/04/24/why-amazons-cloud-computing-outage-didnt-violate-its-sla/

[REF-6} R Ray Wang, "Monday's Musings: Lessons Learned From Amazon's Cloud Outage," Forbes, May 25 2011, http://www.forbes.com/sites/ciocentral/2011/04/25/mondays-musings-lessons-learned-from-amazons-cloud-outage/

[REF-7] R Ray Wang, "Research Report: Customer Bill of Rights - Software-as-a-Service," A Software Insider's Point of View, October 12, 2009, http://blog.softwareinsider.org/2009/10/12/research-report-customer-bill-of-rights-software-as-a-service/

[REF-8} Arnal Dayaratna, "Why Amazon's Cloud Computing Outage Didn't Violate Its SLA," Cloud Computing Today, April 29 2011, http://cloud-computing-today.com/2011/04/24/why-amazons-cloud-computing-outage-didnt-violate-its-sla/

[REF-9] Krishnan Subramanian, "Some Lessons From AWS Outage," Cloud Ave, April 22 2011, http://www.cloudave.com/11886/some-lessons-from-aws-outage/