Hacker News Reader

Comment by yeldarb | Hacker News Reader

Anyone know why there's a hard limit of 15 minutes for Lambda (and 9 minutes for Google Cloud Functions)? Still seems really weird to me.

View on HN

Safety.

No function runs forever.

Also if you want to reboot/repurpose the server, 15 minutes is max wait time.

And finally, you don't want people running long jobs here when you have a solution there.

Bin packing. It's a lot easier to distribute workloads around a cluster of compute if you can guarantee the maximum runtime.

If I had to imagine designing a system like Lambda, people running really long operations would really throw a wrench in things.

Maybe you could let users indicate the operation will take a long time... but if the user knows the operation is long running in advance, why not just guide them to a more suitable system?

One way around this limitation while still using server less (for Python only) are Glue python shell jobs. They can run for hours if not days, and default at 1 vCPU and 1GB of memory for 2.75¢ an hour.

To limit the scope, and type of applications people should use Lambda for and Lambda is best at running them.

15 mins max runtime simplifies the resource management and avoid abuse. If you have workload for long running jobs, then that should go to something like AWS EKS/Batch/SageMaker.

That being said, things can change, if more and more people requires long running capacity for Lambda (though I am skeptical of that, as Lambda abstracts the underlying hardware away and is supposedly flexible to the requirements)

How long would you like it to be?

Chris Munns - Lead of Dev Advocacy for Serverless@AWS

My lambdas run indefinitely. It's a bit silly, but basically every lambda spins up a bunch of threads, pulls messages, and then pushes them into internal buffers to be processed. There are reasons for this.

What I care about is: * Scale to 0, and automatic scaling up without configuring it

* Automatic patching of the OS

* Fault isolation

Lambda gives me that. So each one runs for 15 minutes, processing all data in an SQS queue.

I do wonder if Fargate would be cheaper per millisecond? Dunno.

Today, for a nonstop workload you might save money with Fargate or ECS.

Yeah, I'd be curious to see how much money we'd save with Fargate.

For raw compute, Fargate is ~1/2 the cost of Lambda. But you'd have to orchestrate the launch yourself. It could be worth it though depending on your workload

I'm going to assume since you're processing off a queue, the lambdas are not serving a waiting user. If you do the work to orchestrate onto Fargate, you might as well go the rest of the way and move to ECS. Then you can use spots, where real savings kick in.

Someone mentioned step functions above. All of our steps run on spots. We also have some tasks like you have that read off queues and do processing, which also all run on spots.

If you want sequential processing of the data in the SQS queue, something which works really well today is to create a state machine in AWS Step Functions which triggers a AWS Lambda function which then pulls data from SQS and processes it. Using a condition in the state machine, this can be done in a loop, so when the AWS Lambda function reaches its timeout, another one gets triggered as long as there is still data in the SQS queue.

If data doesn't have to be processed sequentially an option is to configure the AWS Lambda function to get invoked for new data in the SQS queue [1], so you don't have to care about manually fetching data from SQS at all.

[1]: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

Yep, but I prefer to care about manually fetching data from SQS. It's a weird system, but due to our data model there are many benefits to processing as many messages in a given lambda as possible.

This might be useful to simplify that model for you :)

https://aws.amazon.com/about-aws/whats-new/2020/11/aws-lambd...

Pretty cool, but not quite the model I want.

Now that someone's listening: I don't mind the 15min Lambda timeout, but it would be great to get rid of the Lambda + API Gateway 30s & ~6MB limits. Those always bite unaware devs in the butt and workarounds for them take quite a bit of effort.

Yes.

But being real, we hear you on this one. I can't comment on API Gateway's roadmap here but this is something both teams is aware of. The reason it is the way it is today is for a valid reason. But this is def something we hear pretty often.

- Chris

Make it indefinitly and price exponentially.

;)

thar be dragons :)

I have many workloads where 15 minutes may be just a little too short for comfort. A hour timeout would have me reaching for Lambda more often.

As long as possible. Our jobs usually finish well within the limit but the top 1% hit the limit.

One example we've been wrestling with is a merge operation. Usually it's merging about 1000 records which completes in a few seconds. But every once in a while someone kicks off a job that tries to merge 1,000,000 records and it times out.

We want the benefits of serverless (scale down to zero, up to infinity at the drop of a hat) but these edge cases mean we're having to evaluate other options.

An hour or two would be a good start; then it'd cover 99.9% of requests. With a few hours we could add more nines :)

That sounds like you need a queue of some sort

If your lambda function detects that it is going to hit the timeout you could have it launch a Fargate container to handle the long merge. Fargate is essentially a long-lived Lambda.

It’s also probably much easier to share code between those two implementations with the new container based lambdas :)

Lambda isn't designed for long running processes. Keeping the runtime limit lower makes it a lot easier to operate the underlying metal because you can move thing around every N minutes where N is the runtime limit. For long-running processes, something like Fargate might be a better fit in the AWS side of things.

Fargate works well especially after they fixed some of the pricing issues there. Then next step you can spin up a fleet of EC2 or EKS or something

Yup! In general, I prefer Fargate over Lambda because of cold starts. It's a little bit more management overhead over Lambda and it is a bit lower level. But I think it's worth it.

> Fargate works well especially after they fixed some of the pricing issues there.

Was this recent, should I take a look at this again? My issue with Fargate as recent as a year ago was that running the same workload on ECS (if you can use your cluster nodes efficiently) was twice as cheap (even without reserved instances).

It's a new pattern, so it's only relevant for some use cases. I don't think it's meant to solve every cases: including the case of a long running job.

It's best suited for jobs that can be broken down into tons of small individual computations, or to respond directly to HTTP requests. If you can fit your pipeline / application into that model it's usually beneficial: Instant scaling, retries, reliable etc. Mixed with other concepts like SQS you can build pretty powerful things without having to pay when there's no load.

Reply on news.ycombinator.com