How Seriously Does Your Cloud Hosting Provider Take Redundancy?
en.upcloud.com
en.upcloud.com
One hour of downtime for an application paying $20,000/month for cloud services is worth $27.78. Even with a 100x multiplier the customer would be due a check/credit for $2,778. Given the choice, I'm sure most rational businesses would prefer the uptime over the credit. Perhaps someone running a company with similar cloud service bills could chime in.
How would you propose to compensate with uptime (if I've understood correctly)? Interested to learn your thoughts on this.
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."
The table listing the "confidence" levels of the providers is designed to impart a certain amount of trust on the end user. The provider is basically saying "you can trust me, not because you can see how I operate my network, but because I'm willing to put my money at risk through an escrow statement that is applied to all my customers". This isn't really useful to everyone as Sue's use case may have a high net worth and Bob's use case has a low net worth.
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?
How long does failover take (and how reliable is it)? How much bandwidth is available for replication between your 3+ separate providers living in separate datacenters and cities, and how much does the latency for this slow your system down?
True fully-distributed systems are a Hard Problem. SLAs aren't an artifact of business models, so much as they (along with those business models) are a non-technical workaround for technical limitations.
I know the whole "you're suppose to use availability sets for redundancy" or equivalent speak.. but there are a lot of times when this just is not possible, not to mention potentially doubling the cost when you do this
Just curious, does your SLA cover such outage case? My service provide said everything is normal from their POV which is kind of true.
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.
Why did you not opt for 2N?
Do you co-locate? What tier is the DC? If you colo, especially <= T3, your colo company has likely cut corners somewhere and that you don't know about some of the weaknesses in their infrastructure.
I don't even consider companies stupid enough to put out a blurb like that.
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.
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.
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.