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

31–40 of 94 posts

Re: New for AWS Lambda – Container Image Support

#31

Post by newscom59 »

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.

No, Fargate isn’t that at all. Google Cloud Run is what you meant to say.

This is of course still valuable to allow container-based workflows to adapt to Lambda, but it really seems like AWS missed the mark on identifying why people really want to use containers. Just one look at the amount of people on HN threads or on Reddit excited at using “arbitrary containers on Lambda” should tell you what people really wanted - and now they have to come away disappointed.

Re: New for AWS Lambda – Container Image Support

#32

Post by riquito »

babyyoda wrote: post #10
tebbers wrote: post #4

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

That was my initial thought too, but looks like these lambdas have to derive from a specific set of Lambda base images. Cloud Run lets your publish ANY docker container from any base image. So this feels much more like a deployment and development feature of Lambdas and not "run any container as a Lambda"

> looks like these lambdas have to derive from a specific set of Lambda base images

About that, you don't need to use their base images, "You can deploy your own arbitrary base images to Lambda"

Re: New for AWS Lambda – Container Image Support

#33

Post by orasis »

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…

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

Re: New for AWS Lambda – Container Image Support

#34

Post by drakej »

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…

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

Re: New for AWS Lambda – Container Image Support

#35

Post by julianwood »

orasis wrote: post #33
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…

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.

Re: New for AWS Lambda – Container Image Support

#36

Post by julianwood »

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…

Yes, with the new container image support, you can use the same docker or ECR images to build, and test your functions locally, and run them on Lambda. Consistent images is super useful.

Re: New for AWS Lambda – Container Image Support

#37

Post by nlg »

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

Re: New for AWS Lambda – Container Image Support

#38

Post by julianwood »

rollingchunder wrote: post #3

Was already working through porting my startup’s web app from docker to lambda via layers and such, but it was a hassle. Then I read today about the 1ms billing and got motivated. THEN I see this about running containers, my life just got much easier. What a time to be alive!

There's going to be a lot more information coming about this over the next 3 weeks during re:Invent. A good outside-AWS blog post is this one: https://twitter.com/hichaelmart/status/1333837825222078466

Re: New for AWS Lambda – Container Image Support

#39

Post by munns »

drakej wrote: post #34
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…

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

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

Re: New for AWS Lambda – Container Image Support

#40

Post by drakej »

munns wrote: post #39
drakej wrote: post #34

Earlier quoted context omitted.

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

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

Awesome. Very excited about this!
Post reply on HN