Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New for AWS Lambda – Container Image Support

aws.amazon.com

Post reply on HN
Print view View original

71–80 of 94 posts

Re: New for AWS Lambda – Container Image Support

#71

Post by wwright »

013a wrote: post #70

This is fantastic news. I'm very curious about the invocation latency overhead of Docker. I assume its non-zero relative to the more native runtimes?

OCI in general doesn't need to have very much overhead at all; it's just a few syscalls after fork() and before exec() (that trivializes it a bit, of course). I wouldn't be surprised if native runtimes already do some of the same work; it's just good practice when designing mixed-trust systems on Linux.

Docker's specific implementation may offer other hurdles, of course, but AWS Lambda could easily use one of the many other implementations of OCI.

Re: New for AWS Lambda – Container Image Support

#72

Post by wwright »

simonw wrote: post #62
munns wrote: post #11

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…

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…

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.

Re: New for AWS Lambda – Container Image Support

#73

Post by catchmeifyoucan »

munns wrote: post #11

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…

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.

Re: New for AWS Lambda – Container Image Support

#74

Post by julianwood »

013a wrote: post #70

This is fantastic news. I'm very curious about the invocation latency overhead of Docker. I assume its non-zero relative to the more native runtimes?

Hi, I work in the AWS Serverless Team. Just to say, the performance of running a container image is pretty much the same as a function packaged as a zip function. We cache the container images near where the function runs so startup time isn't any worse than ZIP.

Re: New for AWS Lambda – Container Image Support

#75

Post by simonw »

wwright wrote: post #72
simonw wrote: post #62

Earlier quoted context omitted.

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…

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.

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).

Re: New for AWS Lambda – Container Image Support

#76

Post by scoopertrooper »

simonw wrote: post #75
wwright wrote: post #72

Earlier quoted context omitted.

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.

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 version…

This doesn't seem to me like something that should be a core part of the lambda product, but maybe some sort of simplified build pipeline service that has Lambda as a target.

Re: New for AWS Lambda – Container Image Support

#79

Post by mikeparker2 »

munns wrote: post #11

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…

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?

Re: New for AWS Lambda – Container Image Support

#80

Post by mikeparker2 »

mwcampbell wrote: post #55
munns wrote: post #53

Earlier quoted context omitted.

Thanks! Appreciate the feedback and hope this helps you out. Let us know if it doesn't :) - Chris

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 li…

Just a heads up we're trying to do that with Fargate right now and theres a limit to how quickly fargate can spin up new instances (like max 10 at a time); it's not well designed to do a single-execution-per-message right now, at least at a decent load.
Post reply on HN