Sergey Nivens - Fotolia
AWS Firecracker has the potential to put the VM vs. container debate to bed, but it still needs support for additional processors and integration with container orchestration tools.
In November 2018, AWS introduced Firecracker, an open source virtualization technology that offers the isolation and security of VMs, with the agility and performance of containers. The technology addresses the need for a virtualization platform that's optimized for event-driven, short-lived workloads, such as those for serverless computing.
Firecracker is available under the Apache License, version 2.0, which enables organizations to freely use, copy and distribute their changes to the technology.
Introducing AWS Firecracker
Firecracker uses the KVM module built into Linux to launch lightweight microVMs in non-virtualized environments. MicroVMs support secure, multi-tenant execution of container-based and function-based workloads without incurring undue overhead.
The Firecracker technology is already used extensively in the AWS platform to support high-volume services such as Lambda and Fargate. Lambda uses the technology to provision and run secure sandboxes that execute customer functions. Fargate uses the technology to run container-based tasks faster and more efficiently. In both cases, Firecracker helps to improve resource utilization and customer experience, while also ensuring secure service delivery.
At the heart of the AWS Firecracker technology is the microVM, which offers the advantages of a VM but with a much smaller footprint. Admins can provision a microVM in a fraction of a second at minimal operating expense. As a result, admins no longer need to choose between VMs and containers, nor do they need to deploy containers in VMs.
Firecracker takes a minimalist approach by design, focusing on transient or stateless workloads rather than long-running processes and stateful operations. The technology includes only what's needed to run secure, lightweight virtual environments, while also excluding all the unnecessary devices and functionality.
Firecracker boots with a minimal configuration, without implementing a complete device model or employing an emulated BIOS. A microVM launches in as little as 125 milliseconds and requires less than 5 MiB of memory. Each microVM also includes an in-process rate limiter to optimize shared network and storage resources. One server can support thousands of microVMs with widely varying processor and memory configurations.
AWS Firecracker architecture
The Firecracker technology has its roots in Chromium OS Virtual Machine Monitor (crosvm), an open source virtual machine monitor (VMM) that runs VMs in the the Linux KVM interface. Like crosvm, Firecracker is written in the Rust programming language, which guarantees thread and memory safety, while also preventing buffer overrun errors.
Firecracker implements a KVM-based VMM to host microVMs. The system runs in the user space and provides a mechanism to accelerate kernel loading. In addition, AWS Firecracker comes with a metadata service to securely share configuration information between the host and guest OSes. Firecracker also exposes an API endpoint for admins to create, manage and start microVMs. The API conforms to the OpenAPI Specification, which provides a description format for REST APIs.
Admins can use the API to carry out a number of tasks. For example, they can configure the number of virtual CPUs and memory size, specifying any combination of processing and memory resources to meet their application requirements. They can also create rate limiters, configure the metadata service, add disks and network interfaces, change the backing file for a block device, configure the logging and metric system, and perform other tasks.
AWS Firecracker provides multiple levels of isolation and protection to help secure workloads. In addition to faster startup times and increased resource utilization, its minimalist design can result in a smaller attack surface area than with traditional VMs. The technology also includes compute security barriers to support multi-tenant workloads, while also treating all workloads as malicious operations that require the highest levels of security.
Firecracker uses Linux control groups and secure computing Berkeley Packet Filters to jail the Firecracker process, while also limiting the process to a small, controlled list of system calls. In addition, the process is statically linked, which means all the libraries are included in the executable code, eliminating outside libraries altogether. Admins can also launch the Firecracker process from a jailer to help ensure safer execution.
Implementing AWS Firecracker
Admins can download Firecracker from GitHub and run it on AWS bare-metal instances or on bare-metal servers with Intel processors. AWS is due to add support for Advanced Micro Devices and ARM processors sometime in 2019. Firecracker developers are also working on methods to enable container runtimes such as containerd to manage containers as microVMs, making it possible for Docker, Kubernetes and other container orchestration tools to use Firecracker.
Currently, the Firecracker project is releasing a new version to the GitHub repository about every one or two months, with most of the effort coming from just a handful of developers. However, this is an active open source project, and the team is ready to review and accept pull requests from others in the community.
Given Firecracker's potential to bridge the gap between containers and VMs, it's an effort that's likely to generate more interest going forward and that will continue to grow in scope, especially with Amazon's influence in the industry.