WebAssembly is arguably beginning to live up to its hype. Although whether it realizes its potential or not remains to be seen and its ultimate success largely depends on factors beyond its worth as a technology. Things that could hold it back include a lack of agreement about standardization devices on which it is deployed.
WebAssembly is expected to eventually see wide-scale use as a way to deploy applications in a single module across different containers and Kubernetes clusters, devices (such as for edge and IoT devices) and multicloud environments simultaneously.
Other things that WebAssembly offers, given its low computing instruction-set size, are its ultrafast speeds and its security aspect — or its sandbox design to use industry jargon — since there is no access by other services or applications during deployments as the code inside remains isolated and is not accessible during its lightning fast journey measured in milliseconds for deployment across different environments.
WebAssembly is very suitable for serverless environments and is seen as a way to overcome many of serverless’ issues impeding its adoption. Today’s typical third-party use cases mean that serverless will require the support of a third party, which is more often than not a cloud vendor. For many, serverless architecture might be equated with Lambda on Amazon Web Services or an offering from another cloud vendor such as Azure, Google Cloud, Oracle or IBM. The organization thus must be content to entrust its several infrastructures not with multiple vendors, but with one third-party cloud provider, to administer its critical apps in many cases. For this reason alone, the avoidance of vendor lock-in is a key Wasm selling point.
“One of the things that we at Fermyon hear all the time is that developers love the serverless functions paradigm,” Matt Butcher, co-founder and CEO of Fermyon Technologies, said. “That statement almost always comes with a ‘but,’ though: While the big clouds each provide serverless, developers dislike the vendor lock-in, performance, and developer experience accompanying those offerings.”
Indeed, WebAssembly has the potential to become the new standard for composing apps, consisting of “truly universal building blocks” that can be combined and molded into many different apps, Torsten Volk, an analyst for Enterprise Management Associates (EMA), said. For the developer, this is accomplished “without worrying about getting it to work within these apps’ runtimes. This opens the door for a massive jump in developer productivity, as developers could pick and choose from a library of boilerplate modules that could even be available as part of the runtime,” Volk said. “They could consist of microservices for identity management, access control, app messaging, data storage, and data mining or they could be entire data pipelines, machine learning models, or API integrations. This prospect of developers becoming laser-focused on writing business code, and business code only, is what makes Wasm so exciting.”
However, again, WebAssembly, as it stands now, remains a work in progress. Among other things, it is in the wait of the standardization of component interface Wasi, the layer required to ensure endpoint compatibility among the different devices and servers on which Wasm applications are deployed.
The idea is that WebAssembly is designed to deploy applications written in the language of the developer’s choice for deployment anywhere simultaneously in disparate and various environments. “Disparate” since WebAssembly runs on a CPU and only requires a device, server, etc., to be able to run a CPU instruction set. This means that a single deployment of an application in a WebAssembly module theoretically should be able to run and be updated on a multitude of different disparate devices whether that might be for servers, edge devices, multiclouds, serverless environments, etc.
The argument that WebAssembly will replace containers and Kubernetes is largely a non sequitur. This is because WebAssembly and containers and Kubernetes are different, yet important technologies. And even though there are some overlapping purposes, they also meet specific and separate computing needs.
At least in the immediate future, many organizations will be loath to replace their container infrastructure and Kubernetes environments. Besides likely losing their investments in those by replacing them with WebAssembly, WebAssembly is not a replace-all technology for all containerized environments. In fact, there is much attention paid these days to use Wasm to deploy applications on containers and in Kubernetes environments.
Docker continues to make announcements about how it will accommodate and extend support for WebAssembly. How both will work together and especially how Docker is used with containers to allow for them to deploy and manage applications with WebAssembly were often discussed. These adaptations are largely seen as necessary to pave the way for Wasm’s adoption and use with containers and Kubernetes.
“With supersonic startup speed and light runtime requirements, Wasm is well suited for serverless functions – something that has historically been hard to implement well in Docker. Conversely, Docker’s standout feature is its ability to easily bundle up a long-running server and its environment in a portable fashion,” Butcher said. “Long-running servers are not yet Wasm’s strong suit. Now that Wasm can be packaged in the same image format as a container, we’ll see the two technologies combined to build the kind of hybrid serverless-and-server microservice apps that have been difficult to achieve with prior technologies.”
Indeed, Wasm offers security advantages on a number of fronts. This is because, as Sounil Yu, chief information security officer at JupiterOne, a provider of cyber asset management and governance solutions, communicated:
Wasm code offers a bit of security through obscurity by not being human-readable, making it harder for attackers to reverse-engineer the code and thus more difficult to discover and exploit vulnerabilities.
Wasm can also be run in a sandboxed environment, which can help to isolate the code from the rest of the system to prevent it from accessing sensitive information or performing illegal operations.
Wasm Frameworks, like CNCF’s wasmCloud, extend the Wasm security footprint further by providing higher-level abstractions, reducing the amount of code that developers embed in each application. wasmCloud also eases the security burden for developers by making it easier to sign artifacts, enable built-in monitoring, and automate the patching of applications.
“In addition, you can use the upcoming component model to constrain the attack surface — the host might, for example, not even offer a file system API — and in the coming world these kinds of constraints will prove critical,” Squillace said. “But don’t be fooled: hosts can still make config mistakes and give too much power to a module!”