My exploration of WASM/WASI

Assembler was developed in 1947, wow! It makes 78 years of computing development in which we saw higher level programming languages, virtual machine programming languages (write once run everywhere), virtual machines, cloud and so on. A lot of knowledge got accumulated over the time which you can see in size of artifacts deployed to cloud.

Over the years we have seen several attempts reach for the roots. Similarly WebAssembly is instruction format for virtual machine designed to be portable compilation target for any language willing. It is fast as nearly native speed, secure and sandboxed and language agnostic. Originally wrote for the browsers it is beginning to get traction as microservice runtime, which btw is topic of this post.

Comparison to JVM

It is obvious that WASM and JVM share similarities as intermediate-represented runtimes. If you have interpreted language then out of necessity you have to have some mechanism to speed things up. For Java there is tiered JIT compiler and Wasm also has JIT however there is also possiblity of Ahead of Time Compilation.

Wasm was designed for security, portability, and fast startup and differs in several things from Java. First of all WASM modules are compact binaries and smaller size means faster loading. Second all the dependencies are pre-bundled and not needed to be loaded dynamically which takes time. And the binary code is already sandboxed which means it does not need to be validated.

But what is most interesting is that WASM bytecode is closer to native binaries than JVM bytecode which means it can be JITed with less effort. Here is why:

• linear memory model similar to C-style pointers
• no GC
• basic numeric types
• assembly like control flow (loops, branches, direct-calls) versus method invocations

It looks like history took whole circle.

Why bother

Where Wasm will shine in near future is serverless computing, which is now more or less poinless. Imagine deploying 100MB artifact which will spin up in 5 seconds for only ONE function. But with Wasm and it's promises to start withing 20ms the task takes whole new dimension.

And of course cloud is money. And where is money (cost savings) there imo will always be political will to move things forward. I'm pretty sure WebAssembly has bright future, at least for the cloud and edge.

A month ago I watched this wasmCloud presentation which was an interesting case for the Edge. Imagine that you run a factory with devices with computing constraints. If the gear is spinning 5000 RPMs you have to take corrective action right now, instead of waiting for server to respond. Wasm can be deployed on such machines (Edge) and take necessary actions of control loop while delegating higher level business functions to cloud.

Sandboxing and Formal Verification

If computer programs were computationally proven to be correct (formal verification) then there would be no bugs at all. Sandboxing is one step close towards this goal. If you enforce clear boundaries of the system, which files are used, what is sent on network and so on the security is much easier to reason about without "gaps". And once you have perfectly isolated component without gaps you can use formal tools to actually prove the logic is correct. I found something here will take a look in near future.

WebAssembly Component Model

So far the application have been run in one-off basis, but standards are emerging which will handle component interactions (microservices). Here is a summary.

Word	Definition
component	a specially wrapped wasm binary that can interact with other components on clear interfaces
interface	a contract between components that is language agnostic
WIT	interface defnition langauge that you port with componentized applications
world	contract between component and runtime

So you basically write the functionality in Rust and export functions in Wit. Other component imports (also with WIT) these functions and the serialization/deserialization is handled by runtime. wasmCloud claims to also remotely call the imports which is handled with NATS. Why WIT you may ask? Because wasm primtives are just numbers and strings. For high level functionality you need records, tuples, variants, lists and so on.

For now disapointing

It looks all good but is still in it's nascency. This means you probably won't see library for your use (if you don't write yourself). However there are several runtimes that are under development:

• wasmCloud
• fermyon/spin
• wasmEdge
• WAGI
• and more

Right now it is hard to host microservices application with WASI other than communicating via http.

I got carried away and wrote some number factorization microservice app. Check it out!

Conclusion

It's worth following the developments, that's for sure. I'm pretty certain that the bright future is ahead for WASM.