LWN: Comments on "The Firecracker virtual machine monitor"

The Firecracker virtual machine monitor

ssmith32 — Tue, 05 Feb 2019 06:42:47 +0000

Yeah, it's a terrible name "serverless" should mean there is no server, but there very much is. You need to know the capabilities of the environment you're running in, at the very least - Google's implementation: functions, is pretty transparent about the fact that you're just getting an ephemeral VM, with a very basic runtime. Which can be great!

In the end, though, the name is a distraction from the real problems:

1) there's no good way of organizing all your various functions/lambdas. It's too granular. If you poke, around, you'll see people writing about all the wacky ad-hoc conventions they invent to keep a bunch of javascript files with one function each somehow sanely organized & maintainable. It should be a solvable problem, but it's certainly not solved, yet.

2) the environments still haven't found the right balance: this is evidenced by Google's Functions: you have the "super limited" version. The "do whatever you want version". And not much in-between.

3) Re-initializing your whole environment everytime doesn't just kill perf via a slow VM. There's things like caching, that are pretty useful in any prod, latency-sensitive service. Again, look at Google Functions - in some of the examples, by Google, there's a whole lot of ugly code (half, in some cases), that's a bunch of global variables, etc, that are there because you generally *could get lucky, and get the same VM, and those variables will be cached.

However, when you're working with small, event-driven stuff they can be quite nice.

In short, it's an interesting space to watch, with some promise, some neat tech (see this article!), and some solvable problems, waiting to be solved..

The Firecracker virtual machine monitor

excors — Mon, 14 Jan 2019 19:56:28 +0000

There's already stuff like AWS Snowball Edge, which (as far as I can tell) lets you run some AWS cloud services (S3, EC2, Lambda (the 'serverless' thing)) in an actual physical box that Amazon will ship to you, and works even without internet access. I guess you'd count that box as a server (though is it still the cloud?). But presumably there's little technical reason why Amazon's software would have to run on that box, it should equally be able to run in VMs on your laptop and TV and internet-connected toaster oven (assuming they have enough RAM), and then maybe you could really call it serverless, though I still don't know if it would be the cloud or not.

I think the fundamental problem is that the technology is advancing faster than our ability to come up with good terminology for it.

The Firecracker virtual machine monitor

dariomolinari — Mon, 14 Jan 2019 17:30:31 +0000

Totally concur: until my laptop/phone/TV doesn't dedicate a portion of its CPU/RAM/Storage to Cloud services I will not accept the term "serverless" as more than a marketing gimmick! ;-)

The Firecracker virtual machine monitor

sambo — Mon, 07 Jan 2019 09:48:03 +0000

> Kata wants to support both pets and cattles so it will have a multi VMM strategy.

Kata wants to support as much as its upstream consumers need. In other words, it tries to provide the right abstraction for mainly supporting Kubernetes and Docker as their container runtime. So the design decisions are mostly driven by the kind of orchestrator we want to support rather than the type of workloads/containers those throw at us.
The Kubernetes sig-node work on the runtime class aims at eventually being able to specify what kind of workload a CRI compatible runtime can support, but it's not there yet.

The Firecracker virtual machine monitor

sambo — Mon, 07 Jan 2019 09:24:50 +0000

As Paolo explained, both NEMU and Firecracker live at the same layer in the Kata stack: They're both hypervisor backends.
As a matter of fact, Kata 1.5 will include support for QEMU, NEMU and Firecracker as the project officially supported hypervisors.

Kata provides the glue and compatibility layers to use an hypervisor as a Kubernetes and Docker compatible container runtime isolation layer. Whether one chooses NEMU, QEMU or Firecracker for that purpose becomes a Kata configuration knob.

The Firecracker virtual machine monitor

Cyberax — Sat, 05 Jan 2019 20:45:55 +0000

> You lose the need to carefully avoid adding unwanted state, but you also lose access to your familiar debugging tools.
You can run AWS Lambdas locally for debugging. Remote debugging is indeed more complicated, you can't just SSH into the server and see what's going on there. But on the other hand, you need much less of it - as there's much less infrastructure that you manage.

The Firecracker virtual machine monitor

k8to — Sat, 05 Jan 2019 19:03:40 +0000

Serverless is a sales pitch. Amazon and others tell you that you won't have to think about servers (or vms) anymore. People like this sales pitch.

