Hacker News Reader

Comment by ricketycricket | Hacker News Reader

> 2. Lambda has provisioned capacity.

I know little about lambda. Provisioned capacity, as in an instance running 24/7? Like a server?

It’s more like you have one Lambda instance that is always running (sure think of it like one server) that can serve the first page instantly while the other ten thousands Lambdas take half a second to warm up. That first Lambda responds instantly so it hides the half second response for the rest of the application.

It really makes sense if you have traffic that spikes at certain times per day (think like fantasy football). There’s going to be times when no one is using your application but when they do, there are going to be dozens or hundreds of people suddenly using it. So the first person that logs on hits the provisioned Lambda instantly and then AWS warms up the rest of the Lambdas as more traffic comes in.

We experimented with Lambda and found it completely unsuitable for any workload that has a "thundering herd" problem. If you go from zero to 1,000 requests/second then it can take up to 30 minutes to fully scale for that inbound traffic. And pre-provisioning for that sudden peak concurrency is very expensive. I think Lambda probably has its place in some kind of backoffice task runner architecture, but it's really not good for serving web traffic that might be occasionally spiky.

And you couldn't directly integrate with other services?

Have you talked to AWS about why that's the case? AWS Lambda should handle that order of magnitude just fine, as you have an initial burst concurrency quota of at least 500 requests per region (which you also can request to get increased). After that scaling should be additional 500 concurrent requests per minute. [1]

[1]: https://docs.aws.amazon.com/lambda/latest/dg/invocation-scal...

I think so, that's why I usually try to avoid it.

But I guess it's the last resort if you absolutely have to use a Lambda without cold-start

Reply on news.ycombinator.com