Getty Images

Server-side Wasm boosts K8s bonds, devx ahead of key update

Early adopters await a WASI update this year before server-side Wasm can be ready for wider production use. For now, PaaS vendors have begun to bridge some of the gaps.

It will be a few more months before important updates to WebAssembly standards reach stability. In the meantime, newcomers to the PaaS market have added fresh enticements to enterprise adoption.

Server-side Wasm is a relatively new field of development for what originally began as a web browser utility. Proponents believe that using Wasm to run server-based workloads could replace containers as a more efficient mechanism for making workloads portable from cloud data centers to small edge devices.

As of six months ago, most Wasm experts admitted that the technology remained an early work-in-progress. Many remain eager to see a group of proposed updates to the W3C WebAssembly System Interface (WASI) standard, called wasi-cloud, reach a stable release later this year. That update is expected to make it easier to mix applications written in different programming languages on Wasm platforms -- a significant step toward readiness for enterprise production use.

Over the last two months, meanwhile, vendors' Wasm integrations have begun to hit milestones of their own. Red Hat indicated on Feb. 1 that Wasm can run on its MicroShift edge Kubernetes project. On March 22, Docker released the second technical preview of its Runwasi project that supports Wasm in Docker containers on Kubernetes. Wasm PaaS startup Fermyon launched the first stable release of its Spin project for serverless WebAssembly the same day.

Finally, this week at KubeCon + CloudNativeCon Europe, Wasm specialists -- including Cosmonic and Fermyon -- issued fresh integrations for Wasm on cloud-native infrastructure in the form of a Kubernetes connector and key-value storage, respectively.

It all adds up to incremental but necessary steps forward for server-side Wasm, said Torsten Volk, an analyst at Enterprise Management Associates.

"They're basically figuring out how to eliminate one roadblock [after] the next for developers, to help more [of them use Wasm] instead of dumping stuff into containers," Volk said. "There are so many pain points for developers on Kubernetes that they have an incentive to try this out."

Cosmonic builds Kubernetes on-ramp to Wasm

Whether it's a love-hate relationship or not, most developers still likely have a relationship with Kubernetes. That's why the first Cosmonic Connect module for Cosmonic's WasmCloud PaaS -- in public beta as of this week -- sets up a link between Wasm and Kubernetes, said Taylor Thomas, director at Cosmonic.

"Kubernetes was an obvious target just because of its popularity," he said. "Even if [an organization] is very forward-looking, they're not going to have the time nor the desire to move everything off of Kubernetes right now. … It basically introduces an easy path to the Strangler pattern."

There are so many pain points for developers on Kubernetes that they have an incentive to try this out.
Torsten VolkAnalyst, Enterprise Management Associates

Ultimately, some applications will remain on containers and Kubernetes, and it's also important to manage both together, Taylor said. Cosmonic Connect Kubernetes adds Kubernetes pods inside WasmCloud that allow containerized apps to connect with Wasm apps via the platform's NATS centralized messaging framework.

Cosmonic also invoked a Kubernetes-style declarative pattern for deploying apps on WasmCloud with a second project unveiled this week named Wadm, based on the CNCF's Open Application Model, he said.

For the kind of extremely early adopters already working with Wasm, Cosmonic Connect Kubernetes and Wadm aren't necessary but will be nice to have, according to Sean Isom, senior engineering manager at Adobe.

"These are things that you could have configured manually, but it would have been very difficult to do," Isom said. "Cosmonic Connect allows you to access Kubernetes resources through the Cosmonic PaaS but also makes it easier to set it up with Kubernetes as well."

This kind of platform flexibility is in keeping with PaaS offerings that have emerged in the Kubernetes era, post-Cloud Foundry, which have taken a less-opinionated and highly abstracted approach to the underlying infrastructure, Volk said.

"That's what didn't work in Cloud Foundry," he said. "Nobody liked that part because you were so restricted."

Fermyon focuses on FaaS, devx

Still, some segments of developers prefer to do minimal infrastructure management using serverless platforms. This is where Fermyon's Spin PaaS has focused on a smooth developer experience and emphasized support for Wasm in multiple programming languages, including Python and TypeScript. Outside of Fermyon, programming language support for Wasm has so far been essentially limited to Rust.

"The C++ ecosystem has very robust support [for Wasm] and they kind of started there, but Rust is the de facto standard for Wasm at this point," said Ricardo Torres, associate technical fellow and chief engineer of open source and cloud native at Boeing. "Fermyon seems to have really tried to emphasize additional languages -- for example, it has an SDK for TypeScript, which is pretty huge for the ecosystem."

This week, Fermyon also added a thin layer of infrastructure in the form of ephemeral key-value storage for developers to use for session data. But generally, Fermyon represents the second of two early approaches to server-side Wasm. Where Cosmonic operates similarly to a traditional PaaS, Fermyon has more in common with function as a service (FaaS) tools such as AWS Lambda.

As with PaaS and FaaS, these two models will likely persist as equally valid alternatives while server-side Wasm advances, Isom said.

"The team I represent within Adobe is a platform service provider, so Kubernetes is part of our value-add," he said. "But I can see a world where both WasmCloud and Fermyon coexist."

A schematic diagram of the WASI component model for server-side Wasm.
Early adopters believe the WASI component model, expected to hit stability milestones later this year, will be key to enterprise server-side Wasm adoption.

IT pros await WASI preview 2

Boeing won't be an early adopter of server-side Wasm, but Torres said he sees potential in the technology as a speedier means of spinning up functions from a cold start and to be more efficient than Kubernetes for edge and IoT devices.

Still, while server-side Wasm hype has been building, it has yet to reach a breakthrough, in Torres' view.

"I feel like Wasm is still waiting for its killer app -- its Kubernetes moment," he said.

Such a moment -- or at least a major steppingstone to it -- could come with WASI preview 2, due out later this year, according to Bailey Hayes, a director at Cosmonic and director of the Technical Standards Committee at ByteCode Alliance, which governs WASI.

WASI maintainers expect to reach stability milestones in preview 2 for wasi-cloud, which is a collection of WASI proposals that provide standardized plugin interfaces, or components, for running cloud-native apps on Wasm. Components are a lighter-weight, more portable alternative to the existing WASI modules, which include cumbersome dependencies, Bailey said during a presentation at the Wasm I/O 2023 conference in March.

The component model will significantly broaden the applications that can work with Wasm by supporting a mix of programming languages in the same infrastructure platform, Isom said.

"This continues to be the challenge, as well as an opportunity, for me with Wasm -- being able to build more complex, more robust systems," he said. "Once they get this developer experience sorted out, so that large companies like us can write a service that runs natively in WebAssembly, either on the edge or on the back end, I think we're on the cusp of being able to do great things with it."

Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.

Dig Deeper on Systems automation and orchestration