Recently open-sourced Cloudflare workerd is a new Web runtime for JavaScript/Wasm applications that shares most of its code with the runtime used by Cloudflare Workers. Workerd is based on standardized Web APIs and aims to enable a new approach to microservices removing their intrinsic latency, says Cloudflare.
The new architectural model, dubbed nanoservices, while keeping the benefits provided by microservices in terms of deployability and scalability, reduces the request overhead close to that of a library call. This is achieved by configuring multiple workers to run in the same process and suggests nanoservice architectures can reach finer-grade granularity than microservices usually stop at to prevent their associated latency and management costs outweigh the benefits.
Each Worker runs in a separate "isolate", which gives the appearance of running independently of the others: each isolate loads separate code and has its own global scope. However, when one Worker explicitly sends a request to another Worker, the destination Worker actually runs in the same thread with zero latency.
To make this possible, Cloudflare engineer Kenton Varda explains, workerd is designed differently than most other runtimes, including node and deno. Running multiple nanoservices inside the same process is accomplished by relying heavily on V8 isolates, with each nanoservice residing in its own isolate to ensure separate code loading and private global space. In addition, workerd built-in APIs are all native and shared by all V8 isolates hosted in the same process. This is key to the promise of nanoservices to grow in number without increasing the cost for their operation.
As a consequence of this, workerd promotes homogeneous deployment, another significant departure from the microservice model, whereby you deploy hundreds or even thousands of nanoservices on a single machine, says Cloudflare.
Homogeneous deployment means that you don't have to worry about scaling individual services. Instead, you can simply load balance requests across the entire cluster, and scale the cluster as needed. Overall, this can greatly reduce the amount of administration work needed.
This is exactly how Cloudflare's edge servers work, remarks Varda, by running the whole software stack on each server, which enables any server to respond to any request, with great benefits for scalability.
Another area where workerd differs from other runtimes is in the way it handles access to external resources. Instead of giving access to all resources by default, a workerd application is required to specify exactly which capabilities it needs, e.g., authentication, and access them through environment objects. This approach makes workerd apps totally immune to SSRF attacks, says Varda. Other advantages are the possibility of listing all internal services used by an application or easily replacing them, for testing or other purposes.
In a comment on Hacker News, Varda confirmed a few low-level details about workerd's implementation. Specifically, workerd uses a V8 fork with a couple of patches to customize the isolate abstraction and most of it is implemented in C++ using Bazel as a build system. For schema definition, workerd relies on a mix between CapNProto and Protocol Buffers.
It must be noted that workerd, contrary to Cloudflare Workers, is not a full-fledged compute platform and while it allows developers to local-test their Cloudflare Workers in an environment similar to the one they would use in production, it is only small part of the whole system. This means that to effectively use workerd in production, you should also concern yourself with security sandboxing, deployment mechanisms, orchestration, and more. Anyway, while it is true that Cloudflare has not open-sourced the rest of their Workers platform, in principle you should be able to use workerd with any other server/VM/container hosting and orchestration system to self-host your application or move it to a different vendor.
