WebAssembly

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.

Already, WebAssembly (aka Wasm) has been shown to work exceedingly well in the browser. It is widely used as a way to improve speed and security, and especially computing simplicity for applications that run directly in the browser, notably with JavaScript, as well as other languages. This speed and simplicity are eventually thanks to its binary computing structure that runs directly in a very clean way on the CPU.

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.”

An essential feature of Wasm is how it allows developers to no longer concern themselves with working with a potential multitude of libraries in order for their code to see deployment. “WebAssembly offers the promise of sharing libraries regardless of the underlying language. For example, a JavaScript program can load a library originally written in Python, and another written in Rust, and use them both,” Butcher said. “In today’s language ecosystem, every programming language has its own YAML parser, its own JPEG library, and so on. How many hours, days, and months are wasted implementing the same algorithms in a plethora of languages? WebAssembly is the remedy.”

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.