6 ms·

Hey everyone, we're really excited about this feature launch, and I wanted to come in to clarify any misconceptions. With this capability you can now package L

by munns 6y ago

Hey everyone, we're really excited about this feature launch, and I wanted to come in to clarify any misconceptions. With this capability you can now package Lambda functions using familiar container image tools (Dockerfile, cli tools, build systems) but you still need to code them for the event model, have a handler, etc. It's a big improvement, but its not "run any container in Lambda". Either way, hope you go and try it out and we'd love feedback on how it can be better. - Chris Munns, Lead of Dev Advocacy - Serverless@AWS

jacques_chester 6y ago
Hi Chris; One thing I'd like to see is buildpacks for that final function contract. It's been done before for other cloud-y respond-y things (we did it on Project riff, Google have done it for Cloud Run), so I am aware it's possible. The nice part is that you won't need to build all the buildpacks yourself -- just the small set that adds your specialisations. Feel free to email me.
- munns 6y ago
  Yeah, this is Day 1 for this and I think we've got a bunch of ideas to make it easier in the future. Most importantly we're looking for feedback just like this! Thanks, - Chris
dcu 6y ago
hi Chris, maybe slightly off-topic but is there a chance to see gravitons and/or ML chips on Lambda? :)
- munns 6y ago
  Couldn't share future roadmap here, but these are some cool ideas :)
newscom59 6y ago
> but you still need to code them for the event model, have a handler, etc. >It's a big improvement, but its not "run any container in Lambda". Well that’s... incredibly disappointing and makes this announcement much less exciting. The entire point of containerization is portability across different services and platforms. It’s seems like a massive miss for the team to tout “container support” but then still require platform-specific customizations within the container. I pretty much don’t care at all for this as-is. Are there plans for “run any container on Lambda”? That’s what everyone was (falsely) excited about.
- dperfect 6y ago
  Your reading of "its not 'run any container in Lambda'" may be a bit too pessimistic. From what I'm seeing, you can run any container (<10 GB), but it just has to implement the Lambda Runtime API[1]. You can't run a random container and expect Lambda to know how it should communicate with the world. As others have noted, ECS or Fargate would be more appropriate for cases that fall outside the Lambda event model. [1] https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.ht...
  - newscom59 6y ago
    > you can run any container (<10 GB), but it just has to implement the Lambda Runtime API[1] So in other words, you can’t run any container. Again, the entire point of containers is portability across execution environments. If I have to build special containers specifically for Lambda because they require these special runtimes, that defeats the entire point. > You can't run a random container and expect Lambda to know how it should communicate with the world. Google Cloud Run, which everyone keeps comparing this with, works exactly like that. Upload any random container, tell it which port to open, and bam... running application. You don’t have to mess around with adding any “Cloud Run runtimes” or modifying your code to add special “Cloud Run handlers”. Because that would be silly.
    - mcintyre1994 6y ago
      It's not really a very good comparison to be honest, because Lambdas integrate with a whole bunch of AWS services that send them events that aren't HTTP requests via a port. I had exactly the same thought you're expressing here when I first built a Lambda to serve as a HTTP API manually after previously using Azure a tiny bit. In Azure you write their equivalent function and one of the built-in trigger options is HTTP, you enable that and immediately get a URL. Lambdas are quite close to that now I think if you're using the console UI, but you used to have to go through API gateway and set everything up manually. But the point is that Lambdas aren't HTTP APIs that listen on a single port. They receive events that can be proxied HTTP requests via API Gateway, or messages on queues, or completely arbitrary invocations from step functions, or notifications that look nothing like HTTP from S3 buckets. I'd like the Cloud Run model when my lambda is acting like an HTTP API, but I don't think it'd be much fun to have to treat every AWS event as a full HTTP request for everything else. I'm not very familiar with Google Cloud, but I think their equivalent is Cloud Functions which looks very similar to Lambda's pre-container model: https://cloud.google.com/functions/docs/writing https://cloud.google.com/functions/docs/writing
orasis 6y ago
What can we expect cold start times to look like with larger containers? (1GB for example)
- julianwood 6y ago
  We optimize and cache the image so cold starts times should be the same as with zip functions.
  - orasis 6y ago
    Wow!
  - stephanos2k 6y ago
    Hm, not what I observed so far. Same Go application taking 1.5s instead of ~50ms to cold start.
