5 ms·
Good question. The point of the article is that the value of cloud SLAs are inversely proportional to the size of the cloud. Think of it this way, consider the
by ChuckMcM 7y ago
Good question. The point of the article is that the value of cloud SLAs are inversely proportional to the size of the cloud.
Think of it this way, consider the definition of an "availability" SLA as 'the mean availability of all hosts in our cloud'. If its reported at "five 9's" or 99.999% that means that a cloud of 100,000 machines could have one machine down for days at a time and never cause their SLA to slip. Big providers average over multiple hundreds of thousands of machines, your stuff could be down all the time and yet 'everything' is "meeting all the SLAs".
You see this outside of data centers in other overly generalized metrics. Unemployment is only 3.7%[1]! Yay right? Tell that to the people of Magoffin County Kentucky where unemployment is 12.3%[2]
So would I pay more? I don't know. If none of the service providers would offer SLAs based on my footprint, it would not be a choice. If one does, then it becomes the preferred choice even if it is more expensive. At which point do all of them to remain competitive? Another good question. Could be a good differentiator for the #3 cloud provider Google. I know they have the technology to do it if they chose to.
[1] https://www.bls.gov/news.release/pdf/empsit.pdf https://www.bls.gov/news.release/pdf/empsit.pdf
[2] https://www.lanereport.com/112723/2019/04/state-releases-county-unemployment-data-for-march-2019/ https://www.lanereport.com/112723/2019/04/state-releases-cou...
- rossjudson 7y agoYou might want to have a look at some Google Cloud SLAs[1]. They are generally calculated based on actual performance on a particular customer's RPC traffic, down to individual RPCs (at least on Google Cloud Storage, where I work). Read through the agreements to the definition of "Error Rate", and I think you'll find the terms you're looking for. You're welcome! :) The root post does raise an important issue, though -- just because GCS thinks it's doing great on your RPCs doesn't mean that your system is doing great. [1] https://cloud.google.com/terms/sla/ https://cloud.google.com/terms/sla/
- jaytaylor 7y agoHow are Google Cloud SLAs valuable when the service regularly has multi-hour (IIRC, > 5 hours!) (sometimes global) outages? I pose that Google is not presently in a good position to highlight as a role model or case-study for demonstration of effective cloud provider SLAs.
- badpun 7y ago>How are Google Cloud SLAs valuable when the service regularly has multi-hour (IIRC, > 5 hours!) (sometimes global) outages? You can sue them? (if that's not forbidden by the contract).
- azernik 7y agoSee my sibling comment - they have a process for talking to them to get discounts for months when they don't meet the SLA. If they don't give you said discount, you can sue them for breach of contract, but if they pay out you can't sue them for damages.
- azernik 7y agoYou report to them your outage (https://support.google.com/cloud/contact/cloud_platform_sla https://support.google.com/cloud/contact/cloud_platform_sla) and then get monetary credits. e.g. for an arbitrarily-clicked service [1], it's 10% off for a month when they don't hit three 9s, 25% if they don't hit two 9s, and 50% off if they're below 95%. Which honestly isn't a very high uptime requirement, but there is a very clear process for getting payouts when they miss it. [1] https://cloud.google.com/filestore/sla https://cloud.google.com/filestore/sla
- azernik 7y agoIn the old phone model, SLAs are per-customer: it doesn't matter what your network as a whole looks like, if any phone line goes below N 9s you're going to be paying out the contract penalties. It's still better for the telco to fail for fewer customers, because then they don't have to pay out as much. The granularity may be harder to define for cloud services, but it is very much doable; it's all about making sure that the target metrics have zero connection to the global state of the system.