Wasm-based Spin 1.0 released to address ‘limitations of serverless’

Wasm-based Spin 1.0 released to address ‘limitations of serverless’

Fermyon has released Spin 1.0, the first stable version of its open source tool for compiling applications to WebAssembly for serverless deployment. Developers can code in languages including Rust, TypeScript, Python, Go and C#, and deploy to the platform of their choice including Fermyon’s cloud, AWS, Azure, GCP (Google Cloud Platform), or other destinations such as Kubernetes.

Spin is an effort to exploit the efficiency and fast startup of Wasm code, which is also sandboxed for isolation from other code. “Wasm has the runtime characteristics that can address the limitations of serverless,” according to Radu Matei, co-founder and CTO of Fermyon. These limitations, he wrote, include vendor lock-in, lack of portability, and cold starts – with the last of these the most compelling argument for Wasm. A cold start is the delay when an serverless application receives the first request after a period of dormancy. This can be a particularly awkward problem for applications which depend on a runtime, like Java or .NET.

“The startup time for a Wasm module can go from less than one millisecond to a few milliseconds,” wrote Matei.

This is just as well, since the way Spin works is that a new instance is created for every request. This means that Spin modules are inherently stateless, though persistent state is achieved by connecting to databases or using a built-in SQLite database to store and retrieve key-value pairs.

The core commands for working with Spin have a pleasing simplicity. Spin build for building an application, spin up for running it, and spin deploy for deploying it. Spin can also deploy to container registries such as Docker Hub or GitHub Container registry.

Although in principle Spin supports any language that can compile to WASI (WebAssembly System Interface), designed for running WebAssembly outside the browser, the detail of language support shows limitations. The best supported language is Rust, with other languages having only partial support for all the features of Spin – with missing features in some cases including the SQLite support and driver for MySQL. Mattei lists “feature parity for language SDKs” as a goal for “upcoming minor versions of Spin.” A kitchensink repository has examples for C#, F#, Go, Python, Rust and Zig.

Another future plan is to transition to the Wasm component model, which will include a standard ABI (Application Binary Interface) so that Wasm modules can support dynamic linking, making code reuse easier. Upcoming WASI networking support will enable support for more database drivers.

Although Spin 1.0 is released, the various limitations and the general state of the WASI ecosystem (for example, Azure Kubernetes support for Wasm workloads is in preview) raise questions over whether it is really ready for production – though the efficiency and developer-friendliness of the tool is impressive.