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

21–30 of 94 posts

Re: New for AWS Lambda – Container Image Support

#21

Post by nathankunicki »

newscom59 wrote: post #19
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…

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

I think you probably want Fargate for that.

This announcement is great if you need to package stuff inside your container for use at Lambda runtime.

Re: New for AWS Lambda – Container Image Support

#22

Post by [deleted] »

babyyoda wrote: post #16
mjb wrote: post #13

Earlier quoted context omitted.

You don't need to build from a Lambda specific base image - you can use (nearly) any base image you choose. Your application just needs to implement the Lambda runtime API, which we provide clients for in multiple languages.

Sure - and looks like runtime API isn't terrible, but still not a "lift and shift my express app as a Lambda" which I can do with Cloud Run

[deleted]

Re: New for AWS Lambda – Container Image Support

#23

Post by newscom59 »

dperfect wrote: post #20
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…

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

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

Re: New for AWS Lambda – Container Image Support

#24

Post by munns »

nathankunicki wrote: post #21
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…

I think you probably want Fargate for that. This announcement is great if you need to package stuff inside your container for use at Lambda runtime.

+1.

That's the idea. Run any container in Fargate. Now use the same tools you use to build/package those containers in Lambda.

Re: New for AWS Lambda – Container Image Support

#25

Post by munns »

dcu wrote: post #18
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…

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

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

Re: New for AWS Lambda – Container Image Support

#26

Post by [deleted] »

munns wrote: post #24
nathankunicki wrote: post #21

Earlier quoted context omitted.

I think you probably want Fargate for that. This announcement is great if you need to package stuff inside your container for use at Lambda runtime.

+1. That's the idea. Run any container in Fargate. Now use the same tools you use to build/package those containers in Lambda.

[deleted]

Re: New for AWS Lambda – Container Image Support

#27

Post by munns »

newscom59 wrote: post #19
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…

> 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 or installing native packages (RPMs) we're basically faced with reinvent Dockerfile... or just use Dockerfile. This is an over simplification of what's happening, but that was the initial spark of this, many many cycles ago.

I think this is still going to be really valuable for folks, but what you are looking for already exists I'd say, and is Fargate.

Btw, ppl shouldn't be downvoting this, its all very valid.

- Chris, Serverless@AWS

Re: New for AWS Lambda – Container Image Support

#28

Post by munns »

jacques_chester wrote: post #15
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…

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.

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

Re: New for AWS Lambda – Container Image Support

#29

Post by mcintyre1994 »

newscom59 wrote: post #23
dperfect wrote: post #20

Earlier quoted context omitted.

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

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

Re: New for AWS Lambda – Container Image Support

#30

Post by munns »

tebbers wrote: 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

Post reply on HN