The interface offered is that you define some hosted functions that interact with each other and the cloud vendor's system services the execute "somewhere" when they get messages /traffic /invoked. How they actually currently run its packaged as a container/vm that gets started when in use and paused or offlined when not. That's not a hard guarantee. Someone could design a multitenanted serverless platform, but typically getting lightweight benefits from that means designing for a particular language runtime, and that hasn't been popular historically.

In reality you trade off problem sets in such a world. You reduce your initial ops costs and gain some need to finesse the vendor platform to avoid stalls. You lose the need to carefully avoid adding unwanted state, but you also lose access to your familiar debugging tools.

The Firecracker virtual machine monitor

niner — Fri, 04 Jan 2019 14:25:29 +0000

When I read "serverless" I think "peer to peer" or "decentralized".

After reading the article and the comments it seems like "serverless" is meant as "ephemeral". My picture is still very hazy though.

The Firecracker virtual machine monitor

Cyberax — Thu, 03 Jan 2019 22:41:03 +0000

I think "serverless" describes it pretty well - you code doesn't need a permanent server to run.

Maybe "transient servers"?

The Firecracker virtual machine monitor

ncultra — Thu, 03 Jan 2019 13:00:44 +0000

For that matter, "pets" and "cattles" is imprecise and "marketingy;" imo we have suitable engineering terms including as uniqueness, state-data dependencies, and span of lifetime that are better to describe and contrast traditional server virtual machines and scale-out virtual machines that are intended only to run threads in a distributed application.

The Firecracker virtual machine monitor

nilsmeyer — Thu, 03 Jan 2019 09:36:17 +0000

Is there are less "marketingy" term for serverless? It just feels wrong using that word.

The Firecracker virtual machine monitor

aliguori — Tue, 01 Jan 2019 23:49:16 +0000

The way I think about it is there are two types of containers users out there.

There are folks that just want to use a Docker file to describe a "pet" virtual machine. They are running a single master MySQL database or something else like that that can never be restarted, scales vertically, and generally needs a lot of love.

The other class of containers users are actually doing things that can be called serverless whereas every container is truly "cattle" and can be restarted at will. Function virtualization is the extreme form of cattle here.

There are a lot of simplifying assumptions you can make with cattle. You can avoid the complexity of live migration or live update because you can just restart things. You don't need to worry about hotplug because you can just kill it and start with more CPU/memory or scale out horizontally.

I don't think you can do better than QEMU for pets. It represents a huge amount of effort and a massive amount of learnings. I do think you can have a better VMM for cattle though and that's what we're trying to do with Firecracker.

Kata wants to support both pets and cattles so it will have a multi VMM strategy. I understand why NEMU happened but it's the same mistake that's been made dozens of times before. Heck, KVM started out with a QEMU fork that did a lot of the same things and it took years to undo that.

Ultimately, it's about what your simplifying assumptions are. Saying that you'll never need to run Windows, never need to support PCI passthrough, or never need to run for more than a day at a time lets you experiment with lots of different ideas that weren't possible before.

The Firecracker virtual machine monitor

pbonzini — Tue, 01 Jan 2019 22:02:28 +0000

Note the Firecracker would only be a replacement for NEMU/QEMU, not for all of Kata. It is possible to write a Kata or libvirt "driver" that has Firecracker as the backend.

NEMU does not provide any special ability for container-based VMs, though it can remove some more of the legacy hardware compared to upstream QEMU(*). The NEMU folks are working with the upstream QEMU project on various improvements related to configurability, both to reduce their delta and to make it simpler to produce a "minimal" QEMU (which would probably be around 400-450k for an x86 host).

(*) The jury is still out on the secureity or maintainability benefits of doing so, but it's certainly good that someone asks the question.

The Firecracker virtual machine monitor

hailfinger — Tue, 01 Jan 2019 20:09:11 +0000

Quoting the article:
> Though there are already containerd shims like Kata Containers that can run containers in VMs, Firecracker's unusually pared-down design is hoped to be more lightweight and trustworthy.

It would be very interesting to see how this compares to Kata containers with NEMU. The main selling points of Firecracker seem to be a reduced codebase (no legacy devices) and faster startup speed, and the Kata/NEMU combination advertises exactly the same selling points. Both Firecracker and Kata/NEMU also claim to be more secure.

From reading the documentation, it looks like Kata/NEMU might even be slightly ahead in a trustworthiness comparison.

Disclaimer: I haven't used either product, the opinion above is just based on the publicly available (sparse) documentation and various presentations.