6 ms·

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.

jlouis 6y ago
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.
yowlingcat 6y ago
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.
- donor20 6y ago
  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
  - yowlingcat 6y ago
    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.
  - Cpoll 6y ago
    > 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).
BoorishBears 6y ago
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?
generj 6y ago
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.
jedberg 6y ago
Bin packing. It's a lot easier to distribute workloads around a cluster of compute if you can guarantee the maximum runtime.
munns 6y ago
How long would you like it to be? Chris Munns - Lead of Dev Advocacy for Serverless@AWS
- staticassertion 6y ago
  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.
  - munns 6y ago
    Today, for a nonstop workload you might save money with Fargate or ECS.
    - staticassertion 6y ago
      Yeah, I'd be curious to see how much money we'd save with Fargate.
      - jeffcarter 6y ago
        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
      - matwood 6y ago
        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.
alex_duf 6y ago
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.
tanilama 6y ago
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)

jlouis 6y ago

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.

yowlingcat 6y ago

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.

donor20 6y ago
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
- yowlingcat 6y ago
  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.
- Cpoll 6y ago
  > 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).

BoorishBears 6y ago

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?

generj 6y ago

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.

jedberg 6y ago

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

munns 6y ago

How long would you like it to be? Chris Munns - Lead of Dev Advocacy for Serverless@AWS

staticassertion 6y ago
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.
- munns 6y ago
  Today, for a nonstop workload you might save money with Fargate or ECS.
  - staticassertion 6y ago
    Yeah, I'd be curious to see how much money we'd save with Fargate.
    - jeffcarter 6y ago
      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
    - matwood 6y ago
      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.

alex_duf 6y ago

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.

tanilama 6y ago

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)