9 ms·

Running Containers on AWS Lambda

170 points by shaicoleman 4y ago

vorpalhex 4y ago
I went down the rabbithole of wanting to build my own lightweight Lambda, only to wonder if Lambda is just distributed CGI by another name.
- zevv 4y ago
  And, was it?
- dsanchez97 4y ago
  I think CGI is a good high level way of think about AWS Lambda and other Serverless compute platforms. I think the key innovations are the integrations with cloud services, and the scaling/economic model. Videos like the one linked below really demonstrate the level of optimizations implemented to make this work on the "cloud" scale. I think Serverless Compute platforms are going to become a really meaningful part of the software development ecosystem. [1] https://www.youtube.com/watch?v=A-7j0QlGwFk&ab_channel=InsideAmazonVideos https://www.youtube.com/watch?v=A-7j0QlGwFk&ab_channel=Insid...
- tyingq 4y ago
  Feels pretty similar to any typical fastcgi implementation with pools, scaling up/down, separate spaces for initialization code and per-request code, etc.
adamgordonbell 4y ago
Author here. I didn't expect this to show up here. I found containers on lambda to work really well. I can easily test them locally and they scale to zero when I'm not using them in AWS. So it's perfect for things that are idle a lot. I have a follow up coming where I use go in a container, and the request speed got a lot better. The service in this article is my html to text convert, so having a container where I could install OS-dependencies was crucial to getting this working. It's covered here and here: https://news.ycombinator.com/item?id=30829568 https://news.ycombinator.com/item?id=30829568 https://earthly-tools.com/text-mode https://earthly-tools.com/text-mode
- squeaky-clean 4y ago
  > I have a follow up coming where I use go in a container, and the request speed got a lot better. My team transitioned a lightweight python based lambda from zip to container based and we also saw a small (but definitely real) speedup in request time. I'm not the one who did the benchmarking, but iirc it was about 10ms faster. From ~50ms to ~40ms or so. edit: originally phrased it backwards to seem like container method was slower.
  - deleted 4y ago
    [deleted]
  - jaimehrubiks 4y ago
    Are you saying latency is lower on container than plain python? I recently made a project for the company and didn't even consider containers (which I love btw) because I though I could save some ms without container. Do you know if lambda containers performance is also good in nodejs? I need to have python and nodejs lambdas.
    - squeaky-clean 4y ago
      Versus the .zip file deploy method if that's what you mean, yes the container had a lower latency. The core code didn't change. This is just for the response time on a warmed-up lambda. We didn't benchmark cold-start times, but just from using it the cold-starts don't seem noticeably worse (Maybe they're also better? Honestly I don't know). Sorry don't know about nodejs yet. This was for a new lambda that wasn't in production yet, so it made sense to experiment. The increase in speed was unexpected but nice. But we're also assuming this increase is a static ~10ms speedup, and not a 20% speedup, but we only tested one lambda. I'm interested to see Adam's followup post and see if I'm wrong about that. Oh also just want to say, since the workings of lambda are hidden, it could be some totally different reason why containers perform better. Since its a newer feature, maybe it's running a newer version of the backend that the zip file backend will be moved to. Maybe container-based lambdas are allocated on newer hardware. Maybe containers are actually just faster. Can't ever really know without getting hired by Amazon and signing an NDA, lol.
Kalanos 4y ago
How long does it take to fetch the container - is it warm or cold? For AWS Batch it was taking me 1-3 min. So I was really surprised/ happy to see this lambda container post.
- adamgordonbell 4y ago
  You can test it out here although it might be hard to get a cold timing for it if many are using it: https://earthly-tools.com/text-mode https://earthly-tools.com/text-mode
- abofh 4y ago
  It's warm - when you change the ImageUri or "Update Code" for the lambda definition, it downloads the container into "somewhere" lambda-y - this takes a few seconds depending on size. Startups are fairly quick, but because of the way it persists your running image in memory, your container is generally (on frequent usage) 'paused' between invocations, and resumes quite quickly.
  - Kalanos 4y ago
    so cost-wise that's probably equivalent to running a server? but you get all of the nice lambda integrations like APIGW
    - adamgordonbell 4y ago
      Cost wise you are just paying for the time and memory when the lambda is running. So the image may be 'close' to the lambda but it's billed like other lambdas.
  - mjb 4y ago
    Yeah, that's right. I talk about some of the details here: https://www.youtube.com/watch?v=A-7j0QlGwFk https://www.youtube.com/watch?v=A-7j0QlGwFk We're working on some more formal documentation of this, both to help customers understand how to optimize things, and to join the research conversation about container loading. Our solution combines deterministic flattening, demand loading, erasure coding, convergent encryption, and a couple of other cool technologies to both accelerate the average case and drive down tail latency.
