Firecracker Open Source Update May, 2019

中文版 – It’s been six months since we launched Firecracker at re:Invent, and we’ve been thrilled by the reception that the open source community has given us. Over these six months, we have merged 87 commits from 30+ external contributors into the Firecracker master branch (representing ~24% of all commits in that time span). These contributions covered device model virtio spec compliance, support for CPUs without one-GiB hugepages, and memory model improvements, as well as improvements in documentation, API specification, testing, and bug fixes. Open source users have also filed about a dozen bug reports, and we’ve received community feedback for several RFCs. The Firecracker repository on GitHub now has over 450 GitHub forks, and there are over 900 people on the Firecracker Slack. We’ve also been excited to see several other open source teams working in the containers/serverless compute space integrating Firecracker with their projects, including Kata Containers, UniK, and OSv. Intel also recently launched “Cloud Hypervisor,” leveraging code from rust-vmm, Firecracker, and crosvm.

In this post, we’ll report on what’s going on now in the Firecracker repo and the milestones that we’ve already planned for the next few months, and, most importantly, get your input for future roadmap items.

Current work

So far in 2019, we have worked on defense in depth, ease of use, AMD and Arm CPU support, and vsock. To improve isolation in a high-density, multi-tenant scenario, we added the option to dynamically adjust rate limiters, added a metric for guests spoofing their MAC address, and defaulted Firecracker to the strictest seccomp level. Usability improvements for engineers working with Firecracker include better API documentation, more dev tools, and clearer error/panic information. With Firecracker 0.16.0, we released alpha AMD support (we still need to get automated testing up and running) and Arm is coming along well. We also spent some time thinking about the right way to support vsock in Firecracker (we’ve received a lot of feedback from the open source community, thanks!), and that implementation is now in progress.

Ahead in 2019

Continuing to raise the security bar for Firecracker, we want to apply fuzzing to the device model and support block device encryption as an additional layer of isolation in specific use cases. We’re going to continue iterating on our continuous integration system to make test runs more granular, to make adding new platforms easy, and to improve test run report clarity. We would also like to know whether the GitHub releases (which include code and binaries) fit existing consumers. Should we maintain something like a Snap package? Are there other forms of software distribution that we should look at?

Next, we want to figure out how to support inference acceleration. While GPU passthrough and oversubscribed serverless compute workloads don’t mix well technically, accelerated inference computation in a function or in a container-based microservice seems like a natural use case. We’d love to hear your feedback and ideas on this one.

Finally, as much as we had hoped to one day be a part of the versioning revolution vanguard, once we close on AMD and Arm CPU support, vsock, and the CI, as well as settle on an approach for API stability, we will declare Firecracker v1.

Your ideas and use cases!

At AWS, 90-95% of our roadmap is driven by customers. This is the time of the year when we plan for 2020, and we’re eager to take in proposals from everyone in the open source community. So please tell us what you want to see in Firecracker by adding your ideas, asks, and use cases to this 2020 Roadmap RFC. Of course we’ve already given the existing feature requests some thought, but we’ll be happy if you come up with more! While we encourage everyone to think big, we will ensure that the resulting roadmap aligns with our mission of enabling secure, multi-tenant, minimal-overhead execution of container and function workloads.

Next post

We’ll keep in touch with more posts like this one. Our next blog post will discuss our tenets, talk about how rust-vmm relates to Firecracker’s future, and present the Roadmap we set for 2020.