Discover more from Matt Rickard
Will v8 Isolates Coexist With Containers?
Long term, will v8 Isolates become the basis of a generalized computing platform, or will containers1 (or some other type of software container)? Or will there continue to be separate infrastructure, application, and edge runtimes?
The isolation technologies are complementary today – they make different trade-offs with cold starts, security boundaries, and resource profiles. You'll find v8 Isolates powering edge functions like Cloudflare Workers (but not Lambda@Edge). However, there are many public and private companies working to make isolates more generalized – hardening the security boundary, improving the cold starts, and expanding the supported languages (through WebAssembly).
There are three areas that the different isolation techniques optimize for:
How they stack up:
Cold starts (v8): v8 Isolates are much faster than the rest. Virtual machine managers like Firecracker (which powers Lambda, Lambda@Edge, and Cloudfront Functions) require more capacity and potentially have a slower start (depending on the use case and benchmark).
Security boundary (VM): v8 has a large and complicated attack surface. Containers to a slightly lesser degree. VMMs like Firecracker have a smaller attack surface and a more hardened boundary. VMs have more historical hardening. But as we saw, some vulnerabilities can affect all layers (e.g., Spectre). The question is whether or not these can be mitigated (see v8 and Spectre).
Packaging (containers): Containers allow developers to ship an entire filesystem and its OS-level dependencies. This is powerful for lift-and-shifting existing applications to the cloud. On the other hand, WASM on v8 forces you to ship a single statically-linked binary. Easier deployment experience, but more restrictive. Debugging containers is difficult, but I'd argue that the debug workflow is still much easier than sorting through WebAssembly bytecode or, worse, a micro VM.
Resource Limits (depends): Running code at the edge means many different replicated regional deployments. You can't fit enough container images on a single machine to do this efficiently. v8 Isolates are small and run on a single thread. Resource monitoring is a little more complicated with isolates but progressing quickly.
I've written about how WebAssembly can be used to extend applications through plugin systems, browser execution sandboxes, and more. But will WebAssembly be the default serverside deployment target?
WebAssembly and its serverside runtimes must reinvent a significant portion of the stack to reach parity with current tools (the browser is the OS). Whether or not that's worth it, it's to be determined.
It might come down to developer experience. How easy is it to package and deploy an application? How easy is it to run locally close to production parity? How quickly can a developer debug something that's going wrong? I'm biased (as someone who has worked on container tooling) towards containers. Sure they are sometimes bulky, and it's challenging to write a good Dockerfile, but things generally work the same everywhere. Of course, you can bring your own toolchain and debugging tools.
But v8 isolates offer a more granular form of isolation, and time has shown that computing generally moves towards granularity. There's so much value in having lightweight process automation at the edge.
1I'm talking about OCI (Open Container Initiative) container format and runtime, e.g., Docker images and containers.