WebAssembly - Where is it going? - Moment For Technology

“WebAssembly is a safe, portable, Low-level code format Designed for efficient Execution and compact representation” — W3C

This article introduces WASM and WASI application scenarios, where some exploratory projects are already under way, with implications for future application architecture and distribution patterns. Translated from WebAssembly — Where is It Going? “By MATEUS PIMENTA.

WASI from WASM

When WebAssembly (Wasm) was supported by major browsers in 2017, it represented the formation of a faster (near-native) technical standard for running computer programs in browsers.

However, when Mozilla released the WebAssembly System Interface (WASI) in 2019, it was a revolutionary moment. WASI has lifted the browser-only restrictions on WASM and expanded it to be a standalone virtual runtime environment that can run on a host. This represents the birth of a whole new technology for coding, packaging, and running computer applications.

WASM running in a browser

After WASM was supported by major browsers (Microsoft Edge, Safari, Google Chrome and Firefox) in 2017, the W3C drafted a WASM standard and soon entered recommendation status, It will be released in 2019. This means that developers can run heavily loaded applications in the browser at “close to native application performance” without JavaScript engine performance constraints or cross-browser adaptation issues.

With WASM in the browser, developers can continue to develop traditional page applications using JavaScript, while offloading heavy functionality into WASM-coded applications that interact with the WebAssembly JS API.

The game

Games were the initial target scenario for WASM, and when some game engine companies supported WASM, such as Unreal Game Engine announced support for WASM, the technical direction of WASM was driven. Of course, WASM isn’t just used in game scenarios, it’s used in image processing, video processing, and audio processing studios, where work can currently only be done on a desktop or server.

Artificial intelligence model reasoning

Model reasoning by ARTIFICIAL intelligence is also a typical scenario for WASM. Side-to-side applications decoupage themselves from the server and load complex models, such as face recognition and speech-to-text, directly to perform reasoning on the side. All the complex logic runs in Native Code without JavaScript.

The Tensorflow.js project provides a WASM application for this scenario. Tensorflow.js can also use multithreading and Single Instruction Multiple Data (SIMD) techniques to speed up calculations. If WASM’s Threading and SIMD specifications are released, new projects will follow to engineer these technologies.

Two important changes

The technique of performing overloaded computations in the browser brings about two significant changes.

Software companies will develop more Web client applications. Compared with software packages installed on the client’s machine, this delivery mode simplifies maintenance work such as application upgrades and security patches. This change will further strengthen the SaaS business model.
Running overloaded computing on the Client side, compared with client-server mode, eliminates runtime interaction between the Client and Server side, improves user experience, and reduces network and computing costs for software manufacturers.

WASM beyond the browser

Currently, WASM can only run Native Code in the browser sandbox. However, the WASI specification defines the interface specification for WASM sandboxes to interact with files, networks, and so on of the host system. This capability allows us to run generic applications in the WASM sandbox and gain portability, security, and other features introduced by WebAssembly. There are profound connotations hidden inside this, and we interpret them one by one.

Containers and container choreography

Docker founder Solomon Hykes made a statement saying that if WASM and WASI had emerged a few years earlier, Docker would not be a problem. Of course, this does not immediately mean that all current Docker runtime loads should be replaced with WebAssembly, but it does suggest that WebAssembly can remedy some of the shortcomings of the current Docker container.

Meanwhile, mainstream container-managed products (AWS ECS, AWS Lambda (Now with Containers!) , Google Cloud Run, Azure Containers Instances), all started to research WebAssembly as a technology to replace traditional Containers. Further, Microsoft’s Deis Labs already has a Krustlet project that orchestrates WebAssemblies in K8S.

WebAssembly has several advantages over traditional Docker Containers.

Security. Application processes can directly access the host kernel, even though The current Container has many security protection measures. Container is a lightweight virtualization technology implemented through the CGroup, rather than complete kernel virtualization. Although the Security context mechanism exists, the attack surface is still large. At present, there is also a trend to use full kernel virtualization, including gVisor, Firecracker(AWS Lambda, AWS Farget products all use this virtualization technology), Kata. This suggests that safety is an important consideration. WebAssembly’s security model is a full sandbox, which indicates controllable system calls, memory security, and less attack surface.
Package size. Container image package size has always been a sore point, resulting in a number of technical points and best practices for reducing image package size. This is because, mechanically, container mirroring requires that all application-dependent lib libraries outside the inner kernel be packaged into the image for portability. The WebAssembly deliverables contain only the application itself (with a 15 percent compression in practice). The reduced package size enables shorter startup times for applications, such as “cold startup” times in function calculations. Fastly’s Lucent plus AOT technology, cold startup time is about 50 microseconds; Cloudflare uses a V8 engine and has a cold startup time of 5 milliseconds. This is a very important experience enhancement for the Serverless computing scenario.

Edge of computing

Cloud vendor Edge computing services have been available for several years. AWS Lambda@Edge and Cloudflare Workers both run user code based on JavaScript engines, and Now WebAssembly offers a new option.

Based on the advantages of WebAssembly discussed earlier, a new distributed computing application architecture is emerging in combination with the POINT-of-presence (PoP) of CND vendors. The application of this pattern not only improves the user experience, but also provides significant resilience and reduces network and computing load in the data center.

So far, there are vendors offering Edge computing services based on WebAssembly.

Fastly Compute@Edge, a pure WebAssembly-based edge computing solution.
Cloudflare Workers, adding WebAssembly support to existing edge computing platforms.

Embedded, IoT, mobile applications, machine learning, etc

WASM is being adopted in more areas. You can integrate WASM into applications that allow users to upload code, such as rules engines, and use WebAssembly to evaluate the security of rule code. Wasmer is probably the best WASM runtime available today.

There are also WASM runtimes in the IoT space, such as WASM-Micro-Runtime and WASM3, that reduce the complexity of moving code across devices. Wasm3 also supports Android and iOS devices.

Intel engineers are working on WASI-NN, which is intended to make it easier for machine learning code to flow across different architectures.

The current stage

WASM in the browser domain application related technology has been basically mature. The WASI specification is also evolving steadily, with several modules implemented and new features iterated. In the language space, there are already a number of languages that support compilation to WebAssembly bytecode and they are becoming more mature.

Outside of browsers, with the exception of edge computing, WASM is still in its early stages and is not an immediate replacement for Containers. The first form is hybrid orchestration, which orchestrates Containers and WASM for different business scenarios.

The WASI standard is in the second of four phases, and the WebAssembly/WASI performance proposal is also under consideration.

There are also ecological considerations to consider, as byte Alliance, recently launched by four WebAssembly Sponsors, is working on the ecology of WASM and WASI.

Give it a try

webassembly.studio

wasm.fastlylabs.com

Reference

WebAssembly-Wiki

WebAssembly

WebAssembly — Where is it going?

Pay attention to the public account for more cloud best practices