New for AWS Lambda – Container Image Support • Hacker News Board

Re: New for AWS Lambda – Container Image Support

#11

Post by munns » Tue, Dec 01, 2020, 5:59 PM UTC

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 try it out and we'd love feedback on how it can be better.

- Chris Munns, Lead of Dev Advocacy - Serverless@AWS

Re: New for AWS Lambda – Container Image Support

#12

Post by zrail » Tue, Dec 01, 2020, 5:59 PM UTC

babyyoda wrote: post #9

sethhochberg wrote: post #2

This feels like a pretty monumental change - my team(s) have historically avoided Lambda specifically because the local dev flow is such a pain and/or open to interpretation, but local dev tooling for building and working with containers is great. At the same time, creating task definitions for one-off tasks in ECS or similar is also kind of a weird workflow if the task is shortlived or event-driven. Using an actual…

Worth noting this isn't bring any application and publish as AWS Lambda, but rather build from a specific Lambda base image and package your Lambda code into it. Fargate likely closer to what you are describing here

You don't have to use their base image, you can implement the Lambda API if you want. They're supplying API toolkits for various languages.

Re: New for AWS Lambda – Container Image Support

#13

Post by mjb » Tue, Dec 01, 2020, 6:00 PM UTC

babyyoda wrote: post #9

sethhochberg wrote: post #2

This feels like a pretty monumental change - my team(s) have historically avoided Lambda specifically because the local dev flow is such a pain and/or open to interpretation, but local dev tooling for building and working with containers is great. At the same time, creating task definitions for one-off tasks in ECS or similar is also kind of a weird workflow if the task is shortlived or event-driven. Using an actual…

Worth noting this isn't bring any application and publish as AWS Lambda, but rather build from a specific Lambda base image and package your Lambda code into it. Fargate likely closer to what you are describing here

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.

Re: New for AWS Lambda – Container Image Support

#14

Post by mcintyre1994 » Tue, Dec 01, 2020, 6:01 PM UTC

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 able to think about lambdas as just a docker container in terms of tooling, and losing all the complexity associated with Lambda's custom code deployment logic will be a massive win.

Re: New for AWS Lambda – Container Image Support

#15

Post by jacques_chester » Tue, Dec 01, 2020, 6:01 PM UTC

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.

Re: New for AWS Lambda – Container Image Support

#16

Post by babyyoda » Tue, Dec 01, 2020, 6:02 PM UTC

mjb wrote: post #13

babyyoda wrote: post #9

Earlier quoted context omitted.

Worth noting this isn't bring any application and publish as AWS Lambda, but rather build from a specific Lambda base image and package your Lambda code into it. Fargate likely closer to what you are describing here

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

Re: New for AWS Lambda – Container Image Support

#17

Post by bpodgursky » Tue, Dec 01, 2020, 6:12 PM UTC

jacques_chester wrote: post #8

falcolas wrote: post #5

Earlier quoted context omitted.

One small note - Cloud Run is KNative as a service. Lambda is divorced from Kubernetes. Personal opinion - I prefer Lambda over KNative. KNative feels like more of a shoehorn into Kubernetes than most other projects. Lambda feels more mature. Still glad to see this move, regardless.

There are two versions of Cloud Run. The fully-managed cloud-only variant is actually an API skin over Google App Engine. The "for Anthos" (née "for GKE") variant is Knative[0] in both API and sourcecode. AWS could plausibly do exactly the same thing: provide a skin over Lambda that speaks Knative. I think Amazon's and Microsoft's reluctance to wade into Knative has been wariness about Google's intentions. And maybe…

It's pretty embarrassing for HN that this would be reflexively downvoted. It's 100% accurate.

Re: New for AWS Lambda – Container Image Support

#18

Post by dcu » Tue, Dec 01, 2020, 6:13 PM UTC

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? :)

Re: New for AWS Lambda – Container Image Support

#19

Post by newscom59 » Tue, Dec 01, 2020, 6:13 PM UTC

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 platform-specific customizations within the container. I pretty much don’t care at all for this as-is.

Are there plans for “run any container on Lambda”? That’s what everyone was (falsely) excited about.

Re: New for AWS Lambda – Container Image Support

#20

Post by dperfect » Tue, Dec 01, 2020, 6:22 PM UTC

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…

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