Namaskar, welcome to another fantastic blog, previously we've tried to work with wasm on the user/client-side and learned its advantages but today in this blog we will try to understand the broader applications and advantages of Wasm in the tech industry i.e. using it on the server-side, it is much more functional than we've thought.
Every two years, the number of transistors on a microchip doubles e, though the cost of computers is halved. Moore's Law states that we can expect the speed and capability of our computers to increase every couple of years, and we will pay less for them. Another tenet of Moore's Law asserts that this growth is exponential. The machine learning tasks can run 60,000x times faster when we replace Python with native code and specialized hardware. WebAssembly is a key technology that makes the software more efficient, while preserving safety, portability, and software engineering best practices we built up in the past 25 years.
WebAssembly was invented as a client-side technology, but it is also proven very useful on the server-side. Server-side WebAssembly provides crucial benefits for modern web and service applications.
Fast: WebAssembly achieves near-native performance. Compared with the Java, Python, or JavaScript runtimes, it can be 10x to 100x faster (how is this possible?). It is also much faster than Docker, especially in the cold start and system access.
Safe: WebAssembly is a sandbox with a capability-based security model. It is not only safer than native binaries but also safer than OS-level containers like Docker. Yet it provides access to the underlying system, including new hardware features.
Portable: WebAssembly apps can be written in C, C++, Rust, Go, and run without change on different OS and hardware platforms.
Manageable: WebAssembly programs can be provisioned, started, hot-swapped, stopped, and moved around by other applications.
To run WebAssembly outside of the browser, You need a runtime. A runtime is an application that runs on the command line or via a static library that allows you to load your Wasm module and run it as if it was just any other program. SSVM, Wasmer, WasmTime, Wasm3, WAVM, and Lucet, are some common emerging Wasm runtimes that have been coming out from the community as of late.
SSVM: Second State provides an open-source WebAssembly implementation (Second State Virtual Machine, or SSVM) that is specifically optimized for server-side applications. It is
Best-in-class in performance. It is 1000x faster than Docker for cold starts.
Seamlessly supports server application frameworks, such as Node.js. You can build high-performance Node.js apps with SSVM.
Supports safe access to external resources, such as databases, message queues, and even new AI hardware
Allows precise metering of computational resources for serverless apps.
Wasmer: Wasmer is designed to provide three key features:
Enable programs to run in any programming language
Enable extremely portable binaries to run unmodified on any "OS" supported by Wasmer (for example, Linux, macOS, Windows and FreeBSD).
Act as a secure bridge for Wasm modules to interact with native "OS" functionality, via Application Binary Interfaces (ABIs) such as WASI and Emscripten (version 1.38.43 and earlier).
In a blog written by Libhunt, they compared SSVM & Wasmer
Emerging Tech Stacks where Wasmer is making a Significant Difference:
a) Blockchain: Wasmer's Single-pass compiler helps eliminate JIT bombs, enabling blockchain providers with a high-quality-of-service infrastructure for their applications.
b) Function-as-a-Service (Faas): Wasmer is a market leader for enabling WebAssembly on the server. It nearly eliminates all the challenges developers must deal with to fully adopt FaaS as a part of their application development strategy.
c) Machine Learning and AI: Wasmer nearly eliminates all the challenges developers must deal with for deploying machine learning applications in and outside of data center environments.
SSVM is also running with pace to make its runtime more efficient and progressing exponentially, while other WebAssembly runtimes are in the development stage and are making progress day by day. Soon we will see a lot of efficient Wasm runtimes on the server-side.
Conclusion:
Lately in the server-side development community, which is the desire to simplify, and is coming in the form of things like Functions as a Service, or serverless technology. There's AWS Lambda, OpenFaaS the serverless framework, things like that are really designed to make things simpler, again, because things have gotten much more complex in the last 5 or 10 years, with the rise of microservices and whatnot. It's made things more difficult.
Wasm can really help with this goal by building these very tightly constrained, highly composable modules from various languages, really whatever you want, and fitting them together into whatever configuration that you need for your application, is pretty compelling.
Check this Blog by @cohix where he explains Server-Side WASM: Today and Tomorrow!
References:
- https://www.infoq.com/presentations/wasm-server-api/
- https://www.libhunt.com/compare-SSVM-vs-wasmer
- https://www.secondstate.io/articles/why-webassembly-server/
- https://docs.wasmer.io/ecosystem/wasmer
- https://noti.st/lostinbrittany/hsL7QE
- https://webassembly.org/docs/use-cases/
Do comment your thoughts and suggestions related to the blog and please share if you found it useful.
Top comments (3)
I highly disagree with "WebAssembly achieves near-native performance". There's A LOT of issues with WebAssembly, and the proposals to add features just proves that point.
In my experience WebAssembly is almost 5x slower than native (either using browsers, wasmer or wazero). Also, sounds like that is not just me: arxiv.org/abs/1901.09056. Of course, each compiler and language have their responsibility, also the JIT/Runtime... But.... First, WebAssembly doesn't have threads, and the threads proposal is just terrible and only works based on WebWorkers, so only applies for Browsers, kinda of. On Golang, exists issues that only affects WebAssembly, such as this one: github.com/golang/go/issues/42979. Also, Garbage Collected languages (such as Go) needs to stop the program and analyse all references in single-thread, making it even slower. There's also issues related to the lack of stack/heap and linear memory, and also related to the lack of goto. However, one of the most important performance-cost is FFI calls, via Import/Export, which punish the communication between host <-> wasm.
I like WebAssembly, and I use it. But, "near-native performance" isn't true for me, yet. Anything else is fine, it's safe, and it's portable. It's makes possible to have a single lightweight-VM for multiple languages. But, isn't fast.
Hi @inkeliz_35 , hope u r doing well. In this post I've properly specified the advantage of wasm on some particular languages and framewroks and how if it is taken to right direction would help it to get more optimised and useful.
If I talk about your reply it really make sense but we both have two different argumnets in different directions. In the intial stage everything has more disadvanges than advantages but slowly slowly with more clarity and optimisations, things start getting working as they are expected. Hope this will answer.
Check enarx.dev/ they are using wasm on the server side and they'r doing really good.
I never use Enarx, and I personally never heard about them. However, Envoy supports WebAssembly and also defines the "proxy-wasm". They list a lot of pros and cons related to WASM, github.com/proxy-wasm/spec/blob/ma.... The performance and FFI calls is also be biggest drawbacks listed, and in my use-case it also where WASM fails apart, and fails really bad.
The situation might improve in the future, as you said, but it's unknown. We already have WebAssembly 2, which extends the first version.