4 ms·

Fargate is a very useful service for anyone hopping on the serverless/lambda train. Here's a simple use case: say you have a simple banking website with a fron

Fargate is a very useful service for anyone hopping on the serverless/lambda train. Here's a simple use case: say you have a simple banking website with a frontend and an API and whatever. People log in and check their balances, etc. Typically, this requires requests that take on the order of milliseconds, so lambda works for this [0]. However, every month, you want to go in and calculate what you owe in interest for everyone's account. Say that you have 100,000 users and it takes 0.01 seconds to do each calculation, so this job will take 1,000 seconds, or 16 minutes to run. Lambda functions are automatically killed after 15 seconds, so that won't work. That's where Fargate comes in. You dockerize your environment and then run a command in Fargate. Now, it runs for 16 minutes for the task itself + 1 or 2 minutes to wind up and then it automatically kills itself when it's done. You pay for the 16 minutes of run time and call it a day. [0] One issue with lambda/serverless is dealing with cold starts when your application hasn't been used in a while, or you need more concurrent instances running, so it takes some time to "warm up". This is a good reason not to use serverless frameworks in many cases, but I won't get into that.

alpha_squared 7y ago
Mild correction, but AWS lambdas are limited to 15 minutes of execution time as of October 2018 [0]. Prior to that, they were limited to 5 minutes. > One issue with lambda/serverless is... when you need more concurrent instances running... Lambda can have 1,000-3,000 concurrent burst invocations for most of the popular regions and 500 for others[1]. Are you saying that's not enough? [0] https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambda-supports-functions-that-can-run-up-to-15-minutes/ https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambd... [1] https://docs.aws.amazon.com/lambda/latest/dg/scaling.html https://docs.aws.amazon.com/lambda/latest/dg/scaling.html
- chucky_z 7y ago
  I recently had a use-case where that wasn't enough, and AWS would not give us enough concurrent invocations either.
- sten 7y ago
  I've run into this problem. But I believe the parent was referring to the situation where new lambdas spin up and aren't immediately ready to respond to invocations. The delay can be significant in some cases though almost immeasurable in aggregate.
- skywhopper 7y ago
  3000 is not really all that many, given the prime use cases for Lambdas. Though at that point you'll probably be running into lots of other issues as well.
- chadash 7y ago
  > Mild correction, but AWS lambdas are limited to 15 minutes of execution Whoops that's what I meant > Lambda can have 1,000-3,000 concurrent burst invocations for most of the popular regions and 500 for others[1]. Are you saying that's not enough? No, that's plenty for most use cases. I'm referring to "cold starts". When you haven't used a lambda function in a while, it takes a few seconds for it to get going. But when you hit it a second time, it responds more quickly.
jasonjei 7y ago
Wouldn’t it be better to break your tasks into smaller, discrete units instead of a 15 minute job, such as using a message queue (SQS)?
- koolba 7y ago
  If your unit of work is a transaction that takes 15+ minutes that's not possible. A common example is nightly ETL jobs that update the world.
  - notyourwork 7y ago
    That’s not a good use case for lambda.
    - koolba 7y ago
      Well duh. That's why the top level comment is saying, "That's where Fargate comes in...".
      - notyourwork 7y ago
        > If your unit of work is a transaction that takes 15+ minutes that's not possible. A common example is nightly ETL jobs that update the world. So what are you suggesting here?
- chadash 7y ago
  Yes, that's ideal. But: * Sometimes it's not efficient to break a task down or it simply can't be done. * Sometimes it just makes the code hard to maintain if breaking it down into different components is a difficult task An example I can think of is loading a very large CSV file into a database. Lambda doesn't have enough memory to read the whole file and even if it did, it might take more than 16 minutes to run. I can try to break it out into multiple tasks and it'll probably be faster, but reading that code is (generally) gonna be much harder.
airocker 7y ago
How is it different from k8s jobs and cronjobs?

alpha_squared 7y ago

Mild correction, but AWS lambdas are limited to 15 minutes of execution time as of October 2018 [0]. Prior to that, they were limited to 5 minutes. > One issue with lambda/serverless is... when you need more concurrent instances running... Lambda can have 1,000-3,000 concurrent burst invocations for most of the popular regions and 500 for others[1]. Are you saying that's not enough? [0] https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambda-supports-functions-that-can-run-up-to-15-minutes/ https://aws.amazon.com/about-aws/whats-new/2018/10/aws-lambd... [1] https://docs.aws.amazon.com/lambda/latest/dg/scaling.html https://docs.aws.amazon.com/lambda/latest/dg/scaling.html

chucky_z 7y ago
I recently had a use-case where that wasn't enough, and AWS would not give us enough concurrent invocations either.
sten 7y ago
I've run into this problem. But I believe the parent was referring to the situation where new lambdas spin up and aren't immediately ready to respond to invocations. The delay can be significant in some cases though almost immeasurable in aggregate.
skywhopper 7y ago
3000 is not really all that many, given the prime use cases for Lambdas. Though at that point you'll probably be running into lots of other issues as well.
chadash 7y ago
> Mild correction, but AWS lambdas are limited to 15 minutes of execution Whoops that's what I meant > Lambda can have 1,000-3,000 concurrent burst invocations for most of the popular regions and 500 for others[1]. Are you saying that's not enough? No, that's plenty for most use cases. I'm referring to "cold starts". When you haven't used a lambda function in a while, it takes a few seconds for it to get going. But when you hit it a second time, it responds more quickly.

jasonjei 7y ago

Wouldn’t it be better to break your tasks into smaller, discrete units instead of a 15 minute job, such as using a message queue (SQS)?

koolba 7y ago
If your unit of work is a transaction that takes 15+ minutes that's not possible. A common example is nightly ETL jobs that update the world.
- notyourwork 7y ago
  That’s not a good use case for lambda.
  - koolba 7y ago
    Well duh. That's why the top level comment is saying, "That's where Fargate comes in...".
    - notyourwork 7y ago
      > If your unit of work is a transaction that takes 15+ minutes that's not possible. A common example is nightly ETL jobs that update the world. So what are you suggesting here?
chadash 7y ago
Yes, that's ideal. But: * Sometimes it's not efficient to break a task down or it simply can't be done. * Sometimes it just makes the code hard to maintain if breaking it down into different components is a difficult task An example I can think of is loading a very large CSV file into a database. Lambda doesn't have enough memory to read the whole file and even if it did, it might take more than 16 minutes to run. I can try to break it out into multiple tasks and it'll probably be faster, but reading that code is (generally) gonna be much harder.

airocker 7y ago

How is it different from k8s jobs and cronjobs?