What’s good enough for serverless cornerstone AWS Lambda seems finally to be good enough for other production environments as well, which is why the Firecracker project now officially sports the mark of a stable product: the version number 1.0.
Firecracker is a virtual machine monitor, much like Cloud Hypervisor, and was initially developed at Amazon Web Services to have a way of creating secure and lightweight virtual machines (so-called microVMs) for serverless computing environments.
The company went on to use the project in both AWS Fargate and Lambda for provisioning and running sandboxes for customer code, until it decided to share the Firecracker codebase under the Apache-2.0 License in November 2018.
Since then, the project gained quite a bit of attention and can now also be found in container related tooling like Kata Containers and VM manager Weave Ignite.
In the runup to the major release, the Firecracker team gave the project a proper once-over, making sure users have access to all sorts of adjustment screws. Amongst other things, admins can now configure the maximum payload size for PUT and PATCH requests, allow MMDS content to be supplied from a file, and make use of custom headers for MMDS requests.
The team also took the opportunity to slightly rework the tool’s jailer, a program isolating the Firecracker process for better security, as well. Starting with version 1.0, it can be run on systems that have their cgroup version set to 2, and provides a way to place microvm cgroups in custom cgroup nested hierarchies.
Of course the release also comes with a couple of bits and pieces for experimenting. Admins can for example set the newly added io_engine entry in the pre-boot block device configuration to Async to see what asynchronous request execution could do for their setup or configure the MMDS version to be used by the project. However, these features are currently in preview only, so using it in a production setup isn’t exactly advised.
Seasoned users should take a minute to read the release notes before considering an update, as changes such as the removal of the --node jailer and --seccomp-level parameter, could lead to breakage or unexpected behaviour in existing systems and might therefore need some extra attention during migration.