carfacts 4y ago
You’ll have to deal with lambda cold starts if you want it to be performant: > When the Lambda service receives a request to run a function via the Lambda API, the service first prepares an execution environment. During this step, the service downloads the code for the function, which is stored in an internal Amazon S3 bucket (or in Amazon Elastic Container Registry if the function uses container packaging). It then creates an environment with the memory, runtime, and configuration specified. Once complete, Lambda runs any initialization code outside of the event handler before finally running the handler code. https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-1/ https://aws.amazon.com/blogs/compute/operating-lambda-perfor...
- booi 4y ago
  This is definitely an issue especially with infrequently accessed functions but I've seen cold start issues regardless. I assume some scaling events will cause cold starts (measured in seconds). There's a good argument to go with packaged code instead of containers if you can manage the development complication and versioning (cold starts measured in milliseconds).
  - cebert 4y ago
    My team owns a Node 14 JS lambda application that is completely serverless. We’re focused on keeping our lambdas small with single responsibilities and leverage lambda layers for anything common across multiple lambdas. Cold starts are a concern, but is very negligible (< 100ms tops) and unnoticed by our client apps. We host all of our static web and JS assets via Cloud Front so they load quickly. If a user happened to visit our site when a lambda incurred a cold start, it’s not perceptible. We were much more worried initially about cold starts than it turned out we needed to be. Keeping lambdas small, picking a good language for the job, and leveraging lambda layers help minimize this a lot.
- mjb 4y ago
  It's not entirely accurate that Lambda pulls container images from ECR at start-up time. Here's me talking about what happens behind the scenes (which, in the real world, often makes things orders of magnitude faster than a full container pull): https://www.youtube.com/watch?v=A-7j0QlGwFk https://www.youtube.com/watch?v=A-7j0QlGwFk But your broader point is correct. Cold starts are a challenge, but they're one that the team is constantly working on and improving. You can also help reduce cold-start time by picking languages without heavy VMs (Go, Rust, etc), but reducing work done in 'static' code, and by minimizing the size of your container image. All those things will get less important over time, but they all can have a huge impact on cold-starts now. Another option is Lambda Provisioned concurrency, which allows you to pay a small amount to control how many sandboxes Lambda keeps warm on your behalf: https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html https://docs.aws.amazon.com/lambda/latest/dg/provisioned-con...
quaffapint 4y ago
We are using a container hosting .net6 with our lambda. We use it where I think lambdas really work well, that is to process queue items off of SQS. It works well with the dead-letter queue as well. We dont notice any performance issues, but this is just a processor, so we don't need to worry about real-time responses either.
- cebert 4y ago
  What was the thought behind processing SQS messages with a dotnet 6 containized lambda instead of a Node or Python lambda?
  - jugg1es 4y ago
    Have you used .NET recently? This is sort of a weird question. Not everyone uses node or python.
scottydelta 4y ago
Is it possible to host an app like Django inside container on lambda? This could help the Django/postgres apps to scale horizontally easily.
- alksjdalkj 4y ago
  Pretty sure Zappa does this: https://github.com/zappa/Zappa https://github.com/zappa/Zappa
- adamgordonbell 4y ago
  Yes, but is the startup time of Django an issue? Besides that you'd have to return your data in the shape that the API gateway expects from lambdas. Returning a 500 would look something like this: { "statusCode" : 500, "headers" : { "content-type": "text/plain; charset=utf-8" }, "body" : "Some error fetching the content" }
- throwaway2016a 4y ago
  Not sure about Django but on the Node.js side there are Express.js compatible libraries that let you write your app like you would Express but it's exposed via Lambda and API gateway. Good chance Python has something similar. Biggest difference is you're not dealing with HTTP (directly) but it can be abstracted to -- from a framework perspective -- act like HTTP.
  - dsanchez97 4y ago
    I am actually working on a python library that works like you described at https://cdevframework.io https://cdevframework.io! The goal is the provided a developer experience like Django that then deploys onto Serverless Infrastructure. It is a long way from that goal, but one day it will get there!
- klohto 4y ago
  Not Django, but AWS has a product focusing on this - Chalice https://github.com/aws/chalice https://github.com/aws/chalice
