Hyperlight Wasm points to the future of serverless

Back when I first wrote about Hyperlight, Microsoft’s minimal hypervisor, I speculated that it had a possible role as a WebAssembly-based alternative to serverless computing tools like Azure Functions, using Kubernetes as a host. So it wasn’t too surprising that Microsoft announced a new OS-free host for WebAssembly code based on Hyperlight.

The new Hyperlight Wasm builds on two Hyperlight features that Microsoft has demonstrated in the past few months. First, Hyperlight is extremely fast. Microsoft showed off this speed in a demo at KubeCon North America in November, a Rust-based web server executing multiple functions on micro VMs, spinning up new micro VMs or reusing warm ones as available to serve requests. In microsecond response times, the demo delivered a basic Hello World web page.

Second, while Hyperlight is a Rust library, it can host guest applications written in other programming languages. Microsoft showed off this capability with a demo application last month, a basic JavaScript interpreter written in C.

These two demonstrations show two key requirements for a serverless computing host. First, Hyperlight can deliver responses to requests extremely quickly from both warm and cold hosts, showing that you could launch a new micro VM and get a result remarkably quickly. Second, Hyperlight can host multiple programming environments on top of its Rust-based APIs.

Even tiny VMs need guests

It’s important to remember that Hyperlight Wasm is a virtual machine host. You will need to write the code necessary to load Hyperlight’s guest applications and run the Hyperlight VM. That heavy lifting may be fine for hyperscale cloud providers looking to keep on top of their resource requirements, but most of us will need to wait for new frameworks before we build Hyperlight into our own applications.

Then there’s the issue of building the guest applications themselves. Compatibility remains an issue, as Hyperlight doesn’t expose all the functions that we expect from an operating system. All Hyperlight offers is a virtual CPU, some memory, and a basic API. That’s one reason why using WASI (WebAssembly System Interface) via the open-source Wasmtime runtime makes sense, as it will handle the necessary abstractions. If we were using a specific language, say C or C++, we’d need a new version of its standard libraries, customized for Hyperlight but with a limited set of functionalities.

Working with WASI has the advantage of being able to target it from any supported language and any WebAssembly-ready development environment. Working with C directly requires knowing what APIs are available. With WASI on Hyperlight, you don’t have to know what you’re targeting. All that’s needed is support for the wasm32-wasip2 target.

Why WebAssembly?

Another benefit of WebAssembly is that you don’t need a running Hyperlight environment to develop and test your code. All you need is a local runtime or even a WASI-ready environment such as Spin or wasmCloud. This makes it a lot easier to build code that will run on Hyperlight and to use Hyperlight to host code as part of a wider WebAssembly platform. It’s possible to see Hyperlight as another alternative to the Krustlet approach that’s being retired from Azure Kubernetes Service, especially for applications that take an event-driven approach to scaling rather than a resource-based one.

WebAssembly support significantly expands the range of supported languages for Hyperlight, ensuring that compiled languages as well as interpreted ones like JavaScript can be run on a micro VM. Your image does get more complex here, as you need to bundle an additional runtime in the Hyperlight image, along with writing code that loads both runtime and application as part of the launch process. Microsoft has demonstrated the StarlingMonkey WebAssembly-based JavaScript interpreter on Hyperlight, which should make it easier to deliver an Azure Functions-like service.

Building the right tools to manage and run Hyperlight micro VMs is going to be key to using it in production. For now, it remains experimental, but it’s clear the Azure team is very interested. That makes sense. Having a micro VM that performs well with minimal CPU and memory requirements and that has very fast cold-start performance can help reduce capital expenditure by getting better performance from existing hardware at higher densities.

Having a basic set of APIs that support a Wasm runtime and very little else provides a much more secure environment for your code. The small amount of memory the micro VM uses is isolated from other applications, and since only the code you provide can run, it’s much harder for an intruder to subvert your application. WebAssembly provides its own sandbox, giving you not one, but two layers between your code and the host OS.

Like earlier Hyperlight builds, Hyperlight Wasm is being developed in public on GitHub, with an Apache 2.0 license. Its repository contains everything you need to experiment, including sample Wasm modules and a host application.

Getting started with Hyperlight Wasm

Getting started is simple enough. You need a handful of prerequisites, including Rust, the Just command runner, and the GitHub CLI. Windows users will need Git and PowerShell. If you’re installing Just for the first time, the developers recommend installing it via Cargo, as other tools may install older, incompatible versions. Both Windows and Linux need to have virtualization enabled, and if you’re using a cloud-hosted VM, make sure it has support for nested virtualization.

Hyperlight Wasm will need Version 1.82.0 of the Rust toolchain. When you have that installed, you can build the rest using the provided just build script.

Once you’ve built the Hyperlight Wasm implementation, you can experiment with hosting applications. There are three APIs for working with sandboxed code managed by a SandboxBuilder. The first, ProtoWasmSandbox, is where you set up the host functions that can be used by your Wasm code. This then transitions to a WasmSandbox, loading and initializing Wasmtime. Once you’ve loaded your own code, the service makes its final transition to a LoadedWasmSandbox.

Your management code can now call your Wasm code, running a function. Usefully you can transition back to a WasmSandbox if you want to unload your code and reuse the sandbox with a different Wasm module.

The host functions provided to your code are described as WebAssembly Interface Types and compiled to a binary Wasm. Starting with a SandboxBuilder, you define the resources needed to run your code including buffers, heaps, and stacks. At the same time, the code used to create the Hyperlight sandbox registers any necessary bindings and sets up the host functions your code needs.

Your Wasm code needs to be compiled before it’s loaded into a Hyperlight sandbox. Hyperlight avoids generating code at runtime to ensure your code loads as quickly as possible. Microsoft is planning to simplify things by shipping a set of default WASI interfaces in Hyperlight Wasm, allowing basic network services to run without needing work on your part. This should allow Hyperlight Wasm to host basic event-driven services by quickly standing up code that’s ready to listen to specific sockets, process data, and then send it on via TCP or UDP.

The future of serverless

There’s a lot of work going on in the WebAssembly community to define a specification for a component model. This is intended to be a way to share binaries and libraries, allowing code to interoperate easily. The Hyperlight Wasm tool offers the option of compiling a development branch with support for WebAssembly Components, though it’s not quite ready for prime time. In practice, this will likely be the basis for any final build of the platform, as the specification is being driven by the main WebAssembly platforms.

One point that Microsoft makes is that Wasm isn’t only language-independent, it’s architecture-independent, working against a minimal virtual machine. So, code written and developed on an x64 architecture system will run on Arm64 and vice versa, ensuring portability and allowing service providers to move applications to any spare capacity, no matter the host virtual machine.

Microsoft is driving toward a serverless future for Azure, and tools like Hyperlight will become a key component of its infrastructure. Support for WebAssembly rapidly increases Hyperlight’s utility, and as this functionality develops, it’s likely to become the focus. For now, Hyperlight and Hyperlight Wasm are very much in development, and we can expect features to change as the platform evolves. Once it’s stable, we should then see the development of much-needed management tools that will provide the necessary user experience for deploying and managing code.