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

31–40 of 74 posts

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#31

Post by moduspol »

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

AFAIK it's not a solution, it's just a workaround.

As others have said, the previous workaround was a cron event that would invoke a function every few minutes to keep it warm. This is a lot better than that.

They're still working to get cold starts as fast as possible, but this helps a lot in the meantime.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#32

Post by moduspol »

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.

The other responses to your comment are good, but another point:

They also support autoscaling the provisioned concurrency. See here:

https://docs.aws.amazon.com/autoscaling/application/userguid...

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#33

Post by WatchDog »

soamv wrote: post #12

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 c…

I doubt there are that many people that want a provisioned concurrency of greater than one.

If you have a reliable base-load of a few requests a second and you don't have some constraint that forces you to use lambda, you are going to get much better value running your application on ecs/ec2.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#34

Post by WatchDog »

karavelov wrote: post #14
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.

Even if it were not frozen, the idle "Provisioned Concurrency" price is still more than paying for an active on-demand ec2 instance.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#35

Post by WatchDog »

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…

I am curious how, without actually invoking the function, lambda knows when your application has been initialized. Does it just run your application for a few seconds and then freeze it? Or does it not even run the application code, merely ensure the virtual machine is loaded into memory ready to be run? It seems a periodic warmer invocation at least has the advantage of ensuring your app is fully initialized and ready to respond to requests.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#36

Post by scarface74 »

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…

Pinging the lambda to keep it warm doesn’t do the same thing.

When you do that, it only keeps one instance warm. If you have 10 concurrent requests, even if one is warm, the other 9 requests will still experience a cold start.

The only way around this is to send a request that holds the connection open long enough to make sure concurrent requests start a new lambda instance. While you are keeping the request open, that lambda instance isn’t available for a real call.

If the entire purpose of lambda is to make things easier, once you start down the Rube Goldberg path of trying to keep enough instances warm, it kind of defeats the purpose. Just spend the money and the time to set up an autoscaling group of the smallest instances of EC2 or use Fargate if you don’t want the cold start times.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#37

Post by momania »

mactunes wrote: post #24
momania wrote: post #21

Earlier quoted context omitted.

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.

That's why I mentioned 'with maybe some overhead'. You can also have the keep-alive handling take a second or 2 extra to complete, to have the lambda blocked for this time, so the burst calls get more spread. It's not going to be a precise solution, but still, paying 2-3 seconds every minute instead of paying the whole minute is still a lot cheaper.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#38

Post by macintux »

msftie wrote: post #10
macintux wrote: post #5

Request for anyone on the Lambda team who happens to read this: your API doesn’t appear to offer a way to retrieve the “last modified by” user when grabbing function metadata. Very unlike other AWS APIs and very annoying.

Which API specifically are you referring to (GetFuntionConfiguration ?), and which APIs are you comparing it against?

Examples of APIs that provide a "LastModifiedUser" result:

* https://docs.aws.amazon.com/systems-manager/latest/APIRefere...

Huh. Turns out fewer of the ones I use than I thought provide that level of detail. That just happens to be the closest approximation of what I'm currently trying to automate.

Anyway, there are several API endpoints in Lambda which supply "LastModified" but none that I can find supply "LastModifiedUser".

* https://docs.aws.amazon.com/lambda/latest/dg/API_GetFunction...

* https://docs.aws.amazon.com/lambda/latest/dg/API_GetFunction...

* https://docs.aws.amazon.com/lambda/latest/dg/API_ListFunctio...

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#39

Post by scarface74 »

reilly3000 wrote: post #23

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 ("Exam…

I agree, but you don’t need to learn how to use a task-definition file. I would actually advise against it. You can create your entire Fargate environment with CloudFormation.

Re: AWS Introducing Provisioned Concurrency for Lambda Functions

#40

Post by mwarkentin »

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…

Apparently you get a discount on the execution time for provisioned lambdas, not sure how much this would offset (the more actual utilization you get the better I guess)

> @ben11kehoe @kondro @mwarkentin You pay for the configured Provisioned Concurrency with a flat hourly charge. Lambda usage gets billed the same, but with a discount on unit pricing ($0.035/GB-hour vs $0.06 on "on demand").

http://twitter.com/ajaynairthinks/status/1202125357144391680

Post reply on HN