drakej 6y ago
It's unclear from the docs -- are the container images supported by CloudFormation?
- munns 6y ago
  Yes, either those docs will ship today or sometime this week. They are doing everything in batches but I've seen the SAM support pre-launch (which would require it). - Chris
  - drakej 6y ago
    Awesome. Very excited about this!
nlg 6y ago
Thanks for coming here to answer questions. Much appreciated! Does each new Lambda cold start pull the entire image from the repo? Or if I derive from Lambda base images am I likely to get some of the layers already cached? I'm trying to think about how the data transfer costs are going to each time the Lambda is instantiated. I didn't take this into account with Fargate and got burned when trying to trigger images on demand in a similar way. This could replace my whole SQS / CloudWatch Events / Fargate setup using Lambda if I can figure out cold start costs ($ not time).
- munns 6y ago
  There's a few things at play. Functions will still stay warm inbetween invocations and will keep local any data already in the worker. We also maintain a couple different levels of cache so as to not hit ECR often. I know we've got a few blog posts coming out over the next couple weeks on this new feature, and each tells a few bits and pieces about the story. Depending on volume you'll probably find that Lambda will be cheaper for that workload, especially with the new 1ms billing. - Chris - Serverless@AWS
  - stephanos2k 6y ago
    FWIW, a little experimented I just ran showed me that with simple layers the cold start time of my little 3MB Go app was <100ms, using the Docker image `amazon/aws-lambda-go:1` instead took ~1500ms. - - - - REPORT RequestId: f905d5fe-a64e-48c8-b1f2-6535640a6f82 Duration: 7.55 ms Billed Duration: 1309 ms Memory Size: 256 MB Max Memory Used: 49 MB Init Duration: 1301.10 ms - - - - REPORT RequestId: 89afb20d-bc49-4d89-91f0-f1ef62ac99aa Duration: 12.20 ms Billed Duration: 13 ms Memory Size: 256 MB Max Memory Used: 35 MB Init Duration: 85.37 ms
ngrilly 6y ago
Why does the lambda container has to pull events from the lambda runtime using an HTTP GET request, instead of having the runtime push the events with an HTTP POST?
- munns 6y ago
  This is all based on how the RunTime API worked already (pre-dates this launch by 2 years or so). We wanted to not change too many bits. Since function code has no listening socket/port as it were you need something (like the bootstrap script in a custom RunTime) to pull the local interface for the runtime API. That runs on the underlying worker and communicates with the API for Lambda.
- saurik 6y ago
  How would the runtime know for sure when the container was ready to accept the request? The lambda model--with the container pulling the events instead of them being pushed to it--seems like the correct way to model the concurrency.
  - ngrilly 6y ago
    Retries and health checks.
mwcampbell 6y ago
Just wanted to say thanks for this new feature. The ability to use images up to 10 GB is huge. Being able to customize the container image down to the base OS is also nice. Don't let the negativity around the Lambda-specific bits get you down. I know that Lambda is about more than just serving HTTP, and I for one plan to use this new feature for a non-HTTP use case soon.
- munns 6y ago
  Thanks! Appreciate the feedback and hope this helps you out. Let us know if it doesn't :) - Chris
  - mwcampbell 6y ago
    I do have a question. I know that Lambda normally reuses a running container for multiple consecutive function invocations. What if I don't want to do that for a particular function? Suppose, for security, I don't want any leftovers from a previous invocation (in case it had data from a different user). Is there a way I could gracefully tell Lambda to create a fresh container instance for each invocation, and just live with the cold start penalty every time? Edit: I could just look to Fargate at this point, but it sounds like Lambda is doing some extra cold start optimization.
    - munns 6y ago
      No good way to do this today. You are right in that you'd be forcing cold-starts. You could use a Lambda Extension to provide some sort of after-processing clean up of vars or /tmp space.. but thats hypothetical I haven't seen anyone do that yet.
      - mwcampbell 6y ago
        I think what I'll do is write a container entry point that cleans up temporary files like you said, but also repeatedly spawns a new process for the main program, to minimize the findable leftover data in RAM. Just in case an attacker finds a Heartbleed equivalent in my application. Thanks again!
