Server-Side Wasm - Q&A with Michael Yuan, Second State CEO

The contemporary rise in the usage of WebAssembly to fulfill server-side use cases appears driven by its security model, portability, and performance. WebAssembly strives to extend the gamut of its abilities through a range of proposals that eventually become part of the specifications. Those proposals must be implemented in Wasm runtimes so developers can enjoy the provided capabilities. 

Second State recently implemented the reference types proposal and bulk memory operations proposal in its SSVM WebAssembly runtime. InfoQ interviewed Michael Yuan, CEO of Second State, on the current use cases of server-side WebAssembly and how Wasm runtimes may support those use cases.

InfoQ: Can you tell us about you? How did you get interested in Wasm?

Michael Yuan: I was involved in enterprise open source software since the early 2000s. Back in 2005, I was among the first “Java Champions” recognized by Sun, and I published several books on enterprise Java. In the past 20 years, we have observed browser technologies migrating to the server as developers keep looking for “simpler” solutions—Java made the migration 20 years ago and JavaScript made the migration 10 years ago. I feel that WebAssembly is driving another wave of migration led by young developers. This time around, I believe WebAssembly has the potential to replace the JVM, V8, and even Docker or microVMs in many server-side applications.

InfoQ: You mentioned in the past that Second State is committed to the vision of secured computing supported by WebAssembly nanoprocesses. What is that vision in layman’s terms? How important is it for the server-side Wasm use cases of today—and tomorrow?

Yuan: In layman’s terms, WebAssembly supports managed code without sacrificing performance. Let’s use the example of “serverless functions”—today’s cloud providers typically use microVMs (e.g., AWS firecracker) or application containers (e.g., Docker) to provide secure execution sandboxes. However, to start an entire OS just to execute a function is very wasteful. As a result, serverless adoption is impeded by issues like cold start time.

WebAssembly aims to provide a high-level VM, but still provide access to the underlying operating system in a very controlled and secure manner. You can read about it in a peer-reviewed paper we recently published on IEEE Software. (Preprint)

In terms of applications, we believe high-performance serverless functions can replace many of today’s web and microservices. To see an example in action, try our TensorFlow as a service demo. The tensorflow function runs inside WebAssembly (SSVM). It recognizes objects, birds, plants, insects, and even food in your picture. It goes directly from a static html page to the serverless function. No servers to manage!

InfoQ: Lin Clark, Bytecode Alliance, mentioned that three pieces were prerequisites toward implementing this vision: WASI, interface types, and module linking. WASI defines standard interfaces for Wasm programs to interact with the program’s host environment (e.g., I/O operations). Module linking allows Wasm modules to interact with one another. Interface types provide a translation between types used in a variety of source languages, runtimes, or host architectures—enabling smoother data passing between interacting parties. Second State had already implemented the current iteration of WASI and recently implemented reference types. How do reference types relate to interface types and what scenarios do reference types already allow? What scenarios are going to require (or are made easier with) interface types?

Yuan: Since WebAssembly is a high-level VM, it typically interacts with other applications on the OS (in contrast, Docker starts its own OS and is hence less efficient). Yet WebAssembly is a very lightweight spec—it lacks many basic data types. For example, WebAssembly doesn’t even natively support strings. That’s why WebAssembly hello world examples are always about arithmetics—they never just print the “hello world” string.

Today, when WebAssembly communicates with JavaScript and C programs, it does so by manually managing chunks of memory to simulate things like strings. That does work but isn’t standard.

• Interface types define additional “complex” types missing in the wasm spec, such as the string type.
• Reference types define how wasm applications exchange typed data with external applications.

Those two specs standardize how other applications could embed WebAssembly, and how WebAssembly could call out to other apps. It is very important in making WebAssembly into a “Lego piece” of the larger ecosystem. 

InfoQ: The WASI standardization effort is reminiscent of server-side Java specifications efforts (J2EE). J2EE strove to address such needs as micro-services, distributed computing, and scalability. How does server-side Wasm compare to J2EE and alternatives?

