Bringing a bang to your serverless processes: Firecracker

New Years Eve fireworks

Amazon Web Services (AWS) Lambda‘s growing popularity is proof positive that serverless computing is for real. But wouldn’t it be nice if you had a better view of how Lamba’s function-as-a-service actually works? Or, better still, if Lambda’s inner workers were open-sourced so you could use them in your own serverless projects? Guess what? AWS has given us both with Firecracker.

Firecracker is a virtual machine (VM)-based technology that combines VM’s security with containers’ small size and speed. Firecracker VMs are designed to run single-purpose, transient, short-lived processes. It starts by building on Linux’s build Kernel Virtual Machine (KVM). This is a type-1 hypervisor, which works hand in glove with AMD and Intel processor’s inherent VM extensions.

Where Firecracker changes course from normal KVM is usually KVM is run in concert with Linux’s type 2 hypervisor QEMU. Firecracker, which runs in Linux’s userspace, drops QEMU entirely. Instead, it provides its own bare-boned virtual network, storage, a one-button keyboard, and a serial console. That’s it.

The net result is tiny, 5 MB of memory per microVM, which can be launched in as little as 125 milliseconds. You can also launch a ton of Firecracker VMs in a great hurry. AWS claims you can run thousands of secure VMs with widely varying vCPU and memory configurations on the same instance.

What can you do with such a minimal VM? You can do just enough, fast enough, to make hundreds of functions available to your programs as needed. Don’t believe you can really do that much? Think again. Both AWS Lambda and Fargate, AWS’s container compute engine, rely on Firecracker to deliver their services.

Yes, you could do the kind of things Firecracker does with containers, but by relying on a minimal VM, Firecracker is inherently more secure.

Think about it.  By default you can’t even run Secure Shell (SSH) on a Firecracker VM. You can only work with a Firecracker VM via its Universal Asynchronous Receiver Transmitter (UART)/serial console or its Representational State Transfer (REST). There’s next to nothing a would-be hacker can attack.

In addition, Firecracker processes are jailed using cgroups and seccomp BPF. A Firecracker microVM also only has access to a few, tightly controlled system calls. Last, but not least, in practice these microVMs are spun up, run, and die in a matter of minutes. By the time a hacker gets in, the instance is already gone. Sure, Firecracker can be cracked, but it’s not worth an attacker’s time to try to bust Firecracker microVMs.

That’s all very neat, but what makes Firecracker really interesting is that, since AWS open-sourced Firecracker, anyone can use it. That’s exactly what Weaveworks has done with Ignite. With Ignite, Weaveworks has married Firecracker with built-in GitOps management, which uses Git for its DevOps source of truth. On top of this, you can run your OCI and/or Docker container images.

That’s one interesting way to make the best of Firecracker, but the best may be yet to come. With its microVM’s tiny size and fast load speeds, Firecracker will also be ideal for Internet of Things (IoT) and edge computing use cases.

In short, whether you want to simply use Firecracker or add it to your own programs, Firecracker deserves your attention. Going forward, Firecracker will be an important building block in the cloud, edge and IoT.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.