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

AWS Lambda pricing now per ms

aws.amazon.com

Post reply on HN
Print view View original

111–120 of 291 posts

Re: AWS Lambda pricing now per ms

#111

Post by staticassertion »

Dunedan wrote: post #105
staticassertion wrote: post #66

Earlier quoted context omitted.

My lambdas run indefinitely. It's a bit silly, but basically every lambda spins up a bunch of threads, pulls messages, and then pushes them into internal buffers to be processed. There are reasons for this. What I care about is: * Scale to 0, and automatic scaling up without configuring it * Automatic patching of the OS * Fault isolation Lambda gives me that. So each one runs for 15 minutes, processing all data in an…

If you want sequential processing of the data in the SQS queue, something which works really well today is to create a state machine in AWS Step Functions which triggers a AWS Lambda function which then pulls data from SQS and processes it. Using a condition in the state machine, this can be done in a loop, so when the AWS Lambda function reaches its timeout, another one gets triggered as long as there is still data…

Yep, but I prefer to care about manually fetching data from SQS. It's a weird system, but due to our data model there are many benefits to processing as many messages in a given lambda as possible.

Re: AWS Lambda pricing now per ms

#112

Post by game_the0ry »

valbaca wrote: post #48
brunoluiz wrote: post #18

I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS

From the research I did, here's how languages stack up in Lambda runtime (lowest first): 1. Python & JS 2. Go 3. C# & Java I couldn't find any data on Rust. The understanding at the time was that Python & JS runtimes are built-in, so the interpreter is "already running" Go is the fastest of compiled languages, but just can't beat the built-in runtimes. C# and Java were poorest as they're spinning up a larger runtime…

Interesting, thanks for sharing! This is the opposite of what most people would expect.

Re: AWS Lambda pricing now per ms

#113

Post by qvrjuec »

throwaway894345 wrote: post #75
alpha_squared wrote: post #47

Earlier quoted context omitted.

Lambdas are underpowered and often poor choices for compute-heavy workloads. Unless there's an urgency to processing infrequent videos, it might make more sense to backlog messages to the queue and use spot instances for draining the queue and processing videos, especially from a cost perspective. Though I acknowledge that this is a more complex setup.

I haven’t heard that lambdas are “underpowered” before, but I’m interested to learn more. Could you elaborate just a bit on why they are underpowered?

Limitations on hardware one can run a lambda function on and constraints on execution time mean they are "underpowered" compared to other options, like ECS Fargate tasks.

Re: AWS Lambda pricing now per ms

#114

Post by jacques_chester »

alexeldeib wrote: post #99
donor20 wrote: post #38

Earlier quoted context omitted.

They would be willing to do this probably if you let them evict your entire workload from memory during the period you were not paying for it, and then were able to charge you for CPU time and some additional charge to reload workload into memory from hibernation. Most workloads ALSO hold memory (which is a key constraint) over the entire wall clock time, and the delays and impacts/costs of hibernating out the memory…

They could also charge you some rate for CPU seconds + Gb-seconds of memory used? Sort of the ultimately flexible cloud platform. You could apply the same sort of thinking to other resources, but it works best for CPU/memory I think.

That would be ideal, as it more closely fits consumption to billing. But potentially harder for end users to reason about. AWS's bills are already notorious.

Re: AWS Lambda pricing now per ms

#115

Post by bt1a »

ignoramous wrote: post #106
munns wrote: post #101

Earlier quoted context omitted.

No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think. They aren't brought up in any of the convos I have with customers.

But you're telling us that Lambda's prices are justifiably higher because of the strong vendor lock-in? AWS is starting to sound more like Oracle. Ironic. :) Besides the fact that Cloudflare's part of the Bandwidth Alliance with GCP and other infrastructure providers from which AWS is conspicuously absent, Cloudflare's also slowly but surely building a portfolio of cloud services.

Woof :)

Re: AWS Lambda pricing now per ms

#116

Post by tgv »

philosopher1234 wrote: post #34
tgv wrote: post #26

Earlier quoted context omitted.

I've got bad experiences with go startup (i.e., cold runs). They're much more expensive than I would have expected. If node can indeed run in 40ms (as https://news.ycombinator.com/item?id=25267211 says), then I'm surely going back to JS.

What is your experience? Go is an AOT compiled language so the only thing I could imagine you running into on startup is loading the binary into memory? Theres not a cold-start issue with Go, as its not an optimizing JIT. Edit: Bizarre. Seems like Go on lambda does actually have slower cold start than JS or Python. I wonder if its just that the binary is likely larger than the equivalent JS source code? https://level…

My experience is that Go cold start takes around 900ms. Processing (parsing a JSON message, verifying it with one DynamoDB look-up, and storing it in DynamoDB) then takes between 11ms and 105ms. Go does use less memory than node, though, and that also counts in Lambda.

I hadn't expected it either, but it loads node faster. Perhaps via some VM trick?

Re: AWS Lambda pricing now per ms

#117

Post by brianwawok »

dumbfounder wrote: post #58
jedberg wrote: post #37

Earlier quoted context omitted.

If you're running it continuously for a year, then you should probably be using a reserved instance and not lambda. Lambda is for short bursts, not 1 year of continuous use.

Not necessarily, especially in a large company setting. Lambda allows you to scale and take care of spikey traffic. It also doesn't require server management. Servers are a pain in the butt.

True, but ECS and K8s both abstract aware the hardware and offer cheaper 24/7 workloads and get past the cold start problem (at the expense of slower spike responses).

Re: AWS Lambda pricing now per ms

#118

Post by jlg23 »

narag wrote: post #87
jlouis wrote: post #6

Necessary change. Now writing stuff in fast languages suddenly matter in cost, changing the landscape of when these solutions might become viable for a chase.

I've been here for a while resisting the temptation to write a sarcastic comment. Speed has been the opposite of what matters for decades. Every change is always trading speed for something else. And suddenly some offer by Amazon is going to change that? Seems unlikely.

Speed has always mattered, though I agree we are light-years away from optimization levels once considered standard. OTOH, so are we WRT complexity of applications.

Amazon is not going to change software development per se, but at least at some of their customers' sites calculations will be done how many hours can be allocated for a n% reduction in runtime. So, if you live in an amazon-universe, this is a real "game changer". Bystanders may chuckle ;)

Re: AWS Lambda pricing now per ms

#120

Post by tnolet »

Swizec wrote: post #41
brunoluiz wrote: post #18

I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS

JS is a great choice for Lambda thanks to great cold performance. I’m seeing runtimes in the 40ms to 100ms range. Most of the time in Lambda is usually spent waiting for IO, which is slow in any language. If you’re using Lambda for heavy computation, that’s not a great choice.

Yep, we ran ~50M Node invocations last month on a small function. AVG was around 100ms but lots of sub 50ms invocations too.
Post reply on HN