Hacker News Reader

Comment by musingsole | Hacker News Reader

You increase the usage of the lambda, sure, but not by double unless all this lambda does is respond to the search. There's a point where this is all semantics when running cloud services with regard to how you've deployed your code behind gateways and lambdas, but most applications have obvious triggers that could warm up a lambda at 10% or less overhead.

And even then....lambdas are dirt cheap.

View on HN

Lambdas can be dirt cheap if you use them well. But that's always what happens. I recently saw a report about contractor who used them for crawling websites. Their client saw a surprise $12k bill for Lambda, when a simple Scrapy crawler on a low-end instance would have cost them < $100/month for the same load.

Why? Because if you spin up a ton of Lambda invocations and have them sit around waiting for the network, you pay for each CPU to sit idle, rather than having just one CPU stay busy managing a bunch of async IO.

Couldn't this also have been handled efficiently in Lambda had it been configured to use batching? (Assuming it was implemented as async invocations driven by a queue of some sort.)

It does seem unfortunate that Lambda cannot be configured to support concurrent synchronous invocations for serving HTTP requests concurrently.

This is a bit like asking if you can make a coal-rolling pickup truck more environmentally friendly by letting your friends carpool with you.

Technically, yes, but it's kinda missing the point.

I guess you're paying a 5x premium for Lambda in the constant usage scenario, a similar premium as on-demand vs spot instances.

4GB m6g.medium $0.0385/hour

4GB Lambda works out at $0.1920/hour

It's been a while since I last used queue driven autoscaling groups, but https://aws.amazon.com/blogs/compute/scaling-your-applicatio... has startup time of about 4 minutes from scratch or 36s from a paused instance in a 'warm pool.' vs less than a second for Lambda in the original article. So the decision ends up coming down to responsiveness vs cost. Presumably Fargate comes somewhere in between.

This is poor architecture, not Lambda's fault.

Same result would be achieved by paying tons of $$ for a high-end machine with dozens of cores, just to scrape one URL per core.

They could have implemented asyncIO within just a few Lambdas - heck even one Lambda could certainly handle hundreds, if not thousands of ASYNC jobs at once, just as a cheap machine, as you pointed.

They treated Lambda functions as threads or async jobs, while they should be looked at as core processors.

I didn't say it was Lambda's fault. Indeed, I said Lambdas can be cheap if you use them well. The implication being that some people don't.

Sure. But isn't this valid to any tech? As I pointed, one could make stupid use of expensive machine with dozens of cores as well...

Right, but at least with the expensive machine, one is making a conscious decision to spend a certain, known amount.

Exactly. These people thought they were using the tech well. They weren't. I like stories of tech gone wrong as examples to learn from. I thought others might as well.

I'm not sure I understand the point about asyncIO: yeah, the Lambda CPU isn't spinning, but don't they count actual runtime? So even if things are async, the Lambda still needs to be up to respond to the event when the async IO is finished.

Or do you mean handling things in an async way and Lambda passing the info on to another computing environment?

I think what they're talking about is using one Lambda to persist, handling many crawl requests. That doesn't make a ton of sense, as each Lambda has to make sure to push all its results and shut down before the max timeout is up, but it would technically work and be more efficient than what I described. Much better, though, just to use long-running spot instances, though, or just a regular instance running something like Scrapy.

Reply on news.ycombinator.com