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

41–50 of 94 posts

Re: New for AWS Lambda – Container Image Support

#41

Post by julianwood »

dcardoza wrote: post #6

This is great. I recently went through the exercise of deploying a periodic lambda function using AWS SAM. The development workflow was great, except when I needed binary dependencies for the MSSQL database driver. Learning and using Lambda layers was cumbersome and the bulk of the dev time. This change will make the lives of engineers in docker shops much easier.

This should make things easier if you're mature in container tooling. AWS SAM recently added much better support for Lambda Layers, and you can use makefiles etc. there. In fact, I would say building layers with SAM is probably the easiest way to build layers! Now you get to try with container images.

Re: New for AWS Lambda – Container Image Support

#42

Post by Corrado »

mcintyre1994 wrote: post #14

This is awesome! Last I looked into it AWS' SAM tooling for running locally actually worked by using third-party docker images that were somehow built by ripping the file system from Lambda, and hooking your code up as a volume (and optionally adding layers as volumes) and then pointing `aws lambda invoke` commands at it. It was all built on https://hub.docker.com/r/lambci/lambda/ Having official base images, being a…

Agreed! Testing AWS Lambda functions that have any complexity to them at all is frustrating. Even using the SAM tools, I found it difficult to test reliably. Specifically, things like environment variables and bundled executables were a pain to get exactly correct. I'm looking forward to using containers in Lambda functions and improving the tooling.

Re: New for AWS Lambda – Container Image Support

#44

Post by wiredfool »

This solves two big pain points for me:

1) the 250 mb size limit.

2) trying to get some tricky dependencies into a lambda compatible image.

Ive got one build system that was going to have to move off lambda in the next few months because of the size issue. We’re shipping a slowly changing node modules directory to lambda, and then repeatedly building an app with them.

We’re also doing perf testing with lighthouse, and that was a pain and a half to get packaged. This should make it far simpler.

Re: New for AWS Lambda – Container Image Support

#46

Post by munns »

nlg wrote: post #37
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…

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 be cheaper for that workload, especially with the new 1ms billing.

- Chris - Serverless@AWS

Re: New for AWS Lambda – Container Image Support

#48

Post by mwcampbell »

munns wrote: post #27
newscom59 wrote: post #19

Earlier quoted context omitted.

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

1. Sorry you are disappointed by this. 2. This is why I wanted to post here, to make it really clear. Andy only got to spend a few seconds on this and couldn't get into all the nuances. The launch post does, and we'll have more posts over the next 3 weeks just on this topic. Containerization solves a few things. One big one was the container image as a packaging model. As customers struggle with dependency management…

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

Re: New for AWS Lambda – Container Image Support

#49

Post by NicBuihner »

mcintyre1994 wrote: post #29
newscom59 wrote: post #23

Earlier quoted context omitted.

> you can run any container ( 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,…

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

I think your integration comment is spot on but might be an apples and oranges thing. On GCP everything is an HTTP request with an id_token in the header and event in the body, almost surprisingly so. As a result services like Cloud Functions and Cloud Run containers are quite literally just generic HTTP handlers. I suspect the integration feel of Lambda, which I agree with, might be a consequence of inter-service communication on AWS being relatively proprietary, or if that's not the right word, custom? Maybe the loose feeling of GCP is because everything is an HTTP request? It's almost like all of GCP runs on a built-in HTTP API Gateway setup by default. Honestly most of the time I feel like I'm living in HTTP-Request-land anyway, so not having to context switch when working with the platform is kind of nice sometimes.

Re: New for AWS Lambda – Container Image Support

#50

Post by ngrilly »

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…

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?
Post reply on HN