- 4y ago
fswd 4y ago
Lambda is Greek for CGI script.
- mjb 4y ago
  In a way, sure. But Lambda also does things that CGI didn't do: dynamic auto-scaling, integration with queues and streams for async processing, strong security isolation with fine-grained authorization, host failure detection and recovery, datacenter failure resilience, and many other things. The interface being familiar and relatively analogous to existing things is intentional. The point is to be different where being different helps, and familiar where being different doesn't help.
  - tedunangst 4y ago
    You get like 90% of that dropping your CGI directory on NFS shared among multiple hosts. AWS offers a full featured host environment, so you don't have to build that part, but the part you write is quite similar.
    - scarface74 4y ago
      Did CGI allow you to have your individual CGI scripts in separate containers?
      - mhitza 4y ago
        If it talks via FastCGI you could have individual containers per whatever unit of segmentation you'd like.
- throwaway2016a 4y ago
  As someone who has been around long enough to actually remember setting up /cgi-bin/... there is a lot more to lambdas. They are scalable (including, importantly, down to zero!), have their own dedicated resources for each process, and are pretty efficient at being put to sleep and woken up. Plus the code is immutable by default and you get a lot out of the box like logging and setting limits. I wouldn't start a new project with CGI at all right now but I use Lambda constantly.
victor106 4y ago
I found using AWS Copilot to deploy to AWS Fargate easy to deploy, maintain and scale.
- nogbit 4y ago
  Until it it fails, and the backing CF errors and won’t resolve itself for over 24rs. Bit twice, never again with Copilot. Good idea they had, just shaky foundation.
  - logic_beats_pro 4y ago
    CF = Cloud Formation?
gadflyinyoureye 4y ago
We're trying this out at a large insurance company. Historically actuarial teams created excel workbooks, r code, and python. Then those models were given to development teams to implement in a different language. As one might guess there were loads of bugs and the process was slow. Now we're going to deploy an R lambda that owned by DevOps which integrates all the I/O into dataframes. The lambda calls a calculation in R that takes those dataframes and returns a dataframe answer. If all goes well (prototype works fine), we saved probably 500k and 6 months.
spullara 4y ago
I have an entire video analytics pipeline running about a dozen containers for inference. Works great.
- alex_suzuki 4y ago
  You and me both! Works great, i only wish that the timeout of 15 minutes could be increased…
  - spullara 4y ago
    I very carefully batch things / break them up to make it work well since none of the models I am using individually need 15 min for a single frame.
  - sjlogan 4y ago
    This plagues me almost daily. I would love for this limit to be increased as well ...
excuses_ 4y ago
I had much better experience with GCP Cloud Run. Prepare a OCI/Docker image, type `gcloud run` with a few flags and you’re done. In 2021 they added a bunch of features which in my opinion make Cloud Run one of the most trivial ways of deploying containers indented for production usage.
- nogbit 4y ago
  Simply the best cloud service from any of the three big CSP’s bar none. The day AWS supports this more out of the box on Lambda (no, I will not use your required base image or signatures) will be the day containers and serverless become one (like it is already on GCP).
  - chrisweekly 4y ago
    Fly.io isn't one of the "three big CSP's" but they are awesome.
- holografix 4y ago
  Prepare image…? Just let buildpacks sort it out and forget the Dockerfile ever existed.
faangiq 4y ago
“Why run on lambda instead of fargate? Oops, we won’t tell you.” - AWS
- andrew_ 4y ago
  This is going to throw unknowing readers for a loop, because it's a comment trying to be cheeky. Simply put: Fargate/ECS/EC2+EB = long running tasks Lambda = Short burst tasks with a max life of 15 minutes Running a lambda 24/7 will nuke your credit card. Using Fargate for a scheduler/cron job that only runs 4 times a day will nuke your credit card. Use the right tool for the right job.
  - alex-korr 4y ago
    AWS datapipeline is likely the best solution for a longer running batch that gets run 3-4 times a day.
    - andrew_ 4y ago
      It's definitely an option. Wrapped services are almost always more expensive, so careful attention to pricing details is needed.
      - alex-korr 4y ago
        The bulk of the cost here is usually on the EC2 side. The main extra cost is the price it takes your runner EC2 instance(s) to bootstrap - ie usually about 2-3 minutes. Can be mitigated by using prepaid discounts, etc.
holografix 4y ago
No offence but Cloud Run has been doing this for a while? And now Cloud Functions gen 2 as well…?
fulafel 4y ago
I'v found that using this will cause Lambda sometimes to return 500 errors while it's reloading the container image from the registry. This might be the price for allowing large images, they've decided not to do it in a blocking way.

