Re:Firecracker – Lightweight Virtualization for Serverless C...
by sudhirj on Tuesday November 27, 2018 @11:20AM
(#18543621)
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.
Re:Firecracker – Lightweight Virtualization for Serverless C...
by Twirrim on Tuesday November 27, 2018 @11:35AM
(#18543765)
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.
Re:Firecracker – Lightweight Virtualization for Serverless C...
by sudhirj on Wednesday November 28, 2018 @03:26AM
(#18550032)
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.
Re:Firecracker – Lightweight Virtualization for Serverless C...
by lilcorey10 on Tuesday November 27, 2018 @12:46PM
(#18544609)
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?
Re:Firecracker – Lightweight Virtualization for Serverless C...
by sudhirj on Wednesday November 28, 2018 @03:27AM
(#18550040)
Yes, and the fact that each Lambda executor is a VM allows the execution of any code in any language using any server.
Re:Firecracker – Lightweight Virtualization for Serverless C...
by nine_k on Tuesday November 27, 2018 @10:52AM
(#18543299)
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.
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.