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

51–60 of 63 posts

Re: Designing a scalable API on AWS spot instances

#51

Post by arecurrence »

There's an excellent implementation using AWS lambda to manage spot instances at https://github.com/AutoSpotting/AutoSpotting

What's fantastic about the autospotting implementation is:

1. It dynamically replaces existing instances with spot instances just by setting a tag

2. Rather than replacing the instance with a fixed spot instance type, it will choose the cheapest that fits the requirements.

3. If there are no spot instances available that fit the requirements, it will spin up on demand instances until spot instances are available.

If you have experience working with spot then you will know that these are really outstanding features that hopefully amazon will bake-in in the future.

Re: Designing a scalable API on AWS spot instances

#52

Post by aripickar »

dijit wrote: post #20
marcinzm wrote: post #18

Earlier quoted context omitted.

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.

Sure, then pay? I don't understand the argument: "I want to outsource understanding but I want to save costs"; You can think of things as a spider-graph of three points: Quality -- Low-Cost -- Knowledge-Required. No solution can score high points on all three reasonably. Anyway, things are a bit skewed because I'm an infrastructure type, and people in my profession really do think of systems administration tasks as b…

I disagree. Once you increase your knowledge of AWS and associated systems, you can decrease cost of what you are doing through tips like what you see in this article. I don't quite get the point about optimizing cloud costs solely by switching to self hosted? Like of course you could do that, but you could also optimize costs by doing what the article says.

Full Disclosure: I work at AWS building tools to help customers do cost optimization.

Re: Designing a scalable API on AWS spot instances

#53

Post by [deleted] »

jungturk wrote: post #50
gridlockd wrote: post #43

Earlier quoted context omitted.

> 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 m…

[deleted]

Re: Designing a scalable API on AWS spot instances

#54

Post by gridlockd »

jungturk wrote: post #50
gridlockd wrote: post #43

Earlier quoted context omitted.

> 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 m…

If you really need any of that stuff you probably shouldn't use Amazon's managed version of it.

Re: Designing a scalable API on AWS spot instances

#55

Post by luhn »

MrPowers wrote: post #14

Great article. Cutting ec2 costs is important, especially for companies with heavy data engineering / data science workflows. Spark service providers make it easy to spin up huge clusters (100+ nodes) to perform ad hoc analyses. The costs can quickly spiral out of control, even if you're getting 3x cost savings on the spot market. Some tangential thoughts: * Is there an AWS API that returns the cheapest availability…

I'm not aware of any API (surprising for AWS), but you use Spot Fleet to get an array of spot instances optimized for cost.

Having a bid above spot price does not guarantee you'll keep the spot instance. AWS can terminate a spot instance at any time if they need the capacity—That's the deal. It used to be more closely tied your bid price, but they've been moving away from that.

Re: Designing a scalable API on AWS spot instances

#56

Post by quicksilver03 »

qeternity wrote: post #47
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.

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 equipment failures to way too many fat-fingering of routes. If you're able to easily switch traffic between OVH and AWS you're in a far better position than most people.

Re: Designing a scalable API on AWS spot instances

#57

Post by Pfhreak »

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.

There should be data available for #1 -- it's not something we should need much subjective discussion around.

Re #2: I love all the other stuff. I never use EC2. Lambda, Cognito, DynamoDB, S3, CloudFront, Route 53, and API Gateway are my default stack, managed by Cloudformation. Granted, I'm doing smaller projects, but the costs are minimal, the setup time is trivial, the documentation is excellent, everything is nicely compartmentalized and 'just works' together. And I only pay for the actual traffic to the site.

Re: Designing a scalable API on AWS spot instances

#58

Post by rospaya »

gridlockd wrote: post #54
jungturk wrote: post #50

Earlier quoted context omitted.

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 m…

If you really need any of that stuff you probably shouldn't use Amazon's managed version of it.

Why? I run both on prem and cloud workloads (on more than one provider) so I'm wondering what's wrong with Amazon's managed services?

Re: Designing a scalable API on AWS spot instances

#59

Post by parsnips »

Pfhreak wrote: post #57
gridlockd wrote: post #43

Earlier quoted context omitted.

> 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.

There should be data available for #1 -- it's not something we should need much subjective discussion around. Re #2: I love all the other stuff. I never use EC2. Lambda, Cognito, DynamoDB, S3, CloudFront, Route 53, and API Gateway are my default stack, managed by Cloudformation. Granted, I'm doing smaller projects, but the costs are minimal, the setup time is trivial, the documentation is excellent, everything is nic…

This is the way. We've given multiple clients very similar stacks for "api layers" and it's by far the most cost effective way to do AWS from both productivity and opex point of view.

Re: Designing a scalable API on AWS spot instances

#60

Post by ethanwillis »

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.

It's less reliable than a guy running a website on a raspberry pi with a solar panel from harbor freight http://pi.qcontinuum.com/
Post reply on HN