170 points by shaicoleman 4y ago

I went down the rabbithole of wanting to build my own lightweight Lambda, only to wonder if Lambda is just distributed CGI by another name.

zevv 4y ago
And, was it?
dsanchez97 4y ago
I think CGI is a good high level way of think about AWS Lambda and other Serverless compute platforms. I think the key innovations are the integrations with cloud services, and the scaling/economic model. Videos like the one linked below really demonstrate the level of optimizations implemented to make this work on the "cloud" scale. I think Serverless Compute platforms are going to become a really meaningful part of the software development ecosystem. [1] https://www.youtube.com/watch?v=A-7j0QlGwFk&ab_channel=InsideAmazonVideos https://www.youtube.com/watch?v=A-7j0QlGwFk&ab_channel=Insid...
tyingq 4y ago
Feels pretty similar to any typical fastcgi implementation with pools, scaling up/down, separate spaces for initialization code and per-request code, etc.

adamgordonbell 4y ago

Author here. I didn't expect this to show up here. I found containers on lambda to work really well. I can easily test them locally and they scale to zero when I'm not using them in AWS. So it's perfect for things that are idle a lot. I have a follow up coming where I use go in a container, and the request speed got a lot better. The service in this article is my html to text convert, so having a container where I could install OS-dependencies was crucial to getting this working. It's covered here and here: https://news.ycombinator.com/item?id=30829568 https://news.ycombinator.com/item?id=30829568 https://earthly-tools.com/text-mode https://earthly-tools.com/text-mode

squeaky-clean 4y ago
> I have a follow up coming where I use go in a container, and the request speed got a lot better. My team transitioned a lightweight python based lambda from zip to container based and we also saw a small (but definitely real) speedup in request time. I'm not the one who did the benchmarking, but iirc it was about 10ms faster. From ~50ms to ~40ms or so. edit: originally phrased it backwards to seem like container method was slower.
- deleted 4y ago
  [deleted]
- jaimehrubiks 4y ago
  Are you saying latency is lower on container than plain python? I recently made a project for the company and didn't even consider containers (which I love btw) because I though I could save some ms without container. Do you know if lambda containers performance is also good in nodejs? I need to have python and nodejs lambdas.
  - squeaky-clean 4y ago
    Versus the .zip file deploy method if that's what you mean, yes the container had a lower latency. The core code didn't change. This is just for the response time on a warmed-up lambda. We didn't benchmark cold-start times, but just from using it the cold-starts don't seem noticeably worse (Maybe they're also better? Honestly I don't know). Sorry don't know about nodejs yet. This was for a new lambda that wasn't in production yet, so it made sense to experiment. The increase in speed was unexpected but nice. But we're also assuming this increase is a static ~10ms speedup, and not a 20% speedup, but we only tested one lambda. I'm interested to see Adam's followup post and see if I'm wrong about that. Oh also just want to say, since the workings of lambda are hidden, it could be some totally different reason why containers perform better. Since its a newer feature, maybe it's running a newer version of the backend that the zip file backend will be moved to. Maybe container-based lambdas are allocated on newer hardware. Maybe containers are actually just faster. Can't ever really know without getting hired by Amazon and signing an NDA, lol.

Kalanos 4y ago

How long does it take to fetch the container - is it warm or cold? For AWS Batch it was taking me 1-3 min. So I was really surprised/ happy to see this lambda container post.

adamgordonbell 4y ago
You can test it out here although it might be hard to get a cold timing for it if many are using it: https://earthly-tools.com/text-mode https://earthly-tools.com/text-mode
abofh 4y ago
It's warm - when you change the ImageUri or "Update Code" for the lambda definition, it downloads the container into "somewhere" lambda-y - this takes a few seconds depending on size. Startups are fairly quick, but because of the way it persists your running image in memory, your container is generally (on frequent usage) 'paused' between invocations, and resumes quite quickly.
- Kalanos 4y ago
  so cost-wise that's probably equivalent to running a server? but you get all of the nice lambda integrations like APIGW
  - adamgordonbell 4y ago
    Cost wise you are just paying for the time and memory when the lambda is running. So the image may be 'close' to the lambda but it's billed like other lambdas.
