What this is allows, and I'm hoping a full fledged service will be announced on Thursday or Friday, is running containers as Lambdas. i.e. if you application starts fast enough, you can just set a container to start and run as a request comes in. It can also shut down when it's done running.<p>This allows things like per second billing for container runs, serverless containers (there's no container running 24/7, only when there's traffic), etc.
There's a Github Pages FAQ describing why it was made and how it fits with other solutions: <a href="https://firecracker-microvm.github.io/" rel="nofollow">https://firecracker-microvm.github.io/</a><p>and a high-level design document about how it works <a href="https://github.com/firecracker-microvm/firecracker/blob/master/docs/design.md" rel="nofollow">https://github.com/firecracker-microvm/firecracker/blob/mast...</a>
> Firecracker was built in a minimalist fashion. We started with crosvm and set up a minimal device model in order to reduce overhead and to enable secure multi-tenancy. Firecracker is written in Rust, a modern programming language that guarantees thread safety and prevents many types of buffer overrun errors that can lead to security vulnerabilities.<p>This is awesome! Really excited to try this out!
This is huge! It basically removes the VM as the security boundary for something like Fargate [1]. This should lead to a significant reduction in pricing since Fargate will no longer need to over provision in the background because VMs were being used even for tiny Fargate launch types.<p>It should hopefully eliminate the cost disparity between using Fargate vs running your own instances. Should also mean much faster scale out since you containers don't need to wait on an entire VM to boot!<p>Will be interesting to see what kind of collaboration they get on the project. This is a big test of AWS stewardship of an open source project. It seems to be competing directly with Kata Containers [2] so it will be interesting to see which solution is deemed technically superior.<p>[1] <a href="https://aws.amazon.com/fargate/" rel="nofollow">https://aws.amazon.com/fargate/</a>
[2] <a href="https://katacontainers.io/" rel="nofollow">https://katacontainers.io/</a>
Clear containers (now called kata containers) did this more than three years ago, with similar performance numbers (sub 200 ms boot times). It is frustrating, but not surprising, to see the same regurgitated solution receive this much excitement. The firecracker documentation also does not mention the similarity with prior work, oh well.<p>[Not affiliated with Intel in any way---just a long-time proponent of the clear containers approach.]
> microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers.<p>Reminds me of rkt + kvm stage 1 <a href="https://github.com/rkt/rkt/blob/master/Documentation/running-kvm-stage1.md" rel="nofollow">https://github.com/rkt/rkt/blob/master/Documentation/running...</a><p>Too bad it didn't take off.
This looks great, I’m just wondering what Amazon’s motivation for open sourcing it is. It seems like some pretty critical secret sauce for making services like Lambda and Fargate both secure and efficient.
My big question is: is this something only exciting for people doing lambda at massive scale?<p>Qemu is exciting technology and has paved the way for all kinds of interesting layers. So, creating a slimmed down improvement that really makes it faster and provides a new lambda-ish execution context is great.<p>I'm sure Amazon cares about that. I'm sure people doing millions of lambda calls a day care about that.<p>But, if I'm an entrepreneur thinking about building something entirely new, is there something I'm missing about this that would make me want to consider it?<p>Lambda and Firebase Functions are exciting partially because they break services into easy to deploy chunks. And, perhaps more importantly, easy things to reason about.<p>But that's not the big deal: the integration with storage, events, and everything else in AWS (or Firebase) is what really makes it shine. It's all about the integration.<p>When I read this documentation, I'm left wondering whether I want to write something that uses the REST API to manage thousands of micro vms. That seems like extra work that Amazon should do, not me.<p>Am I missing something important here? Surely Amazon will integrate this solution somewhat soon and connect it to all the fun pieces of AWS, but the fact that they didn't consider or mention it makes me think it is something I should not consider now.
I really hope this helps with the cold start times on Lambda. We were currently looking heavily into moving our API from Lambda to EKS, but if this impacts cold start times, I think we will look at how it ends up looking like in practice.
The crosvm and Rust have me intrigued. I was hoping for something like this since I saw the first hints of Rust showing up in ChromeOS in crosvm.<p>A compare/contrast with Kata Containers would also be interesting. Their architectures look similar. (Kata Containers [1] being another solution for running containers in KVM-isolated VMs, that has working integrations with Kubernetes and containerd already. Not affiliated, but I'm tinkering with it in a current project, though I'm also now keen to get `firecracker` working as well.)<p>Obviously, if nothing else, qemu vs crosvm is a big difference, and probably significant since my understanding is that Google chose to also eschew using qemu for Google Cloud.<p>[1]: <a href="https://katacontainers.io/" rel="nofollow">https://katacontainers.io/</a>
I’m very excited to play with this technology in the same way I love playing with Elixir/Erlang and userland concurrency models. I also love the <i>idea</i> of docker (and use it daily) but dislike the ergonomics. My first thought is, particularly with the emphasis on oversubscription, how does the kernel of the host schedule work?
still seems much slower than the model used by Cloudflare for what they call "workers."[1] A recent blog post a few weeks back was the subject of considerable discussion here[2], and it seems to me to be doing much the same thing as Firecracker, but still faster because there's less overhead. But maybe I'm missing something.<p>[1] <a href="https://blog.cloudflare.com/cloud-computing-without-containers/" rel="nofollow">https://blog.cloudflare.com/cloud-computing-without-containe...</a><p>[2] <a href="https://news.ycombinator.com/item?id=18415708" rel="nofollow">https://news.ycombinator.com/item?id=18415708</a>
"Process Jail – The Firecracker process is jailed using cgroups and seccomp BPF, and has access to a small, tightly controlled list of system calls."<p>So basically, a gVisor alternative?