Live data from Hacker News

New for AWS Lambda – Container Image Support

aws.amazon.com

81–90 of 94 posts

Re: New for AWS Lambda – Container Image Support

#81

Earlier quoted context omitted.

> but what you are looking for already exists I'd say, and is Fargate. IIUC though, Fargate doesn't have "scale to zero" like Lambda and API Gateway. Then again, IMO, scale to zero and the associated cold starts probably aren't the best fit for handling HTTP requests that are waiting for an answer right now.

Cloud Run on GCP is the “run any container” solution that this isn’t. It scales to zero, responds immediately to an incoming http request and can handle up to 50 concurrent requests out of the one invocation for no additional cost.

[deleted]

Re: New for AWS Lambda – Container Image Support

#83
post #30
post #4

This is pretty cool, to me it looks like it's moving towards Google Cloud Run's feature set.

Not entirely. This is something we've been thinking about for years now and is really about tooling and developer workflow. That is where the biggest benefit is for this. - Chris - Serverless@AWS

Why doesn’t AWS have a google cloud like offering?

Re: New for AWS Lambda – Container Image Support

#84
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…

Would this end up cheaper than fargate spot pricing?

Re: New for AWS Lambda – Container Image Support

#85
post #46
post #37

Earlier quoted context omitted.

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

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…

FWIW, a little experimented I just ran showed me that with simple layers the cold start time of my little 3MB Go app was - - - -

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

Re: New for AWS Lambda – Container Image Support

#86
post #33

Earlier quoted context omitted.

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

We optimize and cache the image so cold starts times should be the same as with zip functions.

Hm, not what I observed so far. Same Go application taking 1.5s instead of ~50ms to cold start.

Re: New for AWS Lambda – Container Image Support

#88
post #50
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…

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?

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.

Re: New for AWS Lambda – Container Image Support

#89
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…

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?

Re: New for AWS Lambda – Container Image Support

#90
post #60

How hard would it be to write a tool that can run inside one of these containers responding to the AWS Lambda runtime API interface and proxying it to a regular HTTP server running on a port inside the container? Such a tool would mean I could take any existing HTTP container and turn it into an AWS Lambda Container Image just by adding the proxy process that translates between the lambda runtime and the internal HTT…

That would be like a ten line bash script (the AWS documentation on custom runtimes is actually just a shell script that uses curl to show how easy this is).
Post reply on HN