Yuan: There are several key differences between WebAssembly and Java:

• WebAssembly is much lighter and simpler. With Java, you must “eat the elephant” just to get started. In WebAssembly, the dev cost to get started with a function as a service or a browser app is much smaller. 
• WebAssembly is optimized for performance and has no heavyweight runtime components like a garbage collector.
• WebAssembly aims to be language agnostic. It is downstream from LLVM, which supports over 20 languages.
• WebAssembly is easier to adopt, modify, and embed. That’s why you see it is used everywhere from blockchain to serverless. 

Of course, Java has a far more advanced enterprise ecosystem than WebAssembly. WebAssembly is still early in its migration from browser to server, which is the journey Java itself completed 20 years ago and JavaScript/Nodejs completed 10 years ago. 

InfoQ: There currently exist a few Wasm runtimes, with different areas of focus. Excepting browser runtimes, the server-side oriented Wasm runtimes may be insisting on performance, size, memory usage, startup time, easier interoperability for specific host languages or embedded systems, and more. What is the focus of Second State? What use cases does Second State specialize in?

Yuan: SSVM is among the fastest WebAssembly VMs today. For comparisons, we have a Github repo where we have updated open-source benchmarks comparing SSVM against other Wasm runtimes. The “node” column refers to the Google V8 WASM engine.

Of course, this still isn’t a complete comparison as many projects, especially blockchain projects, have their own Wasm implementations. However, I think we covered the mainstream ones. Most Wasm implementations out there are just interpreters, which are very, very slow. V8 and wasmtime grew from browser use cases, and they support JIT optimizations, which is much faster than interpreters. SSVM is designed for the server and hence uses AOT optimizations, which are faster than JIT optimizations.

SSVM leverages its performance to implement highly useful but non-standard extensions such as Ewasm and WASI-tensorflow. SSVM thus covers blockchains and machine learning use cases.

InfoQ: Portability is at the core of Wasm’s goal and design. Wasm programs should run on the web and off the web, and on a variety of operating systems and instruction set architectures. Importantly, Wasm programs should be portable across Wasm runtimes. Kevin Hoffmann however warned that while Wasm is portable today, it can only remain so as a result of a conscious community effort. J2EE is a cautionary tale in that matter—vendor runtimes with extra features could result in Java code that wasn’t portable across J2EE runtimes. Are there Wasm programs that only run on Second State runtime? How do you balance Wasm portability objectives with the urge to answer the use cases of today today?

Yuan: I was heavily involved in the J2EE standardization effort back in the early 2000s. I think a key lesson we learned is that standardization can’t happen in a vacuum. To get a committee of PhDs inventing the perfect standard in a hotel, you get debacles like the EJB 2.0. Standards must emerge from non-standard real-world applications—like Hibernate becoming EJB 3 all these years ago. 

I believe WebAssembly needs to have many non-standard extensions for real-world applications, and then we can standardize. That said, it is critical to have standardization organizations actively monitoring and working on community innovations. 

In terms of SSVM, yes we do provide several non-standard extensions that we hope to standardize through the community. Examples:

• The Ethereum flavor WebAssembly (Ewasm) is a semi-standard created by the Ethereum foundation to support WebAssembly on blockchains. The SSVM is the world’s most complete Ewasm implementation and is already used in leading blockchain projects.
• The SSVM tensorflow extension is a WASI-like extension to run TensorFlow models from WebAssembly. It takes advantage of full native features of the OS including the GPU and AI chips in executing TensorFlow—and hence achieves performance orders of magnitudes faster than standard wasm libraries like tensorflow.js. The use case here is edge AI services. 

About the Author

Dr. Michael Yuan is founder at Second State. He lives in Austin, Texas. Second State focuses on high performance and secure software runtimes for AI, blockchain, and data applications. The Second State VM (SSVM) is one of the fastest WebAssembly engines on the market and powers the Second State serverless functions. Dr. Michael Yuan has been developing open source software for over 15 years and wrote 5 books about it.