An SLA thread

I've mentioned this comment thread in an earlier post. @sarojkar (not a Twitter account) and I took it another round. The origin post is about how to write/offer a great SLA model to cloud services.

@sarojkar's answer to my Q; whether or not he/she meant a service chain SLA or full SLA for a service incl underlying parts/functions:

"What I mean say is that these items need to be discussed and put in paper as part of SLA. You don’t want to be in a situation where your provider is pointing a finger at the infrastructure issue or outage and saying it wasn’t their fault. Incorporate SLA terms that indicate how your company will perform based on these resources. What does it mean to your operations if the cloud is down? When will you be using the service? How long can your business operate without the cloud service? What are your non-production times? What is your company business continuity plans in case of a cloud service outage? Latency might be a problem with cloud providers, so you need to consider that aspect too."

My comment/answer:

"Yes, I certainly agree. There should be no such thing where CSP’s can get away blaming service outage because of the underlying functions/infrastructure (including bugs – choose another part from another vendor if buggy). It’s the CSP who choose which part’s building their service. If the CSP doesn’t choose great and reliable parts the customer shouldn’t suffer because of bad choices. Unfortunately these might be risks the CSP calculate, where the SLA and penalty becomes just some numbers. Hopefully not but it might be a risk for the customer. Since it’s more accepting T&C’s than negotiating contracts when it comes to cloud. Therefore, as you said earlier; compare/benchmark, check for references and read T&C’s carefully. Also; as a professional business you should always analyze risks, impacts etc. whether cloud, ITO or on-prem and don’t end up with your pants down - outages do happen."

Read the post and the comments