WebAssembly Gets Polyglot Development Boost in Spin 3.0
The release of Spin 3.0 demonstrates what developers and platform engineers can now achieve. Beyond WebAssembly’s long-touted benefits of providing lightweight modules for deployment and ultra-low-latency cold start times, Spin 3.0 expands the possibilities for those working with WebAssembly by allowing users to benefit firsthand from WebAssembly’s polyglot capabilities. Its expanding use has resulted in over 5,625 GitHub stars and 230,000 clones and downloads.
In this way, Spin 3.0 fulfills one of WebAssembly’s core promises: enabling developers to use their preferred programming languages while ensuring seamless integration. For instance, a Rust developer can write Rust code, distribute it as a module and deploy it in a JavaScript application. Furthermore, if developers prefer not to create their own modules, they can access a variety of pre-built libraries available in the Open Container Initiative (OCI) registry for module creation and deployment.
The component model has long been described as a way to add a Rust, Go or another library and “it won’t matter one iota to the user,” Fermyon CEO and co-founder Matt Butcher explained. “It appears the same as any other library they would use. Spin 3 — we’ve been talking about being able to do that for a while, and it’s been inherent in the component model for about a year now,” Butcher said. “But to actually do it in practice has been this sort of tedious process of running tools and saying, ‘OK, you’re gonna connect to this thing,’ just because the tooling hadn’t arrived yet …So finally, that polyglot experience has also become a real thing that is easy for developers to do.”
Much depends on the finalization of a component model and especially its relationship to WASI, which is the standard interface or API linking the WebAssembly modules to the components. It will support the development of so-called WebAssembly “Worlds,” as groups of compatible Wasm components form an interconnected infrastructure similar to Kubernetes, but without containers. WASI Preview 2, released in 2024, made some huge strides toward standardization, but we are not there yet. In 2025, we will likely not achieve the Holy Grail, but we could see some pleasant surprises. Again, improved WASI and component standards means more languages that can be used with WebAssembly beyond the current stable of Rust, Go and C++.
Spin 3.0’s reliance on the component model also supports AI model development and training.
“Do we really want to write the same AI code in nine different languages again? Or can we just say, ‘Hey, all these Go libraries and Rust libraries, we can call them from TypeScript, and this library over here, we can use it with Python’ and it’s going to be a very exciting time,” Butcher said. “I think this has been the first time in a while where we’ve opened up a kind of vision of the potential of the component model in actually making developers’ and platform engineers’ lives easier.”
More Stuff
Spin 3.0 enables developers and platform engineers to easily get started with deploying and managing applications using WebAssembly modules. A key feature is its use of the newly completed WebAssembly interface types (WIT), which allow components to interoperate regardless of the programming language used to create them. This interoperability underscores the compatibility and modularity of WebAssembly, akin to microservices.
Significant progress has also been made in supporting the WASI API standard, including the WASI Key-Value and WASI Config APIs, both now supported by Spin. This effort is part of a broader open source collaboration to bring WASI Cloud to fruition. WASI Cloud is a proposal to standardize APIs that enable applications to interact with a unified set of cloud services through Spin.
In addition, Spin 3.0 integrates with observability tools, such as OpenTelemetry, to provide better insights into WebAssembly applications. This ensures that developers have robust monitoring and diagnostic capabilities as they deploy and manage their applications.
With the integration of OpenTelemetry, it is easier to choose and implement the observability platform of your choice for Spin application observability. Previously, it was possible to use tools like Jaeger or Prometheus for Kubernetes deployments with Spin to view metrics, but it required more effort. Now, with OpenTelemetry integration, the process is significantly more practical and streamlined.
Spin 3.0 has also become easier to learn, set up and use. Whether you’re working on a one-off project or a more complex deployment, the platform accommodates various use cases. To that end, Fermyon has introduced Spin factors, with each factor offering a specific set of functionalities. These features are designed to facilitate deployments in different environments, making Spin more modular and adaptable.
Additionally, when you fork the project for your own use, these factors simplify the process, enabling you to achieve your deployment goals more efficiently. Spin factors make the platform even more accessible for developers, whether they’re experimenting or implementing production-grade solutions.
Adopt a Spin
Meanwhile, Spin — or SpinKube, for Kubernetes — and WebAssembly support should see more availability. Already, Docker, Microsoft, F5 and NGINX, SUSE and others rely on Spin at least to some extent for internal use and in the products they offer.
Speaking about WebAssembly in general, Shobhan Lakkapragada, a Red Hat senior director of product management, during a pre-briefing ahead of KubeCon+CloudNativeCon North America in November in response to my question, said WebAssembly is a layer above OpenShift. It remains a new emerging technology for building web applications that Red Hat does not yet directly support. Adoption remains in the “very early stage,” he said.
The ability to run WebAssembly workloads on OpenShift is enabled by updating the configuration of CRI-O on the OpenShift worker nodes to use the crun-wasm runtime Podman, Kirsten Newcomer, senior director, hybrid cloud platforms, for Red Hat, told me. OpenShift customers will be able to use standard container tooling (registries, engines, runtimes) including tooling that works with OpenShift and Podman by implementing support in CRI-O, she said.
CRI-O already supports wasmedge today, but “we will be able to swap that out in future” if a different WASI runtime (such as wasmtime or wasmer) becomes more dominant, Newcomer said. “Note that we run the Wasm runtime in a container just as we do our other runtimes. This provides an additional security layer with the same protections that OpenShift provides for all containers, including SELinux, cgroups and network namespaces,” she said. “Podman also enables you to build Wasm OCI images.” This capability is available as a developer preview as of OpenShift 4.14.
Heather Joslyn contributed to this article.
