In fairness to this paper, it was written and published before that Firecracker article (2017 vs 2018). From another paper on Firecracker providing a bit of history:
> When we first built AWS Lambda, we chose to use Linux containers to isolate functions, and virtualization to isolate between customer accounts. In other words, multiple functions for the same customer would run inside a single VM, but workloads for different customers always run in different VMs. We were unsatisfied with this approach for several reasons, including the necessity of trading off between security and compatibility that containers represent, and the difficulties of efficiently packing workloads onto fixed-size VMs.
And a bit about the timeline:
> Firecracker has been used in production in Lambda since 2018, where it powers millions of workloads and trillions of requests per month.
No, it's using a modified version of the Xen hypervisor and the numbers they show are boot times and memory usage for both unikernels and pared down Linux systems (via tinyx). It's described in the abstract:
> We achieve lightweight VMs by using unikernels for specialized applications and with Tinyx, a tool that enables creating tailor-made, trimmed-down Linux virtual machines.
> When we first built AWS Lambda, we chose to use Linux containers to isolate functions, and virtualization to isolate between customer accounts. In other words, multiple functions for the same customer would run inside a single VM, but workloads for different customers always run in different VMs. We were unsatisfied with this approach for several reasons, including the necessity of trading off between security and compatibility that containers represent, and the difficulties of efficiently packing workloads onto fixed-size VMs.
And a bit about the timeline:
> Firecracker has been used in production in Lambda since 2018, where it powers millions of workloads and trillions of requests per month.
https://www.usenix.org/system/files/nsdi20-paper-agache.pdf