8 ms·
New for AWS Lambda – Container Image Support
- sethhochberg 6y agoThis 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 container orchestration platform when you need it, and a lambda to run the same container image one-off when you don't need orchestration, feels like a best of both worlds. I like the idea of "serverless" being more "your packaged execution environment, running with no regard for the underlying host" than "your code, running with no regard for the underlying execution environment". EDIT: Disregard.... see the AWS team's responses in this topic for the full story, its not quite as convenient as anything packaged via standard container being able to run on Lambda
- babyyoda 6y agoWorth 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
- zrail 6y agoYou 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.
- mjb 6y agoYou 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.
- babyyoda 6y agoSure - 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 6y ago[deleted]
- rollingchunder 6y agoWas 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!
- julianwood 6y agoThere'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 https://twitter.com/hichaelmart/status/1333837825222078466
- tebbers 6y agoThis is pretty cool, to me it looks like it's moving towards Google Cloud Run's feature set.
- falcolas 6y agoOne 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.
- sofixa 6y agoHow so? With Google Cloud Run, you don't really interact with Knative or Kubernetes, so the underlying platform is a non-issue.
- jacques_chester 6y agoThere 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 6 months ago I would have said "fair enough, I would be cautious too". But the recent update to Knative's governance model largely resolves the problem, in my view. I would very much like to see AWS and MS involvement. [0] "Knative" is the correct spelling, FWIW. Disclosure: I work for VMware, which participates in Knative development. I also, like, wrote a book about it.
- bpodgursky 6y agoIt's pretty embarrassing for HN that this would be reflexively downvoted. It's 100% accurate.
- babyyoda 6y agoThat 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"
- dcardoza 6y agoThis 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.
- julianwood 6y agoThis 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.
- munns 6y agoHey 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
- jacques_chester 6y agoHi 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.
- munns 6y agoYeah, 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
- dcu 6y agohi Chris, maybe slightly off-topic but is there a chance to see gravitons and/or ML chips on Lambda? :)
- munns 6y agoCouldn't share future roadmap here, but these are some cool ideas :)
- newscom59 6y ago> 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.
- mcintyre1994 6y agoThis 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/ 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.
- julianwood 6y agoYes, 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.
- Corrado 6y agoAgreed! 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.
- k__ 6y agoAfter doing some K8s stuff in the past months, I'd rather prefer the direct ZIP upload to indirections with a registry.
- wiredfool 6y agoThis 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.
- deleted 6y ago[deleted]
- politelemon 6y agoCurrently it's only ECR, and public Docker hub. I hope they will support private registries soon.
- dabeeeenster 6y agoDoes this require API Gateway or can you run it directly via Application Load Balancers like regular Lambda?
- munns 6y agoThere's no impact of this feature to how you invoke your Lambda functions.
- dabeeeenster 6y agoAh great thanks. One more q: What about network latency on warm up when connecting to e.g. RDS?
- anderspitman 6y agoHow does this compare to fly.io?
- k__ 6y agoFly.io is more like a simplified Fargate. This is more like Lambda with Docker instead of ZIP. More code storage but same 15min runtime limit.
- simonw 6y agoHow 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 HTTP server.
- saurik 6y agoThat 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).
- underbluewaters 6y agoWhat would really open this up to new use cases now would be to drop the 15 minute timeout. I've got jobs I had planned to run in Fargate that would really be more appropriate for Lambda, but in some cases I need them to run as long as 90 minutes.
- 013a 6y agoThis is fantastic news. I'm very curious about the invocation latency overhead of Docker. I assume its non-zero relative to the more native runtimes?
- wwright 6y agoOCI in general doesn't need to have very much overhead at all; it's just a few syscalls after fork() and before exec() (that trivializes it a bit, of course). I wouldn't be surprised if native runtimes already do some of the same work; it's just good practice when designing mixed-trust systems on Linux. Docker's specific implementation may offer other hurdles, of course, but AWS Lambda could easily use one of the many other implementations of OCI.
- julianwood 6y agoHi, I work in the AWS Serverless Team. Just to say, the performance of running a container image is pretty much the same as a function packaged as a zip function. We cache the container images near where the function runs so startup time isn't any worse than ZIP.
- nojvek 6y agoSo this is google cloud run but in aws? Always been a huge fan of cloud run.
- richardanaya 6y agoRust base image? Is there some easy way to simulate api gateway + docker lambda locally?
- julianwood 6y agoHi, I work for AWS in the Serverless team. Yes you can run Api Gateway and Lambda locally for testing. Have a look at AWS SAM. https://github.com/aws/serverless-application-model https://github.com/aws/serverless-application-model