Getting Started with Firecracker on Raspberry Pi(dev.l1x.be) |
Getting Started with Firecracker on Raspberry Pi(dev.l1x.be) |
I really don't like that diagram. The folks doing serverless work at University of Wisconsin-Madison generally do a good job, but they really whiffed on that one.
I don't think there's a reasonable sense in which KVM/Qemu moves more functionality to the guest kernel than KVM/Firecracker does. Both depend on the guest kernel for VM setup (KVM), low-level virtualization operations (KVM), and doing the actual IO below their paravirtualized device drivers. On the other end, Linux containers don't have a guest kernel (unless you use some kind of library OS). So those boxes should collapse together. If you look at it one way, gVisor is a guest kernel, which depends on the host kernel in fundamentally similar ways to what Firecracker or Qemu do.
I took the diagram to just mean the whole guest, not just the kernel. In the qemu case, the guest has to interact with the bios and other emulated peripherals. Firecracker skips the whole bios layer so it does operate at a different layer
The biggest impact is not to have JS and not to have a giant amount of HTML / CSS. That keeps the content very small. The syntax highlight is rendered at compile time.
Interestingly HN's front page is an order of magnitude smaller in uncached transfer size. It does include some JS, but the lower perceived snappiness seems to owe to longer round trip times (for me anyway ~60ms for HN vs ~10ms for dev.l1x.be).
But Firecracker is VMs, not containers.
Even beyond pure learning opportunities, though, there are good reasons to containerize applications even on a system as low-powered as a Raspberry Pi.
For example: if you have a k8s, Docker Swarm, Nomad (disclaimer: I work on the Nomad team @ HashiCorp), etc. orchestrator in place you can keep workloads up and running even as you take down individual machines. (This can help a lot for OS upgrades, replacing failing hardware, disk upgrades, etc. on a running cluster.)
Likewise, you can develop + test your containers on a more performant or convenient machine (like a PineBook Pro, or VMC on a Chromebook) and deploy to the Pi(s) without having to manually map your FS layout, dependencies, etc. to Raspbian or another Pi-specific distro.
It's not something you _need_ to do, necessarily, but neither does that mean there isn't value, esp. for folks already comfortable with a container-based deployment workflow.
I completely agree with you that there is a value in containers but everything has a price and so far I have yet to find project with the scale that does require all this overhead.
I had no problems making / working with / deploying containers on Azure when it was required by client. Since client is the king I do as instructed. For my own business or when I am the one making deployment decisions for a client I get away without containers.
I've been setting up Nomad on my pi cluster. I really like it. But the documentation really isn't up to speed, and there isn't really many avenues to get support. Sometimes I regret not doing K8s instead.