[Twirrim]

Why run a container? What value does that abstraction provide here?

To my mind this completely negates any value proposition of the container. The only thing missing, at face value, is something as straightforward as the Dockerfile for building base images. I imagine that shouldn't be hard using things like guestfish etc in guestfstools.

[sudhirj]

Want to run Ruby on Rails on Lambda, with no changes from the servers I run on my laptop. Or maybe I want to run Crystal. Or maybe I’m writing my own language. Doesn’t really matter.

Lambda works great as a deployment and execution model. This allows anything to run on Lambda, not just specially prepared runtimes.

[Twirrim]

It's a VM, right? So whatever you put in the base image will be available, just like with a container. It's just fast to provision and small.

[sudhirj]

In this case the base image is then a packaging format, which takes us back to building special AMIs for this. Used to do EC2 deployments like this in the early days, using Packer.io.

Prefer containers because build once run anywhere, as opposed to build for each deployment target.

[lilcorey10]

So essentially pairing Firecracker with Lambda will reduce Lambda down to a simple trigger that can spin up one of these VMs where before Lambda ran the code?

[sudhirj]

Yes, and the fact that each Lambda executor is a VM allows the execution of any code in any language using any server.

[nine_k]

Your container = your environment.

When your container is not running (say, 99% of time), other customers' containers are running. No need to ever boot the kernel, etc.

One might say that an unikernel has advantages over it. But it also has a higher barrier to entry.

[Twirrim]

It's a KVM microinstance. Your image = your environment. Same as with a container.