Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing a scalable API on AWS spot instances

blog.adapty.io

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Designing a scalable API on AWS spot instances

#41

Post by [deleted] »

marcinzm wrote: post #18
dijit wrote: post #8

Earlier quoted context omitted.

The solution to saving costs is to go for cheaper cloud providers or run k8s on VPS's/colocated physical hardware. I'm not sure where the idea came from that this is hard to do. To answer your questions in order: 1) People warned aggressively about lock-in of cloud providers with proprietary extensions and you must have chosen not to listen; so, I have little sympathy. I'm not saying it's black and white; but I hope…

Now you have five more things you need to research, learn, keep track of, debug, etc. Plus, in my experience, anyone who says kubernetes is easy to run (cloud or native) has never had to run kubernetes in production.

[deleted]

Re: Designing a scalable API on AWS spot instances

#42

Post by csunbird »

jorams wrote: post #38
csunbird wrote: post #15

Earlier quoted context omitted.

is it that bad? we are thinking about bootstrapping a project, which will use spaces for file storage and we will be using them frequently.

It was that bad 2 years ago, in the AMS3 region. I don't know how it is these days, but I expect after 2 years it has matured at least a little bit. They also now include a CDN, which might improve things a bit if it reduces the load on the buckets behind it. Honestly it soured my opinion on DO a bit. I'd previously had a droplet there for several years, which never seemed to experience any issues at all.

In our case, we can not use the CDN, unfortunately, because the objects change a lot.

Re: Designing a scalable API on AWS spot instances

#43

Post by gridlockd »

CSDude wrote: post #13
makkesk8 wrote: post #3

"Our backend system is built on AWS. Today I’m going to tell you how we had cut costs" This is a recurring topic here on HN and it boggles me and makes me wonder if people know that there are other platforms than aws, azure and google cloud out there that are very capable and much much cheaper. Unless any of the big 3 has a feature or certification you need I don't see any reason to use them at all due to the insane…

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.

Re: Designing a scalable API on AWS spot instances

#44

Post by Epixors »

l33tman wrote: post #28
ollyculverhouse wrote: post #7

Earlier quoted context omitted.

AFAIK with Fargate a lot of this is handled for you, as long as you have the auto scaling group. We have this setup with two capacity providers (FARGATE_SPOT and FARGATE) with a 75/25% split, meaning that even if there are no spot instances available we will still be up. The benefit of Fargate being that we don't need to care if certain instance sizes are not available as that is handled by AWS.

Cool, when fargate launched they didn't have a spot possibility (AFAIK) and since we run ECS on Spot instances it would just be a massive increase in cost to switch to FG, but if it now can use underlying spot instances, it might be worth looking at again..

Yeah spot capacity providers for Fargate only got added a few months ago, been running well for us in production.

Re: Designing a scalable API on AWS spot instances

#45

Post by pm90 »

makkesk8 wrote: post #3

"Our backend system is built on AWS. Today I’m going to tell you how we had cut costs" This is a recurring topic here on HN and it boggles me and makes me wonder if people know that there are other platforms than aws, azure and google cloud out there that are very capable and much much cheaper. Unless any of the big 3 has a feature or certification you need I don't see any reason to use them at all due to the insane…

I don't think moving cloud providers is an effective way to solve for cost problems; especially considering the engineering cost involved in making these migrations, which reduce the marginal utility of such a migration to 0, possibly even If you're really looking to save on costs, hosting solutions (i.e. hosting racks or some managed solution) are probably what you would need to look at. But then there are other costs involved there as well (infrastructure team, upfront capex costs etc.), but it might still be worth it if you run e.g. a ton of batch processing over a ton of data.

Re: Designing a scalable API on AWS spot instances

#46

Post by saddlerustle »

duggan wrote: post #33
dijit wrote: post #25

Earlier quoted context omitted.

AWS S3 buckets have a limit of 5gb/s access to a single bucket. Unless that limitation has changed in the last couple of years; I can easily make a system beat that, if that's the requirement.. and ultimately it does come down to understanding requirements. :\ I think generally people forget that cloud is just computers too, it's really not anything special, and amazon/google/microsoft are solving the general case (a…

It's 25Gbps now[1]. I have a rule of thumb: if I haven't refreshed something I think I know about AWS for more than half a year, it's probably out of date. [1]: https://aws.amazon.com/premiumsupport/knowledge-center/s3-ma...

That the throughput available to a single EC2 instance. S3 as a whole will do hundreds of Gbps no problem.

Re: Designing a scalable API on AWS spot instances

#47

Post by qeternity »

CSDude wrote: post #13
makkesk8 wrote: post #3

"Our backend system is built on AWS. Today I’m going to tell you how we had cut costs" This is a recurring topic here on HN and it boggles me and makes me wonder if people know that there are other platforms than aws, azure and google cloud out there that are very capable and much much cheaper. Unless any of the big 3 has a feature or certification you need I don't see any reason to use them at all due to the insane…

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.

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.

Re: Designing a scalable API on AWS spot instances

#48

Post by speedgoose »

jrockway wrote: post #39
speedgoose wrote: post #16

Earlier quoted context omitted.

That's not a very common use case though. Most companies don't need to DDOS their cloud provider.

25Gbps is 250 cable Internet users downloading the release of your new software. What you call a DDOS is actually a woefully underwhelming instantaneous transfer rate.

You should put your objects storage behind a CDN if you expect that many downloads. That's much cheaper and faster.

Re: Designing a scalable API on AWS spot instances

#49

Post by Epixors »

jrockway wrote: post #39
speedgoose wrote: post #16

Earlier quoted context omitted.

That's not a very common use case though. Most companies don't need to DDOS their cloud provider.

25Gbps is 250 cable Internet users downloading the release of your new software. What you call a DDOS is actually a woefully underwhelming instantaneous transfer rate.

If you're distributing releases (or anything, really) users should not have to go directly to your object store...

Re: Designing a scalable API on AWS spot instances

#50

Post by jungturk »

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.

EC2 might be a glorified VPS provider, but you seem to be ignoring the vast array of managed services in modern cloud providers (or unaware of their utility beyond padding resumes).

Load balancing, fault tolerance, high availability, arbitrary scale, messaging, orchestration, autoscaling, warehousing, big data processing, identity management, desktop management, secrets management, container registries, source code management, build tools, hardware test suites, gpu hardware, observability tools...

Those of use that use cloud providers know full well why we use them (and certainly know when not to).

Post reply on HN