serverless OS support

Serverless is a way of running code in the cloud where you upload just a small function and the platform runs it on demand, only when something triggers it, and you pay only for the moments it actually runs. The name is a bit misleading — there are still servers — but you never manage them; the platform conjures the environment when a request arrives and tears it down afterwards. Picture motion-sensor lights in a hallway: nothing is on until someone walks by, then a light flicks on instantly for just as long as needed, then off again.

What makes this hard, and why it is an operating-systems topic, is the cold start problem. When a function is triggered and nothing is already running, the platform must create an isolated environment for it from scratch — and it must do so in milliseconds, securely isolating untrusted code from thousands of other tenants, then often discard it seconds later. Ordinary process isolation is too weak (you are running strangers' code together) and a full virtual machine is too slow and heavy to spin up per request. So serverless drove new OS-level isolation technology: lightweight virtual machines and sandboxes designed to boot in a few milliseconds with a tiny memory footprint (a well-known example is Firecracker, a stripped-down hypervisor built for exactly this), plus tricks like keeping environments warm and reusing or snapshotting them to dodge the cold start. Unikernels and library operating systems are appealing here for the same reason: less to boot.

The honest framing is that serverless does not remove the operating system — it pushes the OS's classic jobs (isolation, fast startup, resource limits, fair scheduling among tenants) to their extreme and hides them from you. The real tensions are the trade-off between strong isolation and fast startup, and the awkwardness for workloads that need to keep state or run for a long time, since each invocation is meant to be short, stateless, and ephemeral.