- mjb 4y ago
  Yeah, that's right. I talk about some of the details here: https://www.youtube.com/watch?v=A-7j0QlGwFk https://www.youtube.com/watch?v=A-7j0QlGwFk We're working on some more formal documentation of this, both to help customers understand how to optimize things, and to join the research conversation about container loading. Our solution combines deterministic flattening, demand loading, erasure coding, convergent encryption, and a couple of other cool technologies to both accelerate the average case and drive down tail latency.

carfacts 4y ago

You’ll have to deal with lambda cold starts if you want it to be performant: > When the Lambda service receives a request to run a function via the Lambda API, the service first prepares an execution environment. During this step, the service downloads the code for the function, which is stored in an internal Amazon S3 bucket (or in Amazon Elastic Container Registry if the function uses container packaging). It then creates an environment with the memory, runtime, and configuration specified. Once complete, Lambda runs any initialization code outside of the event handler before finally running the handler code. https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-1/ https://aws.amazon.com/blogs/compute/operating-lambda-perfor...

booi 4y ago
This is definitely an issue especially with infrequently accessed functions but I've seen cold start issues regardless. I assume some scaling events will cause cold starts (measured in seconds). There's a good argument to go with packaged code instead of containers if you can manage the development complication and versioning (cold starts measured in milliseconds).
- cebert 4y ago
  My team owns a Node 14 JS lambda application that is completely serverless. We’re focused on keeping our lambdas small with single responsibilities and leverage lambda layers for anything common across multiple lambdas. Cold starts are a concern, but is very negligible (< 100ms tops) and unnoticed by our client apps. We host all of our static web and JS assets via Cloud Front so they load quickly. If a user happened to visit our site when a lambda incurred a cold start, it’s not perceptible. We were much more worried initially about cold starts than it turned out we needed to be. Keeping lambdas small, picking a good language for the job, and leveraging lambda layers help minimize this a lot.
mjb 4y ago
It's not entirely accurate that Lambda pulls container images from ECR at start-up time. Here's me talking about what happens behind the scenes (which, in the real world, often makes things orders of magnitude faster than a full container pull): https://www.youtube.com/watch?v=A-7j0QlGwFk https://www.youtube.com/watch?v=A-7j0QlGwFk But your broader point is correct. Cold starts are a challenge, but they're one that the team is constantly working on and improving. You can also help reduce cold-start time by picking languages without heavy VMs (Go, Rust, etc), but reducing work done in 'static' code, and by minimizing the size of your container image. All those things will get less important over time, but they all can have a huge impact on cold-starts now. Another option is Lambda Provisioned concurrency, which allows you to pay a small amount to control how many sandboxes Lambda keeps warm on your behalf: https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html https://docs.aws.amazon.com/lambda/latest/dg/provisioned-con...

quaffapint 4y ago

We are using a container hosting .net6 with our lambda. We use it where I think lambdas really work well, that is to process queue items off of SQS. It works well with the dead-letter queue as well. We dont notice any performance issues, but this is just a processor, so we don't need to worry about real-time responses either.

cebert 4y ago
What was the thought behind processing SQS messages with a dotnet 6 containized lambda instead of a Node or Python lambda?
- jugg1es 4y ago
  Have you used .NET recently? This is sort of a weird question. Not everyone uses node or python.

scottydelta 4y ago

Is it possible to host an app like Django inside container on lambda? This could help the Django/postgres apps to scale horizontally easily.

alksjdalkj 4y ago
Pretty sure Zappa does this: https://github.com/zappa/Zappa https://github.com/zappa/Zappa
adamgordonbell 4y ago
Yes, but is the startup time of Django an issue? Besides that you'd have to return your data in the shape that the API gateway expects from lambdas. Returning a 500 would look something like this: { "statusCode" : 500, "headers" : { "content-type": "text/plain; charset=utf-8" }, "body" : "Some error fetching the content" }
throwaway2016a 4y ago
Not sure about Django but on the Node.js side there are Express.js compatible libraries that let you write your app like you would Express but it's exposed via Lambda and API gateway. Good chance Python has something similar. Biggest difference is you're not dealing with HTTP (directly) but it can be abstracted to -- from a framework perspective -- act like HTTP.
- dsanchez97 4y ago
  I am actually working on a python library that works like you described at https://cdevframework.io https://cdevframework.io! The goal is the provided a developer experience like Django that then deploys onto Serverless Infrastructure. It is a long way from that goal, but one day it will get there!
klohto 4y ago
Not Django, but AWS has a product focusing on this - Chalice https://github.com/aws/chalice https://github.com/aws/chalice
4y ago

fswd 4y ago

Lambda is Greek for CGI script.

