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

11–20 of 74 posts

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#11

Post by dillondoyle »

etaioinshrdlu wrote: post #8

This feels like a step backwards to me, nevermind how necessary it may be. The magic was paying only for what you use on super bursty workloads. Now this is like throwing your hands up and saying the users bursts are too big for AWS.

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.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#12

Post by soamv »

Lambda has always been the most expensive compute you can buy on AWS -- you could think of that as the premium for being the most "elastic". So this feature is about giving away some of that elasticity for (a) performance predictability and (b) a bit of total cost savings. Note that you can still happily "burst" into exactly as much concurrency as you could before, you'll just have cold starts.

People used to write cron jobs to keep their functions warm, which besides being ugly didn't even work well -- you could at best keep one instance warm with infrequent pinging, i.e. a provisioned concurrency of 1. So this feature addresses that use case in a much more systematic way.

There's some precedent for features like this -- provisioned IOPS and reserved instances come to mind. In both those cases you tradeoff elasticity and get some predictability in return (performance in one case, cost in another).

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#14

Post by karavelov »

nexuist wrote: post #7

I am a huge fan of serverless, and AWS as well. I also find it deeply ironic that their solution to cold starts is to keep the function running 24/7... Could I include openssh and Apache in my Lambda instance? Maybe run a Minecraft server? :P

Your function is frozen if there is no active invoke in progress. So no, ssh or minecraft server will not work, unless you make them communicate over Lambda invocations.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#16

Post by soamv »

etaioinshrdlu wrote: post #8

This feels like a step backwards to me, nevermind how necessary it may be. The magic was paying only for what you use on super bursty workloads. Now this is like throwing your hands up and saying the users bursts are too big for AWS.

No, this isn't about how much you can burst -- the maximum concurrency is still the same.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#17

Post by tybit »

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.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#19

Post by matteuan »

etaioinshrdlu wrote: post #8

This feels like a step backwards to me, nevermind how necessary it may be. The magic was paying only for what you use on super bursty workloads. Now this is like throwing your hands up and saying the users bursts are too big for AWS.

You can continue to pay only for what you use and handle super bursty workloads. But there is no free solution to cold-start if you don't see the future. People needing consistent latency were already doing something similar to keep the containers alive or they just avoided to use Lambda. So I think it's a step forward.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#20

Post by matteuan »

dillondoyle wrote: post #11
etaioinshrdlu wrote: post #8

This feels like a step backwards to me, nevermind how necessary it may be. The magic was paying only for what you use on super bursty workloads. Now this is like throwing your hands up and saying the users bursts are too big for AWS.

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?
Post reply on HN