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

AWS Introducing Provisioned Concurrency for Lambda Functions

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 74 posts

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#21

Post by momania »

tybit wrote: post #17
gcatalfamo wrote: post #13

Sorry for the stupid question, I genuinely want to know: how does this differ from firing up your function with an additional call every, idk, 5 mins? Wouldn’t it be cheaper and easier?

This works beyond a scale of 1, e.g if you want to be ready for 100 concurrent invocations using ping it’s quite difficult to do that I imagine. Also presumably more reliable. With the 5 minute ping the underlying container will be reprovisioned every few hours. At which point it’s a race to see whether the next ping comes before the real user request to swallow the cold start.

And what if I fire 500 concurrent keep-alive's? (Or maybe a bit of overhead). Then the 500 lambda instances will stay alive for a couple of minutes again, but I'm still only charged the 500 calls. Not the Gb/sec the rest of the time the labmda's are alive, right?

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#22

Post by piva00 »

matteuan wrote: post #20
dillondoyle wrote: post #11

Earlier quoted context omitted.

Honest question not being sarcastic: if this cold start latency is so important why chose function over elastic beanstalk or other auto-scaling type system? Answer could help us try something new. We currently use large google app engine 'apps' after failing to get functions to scale quick enough (and hit limits). we have SUPER bursty traffic that needs to scale up to hundreds of instances very fast.

> if this cold start latency is so important why chose function over elastic beanstalk or other auto-scaling type system? Pricing! It depends on the application, but there are some use-case where Lambda is way cheaper, so if we can also partially solve cold start latency, why not?

Way cheaper given a particular workload and access pattern*, Lambda is not magical and its pricing is tricky to figure out until you have something running.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#23

Post by reilly3000 »

With Fargate Savings Plans and Spot Instances, the cost of running workloads on Fargate is getting substantially cheaper, and with the exception of extremely bursty workloads, much more consistently performant vs Lambda. The cost of provisioning Lambda capacity as well as paying for the compute time on that capacity means Fargate is even more appealing for high volume workloads.

The new pricing page for lambda ("Example 2") shows the cost for a 100M invocation/month workload with provisioned capacity for $542/month. For that same cost you could run ~61 Fargate instances (0.25 CPU, 0.5GB RAM) 24/7 for the same price, or ~160 instances with spot. For context I have ran a simple NodeJS workload on both Lambda and Fargate, and was able to handle 100M events/mo with just 3 instances.

Serverless developers take note: its time to learn Docker and how to write a task-definition.json.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#24

Post by mactunes »

momania wrote: post #21
tybit wrote: post #17

Earlier quoted context omitted.

This works beyond a scale of 1, e.g if you want to be ready for 100 concurrent invocations using ping it’s quite difficult to do that I imagine. Also presumably more reliable. With the 5 minute ping the underlying container will be reprovisioned every few hours. At which point it’s a race to see whether the next ping comes before the real user request to swallow the cold start.

And what if I fire 500 concurrent keep-alive's? (Or maybe a bit of overhead). Then the 500 lambda instances will stay alive for a couple of minutes again, but I'm still only charged the 500 calls. Not the Gb/sec the rest of the time the labmda's are alive, right?

How do you ensure that the 500 concurrent keep-alives land on different Lambda functions? I.e. requests 220 and onwards might hit lambda functions which were warmed up by requests 0-219. I just made the above numbers up of course.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#25

Post by leovingi »

Am I misunderstanding something here? Based on the AWS calculations on the Lambda pricing page, a single 256Mb Lambda would incur a cost of $2.7902232 per month, using "provisionedConcurrency: 1". Pushing it to 3008Mb, to get access to more processing power, makes that go up to $32.78 per month (EU London region). Compared to the standard way of warming it up by hitting the endpoint once every 5 minutes, which comes out to 8640 calls per month, which costs next to nothing.

Unless I am terribly mistaken, it doesn't seem like allowing AWS to handle this and not doing it in code (warmup plugin, cron job, etc.) is worth the cost.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#30

Post by viraptor »

leovingi wrote: post #25

Am I misunderstanding something here? Based on the AWS calculations on the Lambda pricing page, a single 256Mb Lambda would incur a cost of $2.7902232 per month, using "provisionedConcurrency: 1". Pushing it to 3008Mb, to get access to more processing power, makes that go up to $32.78 per month (EU London region). Compared to the standard way of warming it up by hitting the endpoint once every 5 minutes, which comes…

It really depends on how much a fast request is worth to you. With a manual ping, you can keep only one function alive. In the worst case you may actually block your existing function with that ping which causes another instance to be spawned for real requests (and experience slow startup there).

The timed pings are just a hack and don't solve all the issues.

Post reply on HN