Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firecracker: Lightweight Virtualization for Serverless Applications

amazon.science

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Firecracker: Lightweight Virtualization for Serverless Applications

#11

Post by kubeexpat »

bonzini wrote: post #8
srmatto wrote: post #2

I'm really excited to see where this goes in the community. There are some interesting projects using Firecracker such as Weave Ignite and firekube that I think could improve the security of Kubernetes. Also lightweight VMs are exciting in their own right. https://github.com/weaveworks/ignite https://github.com/weaveworks/wks-quickstart-firekube

How does firekube compare to Kata Containers?

They're almost sort of opposites? Firekube is the Kube control plane running on lightweight Firecracker-powered VMs. On the other hand, Kata Containers is a CRI runtime (like containerd or CRIO) that allows Kubernetes to schedule containers to start through Kata (which then allows the container to run via Firecracker or Qemu, IIUC). But also, I think in practice everyone uses Containerd/CRIO and then configure them to pass untrusted workloads onto Kata.

I'm not sure what to think of how all of this ended up.

Re: Firecracker: Lightweight Virtualization for Serverless Applications

#13

Post by bonzini »

mjb wrote: post #9
bonzini wrote: post #7

The comparison with QEMU is a bit disingenuous. The number of lines of code in a given binary is much less than 1.4 million, which is the total for all the architectures that QEMU supports (actually it's closer to 2 million). It is also possible to configure out a lot of the code and libraries. A default build is around 6-700.000 lines of code, and it is possible to build reduced versions that tally less than 300.000…

> QEMU is a complex program, as demonstrated by the complexity of measuring it accurately For sure. Our goal was a fair comparison, but any comparison by one set of criteria is going to paint an incomplete picture, especially of something like QEMU that does a lot and has a lot of buttons and knobs. This is further complicated by doing the comparison over a time span where both are moving targets (which is a good thi…

> All the details of our comparison methodology are here, if you are interested in the details of exactly what we ran and how: https://github.com/firecracker-microvm/nsdi2020-data

I am and this is awesome! Thanks for sharing it. And thanks for using the latest version of QEMU and the microvm machine type, that did make the comparison much fairer already.

> I saw the loss of velocity in the project, but couldn't find any details of why.

The Intel people moved on to work on Cloud-Hypervisor and a lot of the stuff done on NEMU was reworked (leading e.g. to the microvm machine type) and added to QEMU (such as disabling TCG on ARM). Before that however we collaborated to complete the configuration mechanism for disabling unwanted devices. [1] And we are still collaborating on rust-vmm, which is taking inspiration from QEMU for the more advanced parts of the design!

[1] https://qemu.readthedocs.io/en/stable/devel/kconfig.html

Re: Firecracker: Lightweight Virtualization for Serverless Applications

#17

Post by _msw_ »

mjb wrote: post #9
bonzini wrote: post #7

The comparison with QEMU is a bit disingenuous. The number of lines of code in a given binary is much less than 1.4 million, which is the total for all the architectures that QEMU supports (actually it's closer to 2 million). It is also possible to configure out a lot of the code and libraries. A default build is around 6-700.000 lines of code, and it is possible to build reduced versions that tally less than 300.000…

> QEMU is a complex program, as demonstrated by the complexity of measuring it accurately For sure. Our goal was a fair comparison, but any comparison by one set of criteria is going to paint an incomplete picture, especially of something like QEMU that does a lot and has a lot of buttons and knobs. This is further complicated by doing the comparison over a time span where both are moving targets (which is a good thi…

Some background on QEMU forks, and fork healing, is in this blog post: https://www.redhat.com/en/blog/all-you-need-know-about-kvm-u...
Post reply on HN