Designing a scalable API on AWS spot instances • Hacker News Board

Re: Designing a scalable API on AWS spot instances

#61

Post by MaxBarraclough » Thu, Jul 23, 2020, 11:12 PM UTC

gridlockd wrote: post #43

CSDude wrote: post #13

Earlier quoted context omitted.

Always this poor argument pops up. 1st AWS and big 3 is much more reliable. 2nd AWS is not only a VPS provider. Changing vendors is not the answer to all cost related problems.

> 1st AWS and big 3 is much more reliable. I think that's a myth. People assume it's true because it should be true. I don't think it is true. > 2nd AWS is not only a VPS provider. It's a glorified VPS provider. Most of the stuff doesn't matter to most of the people using AWS, but they go for it so they can put it on their resume and because they don't want to get fired for choosing something that's not a big name.

> People assume it's true because it should be true. I don't think it is true.

It makes sense that bargain-bin providers would offer inferior reliability, but there are providers out there other than the big 3 cloud providers and the bargain-bin VPS providers.

GitHub for instance is apparently [0] hosted by Carpathia [1].

[0] https://github.com/holman/ama/issues/553

[1] http://www.carpathia.com/ (they should really fix https://www.carpathia.com )

Re: Designing a scalable API on AWS spot instances

#62

Post by WatchDog » Fri, Jul 24, 2020, 2:06 AM UTC

Seems like amazon has long been transitioning spot instances away from being a method of efficiently utilizing excess capacity, towards being a discounted service for less risk-averse businesses(businesses that can accept the risk of their service being terminated at any time).

Even if in practice AWS never sees large spikes in compute demand and corresponding large scale instance preemption, most businesses I've worked with won't accept the risk of having OLTP systems be taken down at any time.

No longer does spot seem to be a service where one can get a bargain for their compute intensive offline/batch workloads that are much more tolerant of preemption.

Given that the spot prices seem to be very flat, and preemption is rare, amazon presumably have a fair bit of underutilized capacity, does anyone know if amazon uses this capacity themselves, or offers more aggressive spot pricing to select clients?

Re: Designing a scalable API on AWS spot instances

#63

Post by qeternity » Fri, Jul 24, 2020, 8:21 AM UTC

quicksilver03 wrote: post #56

qeternity wrote: post #47

Earlier quoted context omitted.

This is not true at all. We run a large setup in OVH Gravelines and another in us-east-1 and we’ve not had a single outage in 3+ years with OVH. I can’t say the same for AWS.

You have been lucky with Gravelines, OVH had major outages lasting several hours in 2017 (Roubaix, total loss of routing for all of the 6 DCs) and in one case close to 24 hours (Strasbourg, cascade of events resulting in total power failure http://status.ovh.net/?do=details&id=15162 ). In that period (2015-2018) I used to run a fairly well known French website on OVH, and their network was very unstable, from equipme…

We stayed away from Roubaix given the experimental design. Not sure why anyone would put production stuff there. I can’t speak to Strasbourg that sounds horrendous. But Gravelines has been rock solid and 4ms latency to London.

But at the end of the day outages happen everywhere, including AWS. We also have some kit at Hetzner and I think that a redundant setup across OVH and Hetzner will be a fraction of a cost of single AZ setup in AWS and yield far greater uptime.

We’ve commoditized the servers and services (cattle vs pets)...why would we treat the providers any differently? Use cheap components and lots of redundancy.