simonw 6y ago
My wishlist for this feature (and for AWS Lambda in general): - Don't make me build the Docker image myself. I'd like to be able to deploy lambdas by sending you a Dockerfile and having you build it for me, with as few additional steps as possible. - Make it as easy as possible to run containers that speak HTTP, like Google Cloud Run does. Having a wrapper that translates the AWS Lambda runtime into HTTP calls, maybe even as a proxy I can run inside my own container, would help a lot here. - Make it as easy as possible for me to host my lambda as the "root" URL of a domain or subdomain that I own - without those nasty /api/ path prefixes. Zeit Now (the Docker-based predecessor to Vercel) did this the best in my opinion - they had an HTTP API that you could POST a Dockerfile to and they would build it into an image and then start a container listening on an HTTP port, with an HTTPS proxy in front of it, running on a subdomain that I could easily customize. I would LOVE to see AWS Lambda offer an equivalent developer experience. I'm super-excited about container image support but I'll admit I am absolutely dreading the several hours (to several days) it's going to take me to figure out how to actually get my code running on it.
- munns 6y ago
  Awesome, thanks for sharing this.
- wwright 6y ago
  One of the difficulties with this is that Dockerfiles are usually not very reproducible, mostly due to the design of the distributions they are based on. It could be very surprising to send the same Dockerfile to the endpoint twice and get very different runtime results.
  - simonw 6y ago
    I'd expect that I would send a Dockerfile once and have that compiled into a lambda for me which would then run in perpetuity unless I sent over a fresh Dockerfile to over-write that deployment, so non-reproducible Dockerfiles wouldn't bother me. I'm OK with developers needing to understand that a Dockerfile may build differently each time if they don't take extra steps to prevent that (like pinning installed versions etc).
xmly 6y ago
Does the container support state?
- munns 6y ago
  Same as Lambda has before. The state you have is most likely short lived as we reap worker environments every so often, but in-between invokes you could persist some data in memory or tmp space.
catchmeifyoucan 6y ago
I know it’s not necessarily a container related thing, but one I thing that frustrates me a lot, and why deploying takes longer than I expect is because zipping up and uploading a package is a bunch of unnecessary clicks. I just want to “npm install” a few third party libraries in the online IDE. (repl.it has a nice experience here). It’s frustrating to shuffle between my desktop, AWS and back again.
mikeparker2 6y ago
If we push an image with an AWS base image do we need to constantly update and rebuild + redeploy it or do you handle the base image updates behind the scenes (e.g. security patches) like normal lambda?
munawwar 6y ago
Would this end up cheaper than fargate spot pricing?
saurik 6y ago
So, apparently I am crazy for thinking that running zip is trivial whereas the ridiculous stack of tooling that surrounds the awkward nested format of docker containers is extremely annoying :/... with the new ability to accept large containers, can I now send you a larger zip, or if I want a larger lambda function am I going to have to use the docker container interface?

by munns 6y ago

jacques_chester 6y ago

Hi Chris; One thing I'd like to see is buildpacks for that final function contract. It's been done before for other cloud-y respond-y things (we did it on Project riff, Google have done it for Cloud Run), so I am aware it's possible. The nice part is that you won't need to build all the buildpacks yourself -- just the small set that adds your specialisations. Feel free to email me.

munns 6y ago
Yeah, this is Day 1 for this and I think we've got a bunch of ideas to make it easier in the future. Most importantly we're looking for feedback just like this! Thanks, - Chris

dcu 6y ago

hi Chris, maybe slightly off-topic but is there a chance to see gravitons and/or ML chips on Lambda? :)

munns 6y ago
Couldn't share future roadmap here, but these are some cool ideas :)

newscom59 6y ago

> but you still need to code them for the event model, have a handler, etc. >It's a big improvement, but its not "run any container in Lambda". Well that’s... incredibly disappointing and makes this announcement much less exciting. The entire point of containerization is portability across different services and platforms. It’s seems like a massive miss for the team to tout “container support” but then still require platform-specific customizations within the container. I pretty much don’t care at all for this as-is. Are there plans for “run any container on Lambda”? That’s what everyone was (falsely) excited about.

