[talawahtech]

The FAQs on the Firecracker website[1] specifically address the difference between Firecracker and Kata Containers. The main thrust being that they have decided not to use QEMU and have instead chosen a much more minimal "cloud-native" oriented approach that deliberately abandons certain features in order to gain greater security, efficiency and agility going forward. They also decided to implement it in Rust.

Based on the the responses I have seen from non-Amazon employees with experience in this space[2][3][4], it looks like their approach is solid.

It should also be noted that one of the main architects of Firecracker was formerly the project lead for QEMU[5][6]

1.https://firecracker-microvm.github.io/#faq

2.https://twitter.com/bcantrill/status/1067326416121868288

3.https://twitter.com/jessfraz/status/1067286831287418881

4.https://twitter.com/kelseyhightower/status/10672947809488322...

5.https://twitter.com/jessfraz/status/1067282499938721792

6.https://twitter.com/anliguori/status/1067293131366785024

[kraemate]

OK I had missed the kata containers blurb in the FAQ, thanks for pointing it out. In fact the tweets make my point: we are all so blinded by new shiny releases that we forget their highly incremental nature.

[talawahdotnet]

Sure, there are going to be some people that are excited by the fact that something seems new or just because it is written in Rust, but jessfraz and bcantrill certainly don't fall into those categories. They have a lot of experience with Operating Systems, VMs and containerization and I don't get the impression that they are eaisily impressed by shiny things. Note that they all work for or worked for AWS competitors (Google/MS/Joyent).

I think what is impressive about Firecracker is that they have chosen to reuse a lot of the right things (Linux/KVM/Rust) while also taking a new approach and rethinking important assumptions (No BIOS, no pass-thru, no legacy support, minimal device support).

In my opinion the Firecracker FAQs give sufficient mention to parallel projects and tools they have built on like Kata Containers, QEMU and crosvm. The developers certainly seem open to collaboration with those communities.

AWS doesn't have much of a track record in terms of leading an Open Source projects so some skepticism is understandable, but I think what we have seen so far is a very good start.

[bonzini]

As a QEMU developer, this is very exciting. Even though there are some differences in the approach to the device model, they are not important in the grand scheme of things and in principle there is no reason why QEMU could not serve the same uses as Firecracker. It's just like Linux runs on anything from 16MB routers to supercomputers, and it means there is a lot that we can learn from Firecracker.

In fact we are considering integrating a more secure language than C in QEMU, even though we're just at the beginning and it could be C++ or Rust depending on whom you are talking to. :) It's possible that this announcement could tilt the balance in favor of Rust, add it would be great if QEMU and Firecracker could share some crates.

[steveklabnik]

These days, I would expect bcantrill to be excited by something written in Rust :)

[bcantrill]

Hey now -- I'm not quite that easily impressed! ;) This is a problem domain that I have suffered in[1] -- and we have recently moved from KVM to bhyve[2] for several of the same reasons that motivated Firecracker. Not that it hurt that it was in Rust, of course... ;)

[1] https://www.youtube.com/watch?v=cwAfJywzk8o

[2] http://bhyvecon.org/bhyvecon2018-Gwydir.pdf

[steveklabnik]

Ha! I wasn't trying to imply that it would only take Rust, for sure. :)

I am excited that everyone seems very excited.