Deep thoughts on Cloud SLA’s

OK, they aren't really deep thoughts so much as they are observations on the SLA assumptions made between provider and customer.

Earlier today there was a great back and forth on Twitter about SLA's and Cloud. Following are some of the associated Tweets:

@GeorgeDWatt
When SLAs are broken cash compensation may trump credits. It hurts more & if service is really bad may simplify exit. #CloudViews

@mthiele10
So much talk about Cloud SLA's. The real issue is how the provider measures outages vs. how the customer does. Penalties are immaterial.

@vambenepe
@mthiele10 Not being able to compensate for "actual loss" doesn't mean give up on defining any kind of penalty. We're beyond "eye for eye".

@GeorgeDWatt
MRT @mthiele10: ...Cloud SLA's. The real issue is how provider measures outages vs. how customer does. Penalties are immaterial. #CloudViews

The above Tweets and many others that occurred over a 30 minute period got my writing juices flowing, which is where this blog was born.

Assumption 1: We need SLA's, but maybe not for the commonly held belief of why

Cloud SLA's are really an opportunity for the customer to learn more about how the provider can protect them from risk. The process of building and agreeing to the SLA is also a necessary step for the customer to take in evaluating their own assumptions on the quality of existing internal architectural design. In other words, the customer must fully grasp and internalize the actual capabilities and design characteristics of their application and physical infrastructure prior to moving anything to a cloud provider. It's only through this self-evaluation will the customer determine if what the cloud provider is offering will meet the business requirements.

Key thought: Assumptions between IT and the business when the application was in-house will be put through a much more vigorous test when it's supported on a public cloud offering. In other words, mistakes that you might have been able to apologize your way through when the application is internal won't be so easy to ignore when they are more "public".

Assumption 2: Penalties are necessary as a way to measure success or failure

I believe my interpretation of "Penalties" is slightly different from many in the Cloud buyers community, but I could be wrong. It's also possible that I haven't read the right blogs.

As suggested in the above "assumption 2" statement, penalties should be used more as a measure of success in the relationship. The fact that you've moved a business critical function into a public cloud means that you need to create a partnership with your provider that mirrors any expectation of communication and responsiveness you would have as a buyer of an internal service. It's essential to realize that communication is the first and easiest process to break. If you were having trouble communicating with your internal teams and customers, moving an application into the public cloud won't simplify the issue, it will magnify it.

It may seem counterintuitive, but you really must fully understand how to manage and support your application effectively before you give it to someone else.  If you hand if off thinking "they'll take care of it", you're in big trouble already. The most common mistakes made in outsourcing are "doing it for the wrong reasons", and "not fixing the service before handing it off".

Assumption 3: A Cloud SLA should be considered a "work-in-progress"

Your SLA should be a mirror of your current needs for any number of common metrics:

  • Performance
    • By region, by application, by process, by instance, etc.
  • Scale needs
    • Up, down, how fast, lifecycle management
  • Cost
    • When, for what, who
  • Failover or recovery requirements
    • RTO, RPO, data locations
  • Merger & Acquisition efforts
    • Integration, new markets, new regions
  • Enterprise growth plans
  • Etc., etc.

Seeing as how all of the above metrics are likely to change as your company changes, you need to stay close to your new cloud provider partner to avoid prioritization miscues. So again, the SLA must be treated as a work in progress and a living document. If you haven't gone over your SLA with your customers and your provider partner in three months or longer, you're falling down on the job.

Key Points:

Your SLA should be a tool for helping you define requirements against "real world" needs and capabilities, while taking into account what you actually have versus what you're asking for.

Communication, communication, communication, it is the key to having a successful partnership, whether it's cloud or some other business arrangement. Build in regular and meaningful opportunities to communicate or find yourself surprised when expectations aren't met. This isn't something you leave up to someone else to do. If the provider isn't offering it, then demand it, if they can't support it, then you're with the wrong provider.

Your SLA with any provider, but especially a CSP, must be considered both a "work-in-progress" and a "living document".  As technology, the economy, and your business change, so should the SLA.

 

Comments

Cloud impact on the corporate data centre!

 

Did you know that 90% of corporate data centre capacity goes unused? Check out the IDC whitepaper about Cloud impact on the corporate data centre.