Docker changed the way services and applications are designed, implemented and deployed. Before Docker, applications and services had to work cooperatively on the same machine. Sometimes they did, sometimes they didn’t. If something went wrong an entire machine, virtual or real, needed to be re-provisioned. It was an expensive and time-consuming way to go about application deployment.
Nowadays, a Docker container thinks it’s the only process that runs on a machine. The result is that companies can run thousands of isolated containers on a single machine. Containers can also be created and destroyed at a moment’s notice to meet load demands. Docker opened a whole new movement in enterprise computing that’s both efficient and cost-effective.
Today, the conventional approach to distributed computing on the internet is to use containers. In fact, in many organizations, containers are considered the only way to deploy services and applications. However, another technology has emerged to challenge the dominance of containers: WebAssembly.
Where WebAssembly got its start
WebAssembly is a specification published by the World Wide Web Consortium to create efficient binary executables that can operate in the same way as a container. WebAssembly has the potential to become a significant alternative deployment unit to Docker.
Docker’s creator, Solomon Hykes tweeted in 2019, “If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker.”
It’s that powerful.
WebAssembly is primarily a client-side technology supported by all the major browsers. WebAssembly makes it possible for browsers such as Chrome, Safari, Firefox and Edge to run CPU intensive games and other types of applications.
let instance = new WebAssembly.Instance(new WebAssembly.Module(binary_wasm_array));
WebAssembly code is very small and can achieve near-native execution speed. Thus, it’s a compelling addition to programming for the browser. However, things can get really interesting when WebAssembly is run on the server-side.
Understand WebAssembly on the server
WebAssembly is like Docker in that both technologies share the resources of the host machine. Docker uses Linux features to create process isolation in terms of networking, user permissions and file system access. This is all done by the Docker daemon. On the other hand, WebAssembly is a complied binary that is intended to run under a WebAssembly Virtual Machine.
WebAssembly binaries are written in languages such as C, C++ or Rust. WebAssembly executables are created by compiling source code into a binary format special to the WebAssembly Virtual Machine. Thus, the binaries can be very small and very fast. As mentioned above, WebAssembly binaries can achieve near-native speeds.
How to use WebAssembly on the server
WebAssembly is well suited to support microservice oriented applications (MOA). The main element of MOA is to create applications that are composed of a variety of distinct services. Each service is created, deployed and maintained independently. Services are made up of one or more functions.
A popular way to implement MOAs is to use a container orchestration technology such as Kubernetes or Docker Swarm. Another way to implement MOAs that has gained traction is to use serverless functions such as AWS Lambda or Google Cloud Functions.
However — given the discrete nature of WebAssembly — it too can be used to realize microservices either under a standalone WebAssembly Virtual Machine or as an enhancement to serverless function technology. Industry professionals have already laid the groundwork for this outlet as interest in the MOA community continues to grow.
WebAssembly is a compelling technology, but it does have challenges. The foremost risk is that a WebAssembly executable is binary and there’s no apparent way to know if a given binary contains malware. The same can be said about containers, but because container use is so widespread, a whole industry has emerged to address the security issues at hand.
Server-side WebAssembly is still in its infancy. WebAssembly has published security guidelines, but there remains a major lack in commercials tools that work to secure a WebAssembly binary after it’s left in the developer’s hands. As a result, the industry has a long way to go to catch up to container security.
The road ahead
WebAssembly isn’t a fad. It’s extended well beyond a few GitHub projects and has a proven success record on the client-side. There’s an established open source community and the WebAssembly System Interface has put more focus on a standardized interaction with the host operating system, a major step in the right direction to see its full potential on the server-side.
There’s a lot to be said for WebAssembly development on the server-side. Execution speed in some cases is measured in nanoseconds, which goes beyond the milliseconds it takes for a typical container to run. Also, given that loose coupling and polyglot development are intrinsic to modern microservices-oriented applications if a company already uses microservices, it’s relatively straightforward to add new ones powered by WebAssembly.
Yes, realizing the value of WebAssembly requires you to master new technology, but it doesn’t require you to rewrite a company’s entire technology stack. This alone makes adoption attractive.
Eight years ago, few people knew about, let alone used Docker. Today it’s everywhere. The same might very well hold true for WebAssembly on the server-side. The technology and support are there and developers have shown an increased interest. WebAssembly is well-positioned to be on the same adoption path as Docker. Two years from now the chances are that WebAssembly will be commonplace on the server-side. Those who want to be at the forefront of the wave of innovation about to come will do well to take an interest in WebAssembly now.