Today we’re happy to announce the Hyperlight Wasm guest based on the Wasmtime runtime. This makes it possible to run Wasm Component binaries on top of WASI interfaces without the need for a guest OS in the VM. In this post we explain how this works and walk through an example.
Firecracker is great if you want to securely execute an OS image. It has the benefit of compatibility with many existing programs, but that comes at the cost of some overhead.
Hyperlight is great if you want to securely execute program runtimes. This requires bespoke guest bindings, but it has the benefit of having less overhead.
There’s a place for both approaches, and I see both happily co-exist.
- If we take VMs as our boundary and compare cold start times, Hyperlight confidently comes out on top. That's 1-2ms vs 125ms+.
- If we take warm instances and measure network latency for requests, Hyperlight will come out on top if deployed to a CDN node (physics!). But if both workloads run in the same data center performance will be a lot closer.
- Say we have a workload where we need to transmux a terabyte of video, and we care about doing that as quickly as possible. A native binary has access to native instructions that will almost certainly outperform pure-Wasm workloads.
I think about Hyperlight Wasm is as yet another tool in the toolbox. There are some things it's great at (cold-starts, portability, security) and some other things it isn't. At least, not yet. Whether it's a good fit for what you're doing will depend on what you're doing.