dperfect 6y ago
Your reading of "its not 'run any container in Lambda'" may be a bit too pessimistic. From what I'm seeing, you can run any container (<10 GB), but it just has to implement the Lambda Runtime API[1]. You can't run a random container and expect Lambda to know how it should communicate with the world. As others have noted, ECS or Fargate would be more appropriate for cases that fall outside the Lambda event model. [1] https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.ht...
- newscom59 6y ago
  > you can run any container (<10 GB), but it just has to implement the Lambda Runtime API[1] So in other words, you can’t run any container. Again, the entire point of containers is portability across execution environments. If I have to build special containers specifically for Lambda because they require these special runtimes, that defeats the entire point. > You can't run a random container and expect Lambda to know how it should communicate with the world. Google Cloud Run, which everyone keeps comparing this with, works exactly like that. Upload any random container, tell it which port to open, and bam... running application. You don’t have to mess around with adding any “Cloud Run runtimes” or modifying your code to add special “Cloud Run handlers”. Because that would be silly.
  - mcintyre1994 6y ago
    It's not really a very good comparison to be honest, because Lambdas integrate with a whole bunch of AWS services that send them events that aren't HTTP requests via a port. I had exactly the same thought you're expressing here when I first built a Lambda to serve as a HTTP API manually after previously using Azure a tiny bit. In Azure you write their equivalent function and one of the built-in trigger options is HTTP, you enable that and immediately get a URL. Lambdas are quite close to that now I think if you're using the console UI, but you used to have to go through API gateway and set everything up manually. But the point is that Lambdas aren't HTTP APIs that listen on a single port. They receive events that can be proxied HTTP requests via API Gateway, or messages on queues, or completely arbitrary invocations from step functions, or notifications that look nothing like HTTP from S3 buckets. I'd like the Cloud Run model when my lambda is acting like an HTTP API, but I don't think it'd be much fun to have to treat every AWS event as a full HTTP request for everything else. I'm not very familiar with Google Cloud, but I think their equivalent is Cloud Functions which looks very similar to Lambda's pre-container model: https://cloud.google.com/functions/docs/writing https://cloud.google.com/functions/docs/writing

orasis 6y ago

What can we expect cold start times to look like with larger containers? (1GB for example)

julianwood 6y ago
We optimize and cache the image so cold starts times should be the same as with zip functions.
- orasis 6y ago
  Wow!
- stephanos2k 6y ago
  Hm, not what I observed so far. Same Go application taking 1.5s instead of ~50ms to cold start.

drakej 6y ago

It's unclear from the docs -- are the container images supported by CloudFormation?

munns 6y ago
Yes, either those docs will ship today or sometime this week. They are doing everything in batches but I've seen the SAM support pre-launch (which would require it). - Chris
- drakej 6y ago
  Awesome. Very excited about this!

nlg 6y ago

Thanks for coming here to answer questions. Much appreciated! Does each new Lambda cold start pull the entire image from the repo? Or if I derive from Lambda base images am I likely to get some of the layers already cached? I'm trying to think about how the data transfer costs are going to each time the Lambda is instantiated. I didn't take this into account with Fargate and got burned when trying to trigger images on demand in a similar way. This could replace my whole SQS / CloudWatch Events / Fargate setup using Lambda if I can figure out cold start costs ($ not time).

munns 6y ago
There's a few things at play. Functions will still stay warm inbetween invocations and will keep local any data already in the worker. We also maintain a couple different levels of cache so as to not hit ECR often. I know we've got a few blog posts coming out over the next couple weeks on this new feature, and each tells a few bits and pieces about the story. Depending on volume you'll probably find that Lambda will be cheaper for that workload, especially with the new 1ms billing. - Chris - Serverless@AWS
- stephanos2k 6y ago
  FWIW, a little experimented I just ran showed me that with simple layers the cold start time of my little 3MB Go app was <100ms, using the Docker image `amazon/aws-lambda-go:1` instead took ~1500ms. - - - - REPORT RequestId: f905d5fe-a64e-48c8-b1f2-6535640a6f82 Duration: 7.55 ms Billed Duration: 1309 ms Memory Size: 256 MB Max Memory Used: 49 MB Init Duration: 1301.10 ms - - - - REPORT RequestId: 89afb20d-bc49-4d89-91f0-f1ef62ac99aa Duration: 12.20 ms Billed Duration: 13 ms Memory Size: 256 MB Max Memory Used: 35 MB Init Duration: 85.37 ms

ngrilly 6y ago

Why does the lambda container has to pull events from the lambda runtime using an HTTP GET request, instead of having the runtime push the events with an HTTP POST?

munns 6y ago
This is all based on how the RunTime API worked already (pre-dates this launch by 2 years or so). We wanted to not change too many bits. Since function code has no listening socket/port as it were you need something (like the bootstrap script in a custom RunTime) to pull the local interface for the runtime API. That runs on the underlying worker and communicates with the API for Lambda.
saurik 6y ago
How would the runtime know for sure when the container was ready to accept the request? The lambda model--with the container pulling the events instead of them being pushed to it--seems like the correct way to model the concurrency.
- ngrilly 6y ago
  Retries and health checks.