mjb 4y ago
In a way, sure. But Lambda also does things that CGI didn't do: dynamic auto-scaling, integration with queues and streams for async processing, strong security isolation with fine-grained authorization, host failure detection and recovery, datacenter failure resilience, and many other things. The interface being familiar and relatively analogous to existing things is intentional. The point is to be different where being different helps, and familiar where being different doesn't help.
- tedunangst 4y ago
  You get like 90% of that dropping your CGI directory on NFS shared among multiple hosts. AWS offers a full featured host environment, so you don't have to build that part, but the part you write is quite similar.
  - scarface74 4y ago
    Did CGI allow you to have your individual CGI scripts in separate containers?
    - mhitza 4y ago
      If it talks via FastCGI you could have individual containers per whatever unit of segmentation you'd like.
throwaway2016a 4y ago
As someone who has been around long enough to actually remember setting up /cgi-bin/... there is a lot more to lambdas. They are scalable (including, importantly, down to zero!), have their own dedicated resources for each process, and are pretty efficient at being put to sleep and woken up. Plus the code is immutable by default and you get a lot out of the box like logging and setting limits. I wouldn't start a new project with CGI at all right now but I use Lambda constantly.

victor106 4y ago

I found using AWS Copilot to deploy to AWS Fargate easy to deploy, maintain and scale.

nogbit 4y ago
Until it it fails, and the backing CF errors and won’t resolve itself for over 24rs. Bit twice, never again with Copilot. Good idea they had, just shaky foundation.
- logic_beats_pro 4y ago
  CF = Cloud Formation?

gadflyinyoureye 4y ago

We're trying this out at a large insurance company. Historically actuarial teams created excel workbooks, r code, and python. Then those models were given to development teams to implement in a different language. As one might guess there were loads of bugs and the process was slow. Now we're going to deploy an R lambda that owned by DevOps which integrates all the I/O into dataframes. The lambda calls a calculation in R that takes those dataframes and returns a dataframe answer. If all goes well (prototype works fine), we saved probably 500k and 6 months.

spullara 4y ago

I have an entire video analytics pipeline running about a dozen containers for inference. Works great.

alex_suzuki 4y ago
You and me both! Works great, i only wish that the timeout of 15 minutes could be increased…
- spullara 4y ago
  I very carefully batch things / break them up to make it work well since none of the models I am using individually need 15 min for a single frame.
- sjlogan 4y ago
  This plagues me almost daily. I would love for this limit to be increased as well ...

excuses_ 4y ago

I had much better experience with GCP Cloud Run. Prepare a OCI/Docker image, type `gcloud run` with a few flags and you’re done. In 2021 they added a bunch of features which in my opinion make Cloud Run one of the most trivial ways of deploying containers indented for production usage.

nogbit 4y ago
Simply the best cloud service from any of the three big CSP’s bar none. The day AWS supports this more out of the box on Lambda (no, I will not use your required base image or signatures) will be the day containers and serverless become one (like it is already on GCP).
- chrisweekly 4y ago
  Fly.io isn't one of the "three big CSP's" but they are awesome.
holografix 4y ago
Prepare image…? Just let buildpacks sort it out and forget the Dockerfile ever existed.

faangiq 4y ago

“Why run on lambda instead of fargate? Oops, we won’t tell you.” - AWS

andrew_ 4y ago
This is going to throw unknowing readers for a loop, because it's a comment trying to be cheeky. Simply put: Fargate/ECS/EC2+EB = long running tasks Lambda = Short burst tasks with a max life of 15 minutes Running a lambda 24/7 will nuke your credit card. Using Fargate for a scheduler/cron job that only runs 4 times a day will nuke your credit card. Use the right tool for the right job.
- alex-korr 4y ago
  AWS datapipeline is likely the best solution for a longer running batch that gets run 3-4 times a day.
  - andrew_ 4y ago
    It's definitely an option. Wrapped services are almost always more expensive, so careful attention to pricing details is needed.
    - alex-korr 4y ago
      The bulk of the cost here is usually on the EC2 side. The main extra cost is the price it takes your runner EC2 instance(s) to bootstrap - ie usually about 2-3 minutes. Can be mitigated by using prepaid discounts, etc.

holografix 4y ago

No offence but Cloud Run has been doing this for a while? And now Cloud Functions gen 2 as well…?

fulafel 4y ago

I'v found that using this will cause Lambda sometimes to return 500 errors while it's reloading the container image from the registry. This might be the price for allowing large images, they've decided not to do it in a blocking way.