I'm not sure the best way to approach it. The issue is that there is (or can be) a huge imbalance between cost and impact for cloud service downtime. A business-critical application coming down for even an hour has the potential to cause significant heartache to the customer's business. The imbalance is so high that I'm not sure it's possible to justifiably compensate for your customer's business impact, based on what the market is for cloud services.
My thoughts on the matter are this:
* Nearly any compensation is "not enough" to a customer. They would have rather had the service not come down.
* It is nearly always better to use extravagant SLA breach compensation for higher redundancy. [1]
* Because 100% uptime is prohibitively expensive, transparency about historical uptime is vital for a prospect making a buying decision.
* The most fair way to compensate a customer for downtime is to take out an insurance policy against your service for the cost of downtime to your customer. (This is unique to each customer, and service should be priced accordingly.) [1]
1: Customers should be compensated for downtime, if at the very least because they aren't able to use the service they paid for. If additional money can't be used for additional redundancy/reliability, it can be used to insure against the cost of downtime.
Edit: After re-reading your question, I see that I misunderstood your question. I don't mean to say "Your customer was down for an hour, give them an hour (or more) for free." I actually meant "Your customer was down for an hour. That costs them $XX,XXX in headache. You can't expect to compensate them enough to cover that, so it would be better to avoid the downtime."
If an application is that business critical, then shouldn't the organisation be running it across multiple cloud providers, or ensuring it can run it internally?
If I've understood your situation correctly - then yes, this would be an issue that is covered by our SLA. Our customer data is actually hosted on two separate storage backends for issues like failing disk drives.
Our approach on this is that when we offer a service to you, you should not be worried about how the physical equipment functions - it should just work. Hence all issues on that front would be our responsibility. Glad to talk more on this if you're interested. My contact details can be found on our company website.
Thanks for the comment! A 100% SLA is actually a promise of future uptime. Nobody can of course guarantee their uptime, no matter what the SLA percentage. Thus, the company includes compensation in the agreement if the service level is not met. All this of course is decided based on historical data and what makes business sense for the company, ie. how much money are they willing to lose if their services go down.
The key here is that that is for a SLA. So it's not that they'll never be down, but rather for every minute they are down they'll pay out money to you for the trouble.
To extend the car analogy, it's more like a lifetime warranty on a car: the car might break down all the time, but its still covered.
They're explicitly not saying that it will never go down. They're saying that if it ever does go down, they will pay their customers a penalty. Without having any "acceptable" amount of downtime that they don't have to pay a penalty for.
Really, too-many-9s SLAs are what's ridiculous. So you say you "guarantee" 99.99% uptime, but only interruptions of 30min or more actually count? 2 incidents of 29 minutes would put you over that .001% that you claim, without either counting.
I would definitely buy a car if they advertised it to never break down - if the compensation on the promise would be good enough!
But seriously speaking, a 99.99% SLA is not more realistic or achievable in itself than any other SLA promise. It all depends on the provider (how they strive to reach that promise) and what they promise in return if the promise is broken.
Nobody claims they will give you 100% uptime. The service level agreement is at 100%, that just means that the service should be up 100%; when it isn't, you get compensated. They're saying that any percentage of downtime (modulo time limits) is bad, not that it won't happen.
Thanks for the comment. I work at UpCloud so I'll chip in my 2c on the issue. Your description of "how much money providers are willing to risk" is a great way to approach this. While it doesn't probably give you the most universal view on redundancy - it is a good, comparative measure of how much companies are willing to risk if their services go down.
Building multi-cloud services is of course a way to try and avoid this, but I would say that this approach isn't very well adopted as of yet.
Having said that, those utilising cloud hosting services will need to balance their own risk levels with those of the companies they are looking at and find the best match. Another way to approach this is to ask; how much am I willing to risk my business for the benefit of this company offering me a cloud hosting service?
Full disclosure: I work at UpCloud, a cloud hosting provider and I think business in this industry day and night.
One thing that gets overlooked in almost all comparisons is the pricing models. I actually use Glacier through Arq (brilliant backup for Mac), but the catch is in the requests. I recently uploaded 200GB of photos to glacier and the upload process cost me about $10. The monthly storage is about $2.
The thing is that you shouldn't compare the sole storage price, but the total of cost of storing your data in glacier, which was also overlooked in the original article.
I'm sure AWS has understood this through their S3 storage lifecycle and thus developed an appropriate pricing model for glacier that arouses interest in the product like no other.
$10 for upload? Pricing is $0.050 per UPLOAD request plus $0.000 per byte. That means that your backup system made 200,000 UPLOAD requests. I don't think I have that many files which I want to back up, and I would hope that any system using Glacier as a back-end would bundle smaller files into larger archives.
(Well, I guess it means that your request size averaged 1 MB. If I'm already using Glacier, I would be perfectly happy with archive granularity coarser than 1 MB.)
Naturally the user is always responsible for the purchase he/she makes. However, if I (OP) make my selections and need to re-enter some information based on their request - I don't think that allows them to change my decisions from what I have chosen earlier, especially if you get an error message similar to "please check your credit card number".
It is also a de facto standard in general that sites do not change once set selections when fixing errors in the original form and once you differ from this you're bound to increase burden on your customer support.
OP here. They haven't refused of a refund per se, but since I am unable to reach them with the second request - it is comparable to "let's leave this be and maybe it will go away".
If it's really just a front-end bug, chances are they're getting lots of calls just like yours. You may just be part of a pile of callback tickets once the bug is fixed and all the refunds are processed. Or, they could still be trying to track down the root cause of the bug in the first place.