mwcampbell 6y ago

Just wanted to say thanks for this new feature. The ability to use images up to 10 GB is huge. Being able to customize the container image down to the base OS is also nice. Don't let the negativity around the Lambda-specific bits get you down. I know that Lambda is about more than just serving HTTP, and I for one plan to use this new feature for a non-HTTP use case soon.

munns 6y ago
Thanks! Appreciate the feedback and hope this helps you out. Let us know if it doesn't :) - Chris
- mwcampbell 6y ago
  I do have a question. I know that Lambda normally reuses a running container for multiple consecutive function invocations. What if I don't want to do that for a particular function? Suppose, for security, I don't want any leftovers from a previous invocation (in case it had data from a different user). Is there a way I could gracefully tell Lambda to create a fresh container instance for each invocation, and just live with the cold start penalty every time? Edit: I could just look to Fargate at this point, but it sounds like Lambda is doing some extra cold start optimization.
  - munns 6y ago
    No good way to do this today. You are right in that you'd be forcing cold-starts. You could use a Lambda Extension to provide some sort of after-processing clean up of vars or /tmp space.. but thats hypothetical I haven't seen anyone do that yet.
    - mwcampbell 6y ago
      I think what I'll do is write a container entry point that cleans up temporary files like you said, but also repeatedly spawns a new process for the main program, to minimize the findable leftover data in RAM. Just in case an attacker finds a Heartbleed equivalent in my application. Thanks again!

simonw 6y ago

My wishlist for this feature (and for AWS Lambda in general): - Don't make me build the Docker image myself. I'd like to be able to deploy lambdas by sending you a Dockerfile and having you build it for me, with as few additional steps as possible. - Make it as easy as possible to run containers that speak HTTP, like Google Cloud Run does. Having a wrapper that translates the AWS Lambda runtime into HTTP calls, maybe even as a proxy I can run inside my own container, would help a lot here. - Make it as easy as possible for me to host my lambda as the "root" URL of a domain or subdomain that I own - without those nasty /api/ path prefixes. Zeit Now (the Docker-based predecessor to Vercel) did this the best in my opinion - they had an HTTP API that you could POST a Dockerfile to and they would build it into an image and then start a container listening on an HTTP port, with an HTTPS proxy in front of it, running on a subdomain that I could easily customize. I would LOVE to see AWS Lambda offer an equivalent developer experience. I'm super-excited about container image support but I'll admit I am absolutely dreading the several hours (to several days) it's going to take me to figure out how to actually get my code running on it.

munns 6y ago
Awesome, thanks for sharing this.
wwright 6y ago
One of the difficulties with this is that Dockerfiles are usually not very reproducible, mostly due to the design of the distributions they are based on. It could be very surprising to send the same Dockerfile to the endpoint twice and get very different runtime results.
- simonw 6y ago
  I'd expect that I would send a Dockerfile once and have that compiled into a lambda for me which would then run in perpetuity unless I sent over a fresh Dockerfile to over-write that deployment, so non-reproducible Dockerfiles wouldn't bother me. I'm OK with developers needing to understand that a Dockerfile may build differently each time if they don't take extra steps to prevent that (like pinning installed versions etc).

xmly 6y ago

Does the container support state?

munns 6y ago
Same as Lambda has before. The state you have is most likely short lived as we reap worker environments every so often, but in-between invokes you could persist some data in memory or tmp space.

catchmeifyoucan 6y ago

I know it’s not necessarily a container related thing, but one I thing that frustrates me a lot, and why deploying takes longer than I expect is because zipping up and uploading a package is a bunch of unnecessary clicks. I just want to “npm install” a few third party libraries in the online IDE. (repl.it has a nice experience here). It’s frustrating to shuffle between my desktop, AWS and back again.

mikeparker2 6y ago

If we push an image with an AWS base image do we need to constantly update and rebuild + redeploy it or do you handle the base image updates behind the scenes (e.g. security patches) like normal lambda?

munawwar 6y ago

Would this end up cheaper than fargate spot pricing?

saurik 6y ago

So, apparently I am crazy for thinking that running zip is trivial whereas the ridiculous stack of tooling that surrounds the awkward nested format of docker containers is extremely annoying :/... with the new ability to accept large containers, can I now send you a larger zip, or if I want a larger lambda function am I going to have to use the docker container interface?