Michael Irwin from Docker here (and author of the blog post too). Happy to answer your questions, hear feedback, and more!
For serverless usecases, cloudflare etc.. found that it would be faster to just call a function from a wasm binary than spin up a whole docker container [1]. Which basically translated to cost savings.
In the last company I worked for [2], we saw wasm as a way to easily ship user code in a cross platform way. We mostly targeted edge-ml use cases. Wasm allowed us to package all the "libraries"/functions needed to run the user code securely. So users created and tested out their ML apps in browser and deployed them to all the platforms we supported. (Mobile, Browser, Embedded). As an added bonus they could write each of their functions in any language that compiled to wasm, and just ship it as one "app".
1. https://blog.cloudflare.com/cloud-computing-without-containe... 2. https://hotg.dev/
Are there realistic benchmarks that quantify these gains?
A first view of the promise reads reminiscent to the JVM days, which promised to solve portability. The main difference is JIT vs. AOT, but hidden behind that remains also the complex management of FS access, threading, spawning, SIMD, GPU, and other unportable differences. While I imagine that the shim would avoid having a whole Linux, what do we lose in the change?
Most images nowadays have ARM version, so probably that's how most people use it.
Although; do we need a compiler for Java? It may be going full circle.
> One benefit of using wasm is architecture-agnostic binary. Right now you can't run x86 binary on ARM or vice-versa.
That was the advantage given for the JVM. The .jar ran on x86 and ARM.
Running raw WASM is similar to running Java bytecode, but with fewer cross-platform APIs.
Yes, we need a compiler for Java. Java sources are compiled to Java bytecode along with many other actions for complex projects like downloading dependencies, generating sources, running tests which might run platform-dependent binaries and so on.
> That was the advantage given for the JVM. The .jar ran on x86 and ARM.
Yes, wasm and Java bytecode are the same in that regard. But Java bytecode failed to get adoption outside of Java world. Wasm might not, we will see. One significant improvement of Wasm over Java is good security story. Java sandbox is well known for its CVEs. Browser wasm implementations are battle-tested on billions of devices in the wild Internet. So you basically can't run untrusted Java bytecode without further boundaries like KVM or at least containers. But you definitely can run untrusted Wasm bytecode because that's what your browser does all the time.
A bigger peeve is that there is no general reasonably fast cross build ability, to eg build, test and debug ARM images (for runnign on ARM servers) on x86 Linux or Windows etc.
There's Rosetta emulation and qemu emulation.
Rosetta emulation is quite fast. But docker does not use it. At least for now.
qemu emulation is extraordinarily slow and basically unusable for anything but the simplest code.
As far as Wasm itself, it's designed to provide a fast, lightweight, secure, and portable binary format. While it was originally designed to help bring native code to the browser, it's quickly spreading to the server side. Many folks are using it for edge/IoT, but it's growing into other areas (saw demos today of even using it in databases as psuedo stored procedures). Happy to dive in more if you have more questions!
What, exactly, is Docker doing? Is it compiling the application? Is it making a runtime for the wasm binary? Is it being the runtime for the wasm binary, so the end user builds through whatever usual build processes and gets a binary they can then easily run?
If the wasm binary is lightweight and portable, why is docker useful?
edit: Given the other comments about "what problem does this solve" I think maybe the blog post has missed its mark slightly
Summary of summary: Dockerfile -> docker build -> docker container with the WASM app and runtime inside -> docker push/pull -> docker run container.
However, even if I never compiled anything to WASM I think that it was already possible to build an image with a WASM container and runtime inside (as for any other language/runtime.) So what's the friction this is removing from the process?
I'm a bit surprised by several comments in this post talking about how WASM could replace containers but I don't have the context around it
But tbh if orchestration is really the concern, Docker + wasm seems less efficient than having a dedicated app that can orchestrate multiple wasm modules within the same process. But maybe that's something docker can solve later as the actual requirements emerge.
I wonder if it could make testing frontend code that uses WASM (but not DOM) fast and easy since you wouldn’t need to fire up a complete browser environment.
I’m not sure that it’s possible at the moment. In the past when I needed to test a WASM integration, I ended up using that approach and it was kind of a pain not to get immediate feedback on the WASM code’s API tests since it was essentially only testable through the complete integration environment.
I like integration tests, but I like smaller and faster test suites for easing development in some conditions as well.
You can currently test a WASM-targeted API if you use unit tests or other language-level testing approaches, but you won’t get the constraints of the WASM runtime as far as I know. Maybe the lack of garbage collection could be a critical constraint to test against.
I suppose you could even test dynamically linked binaries without a browser as well.
I’m sure there’s far more to it that I’m not aware of, and maybe testing really isn’t that useful of a feature here — I’m just guessing based on my own experience.
But... certainly a neat idea to think about what Wasm-based applications could possibly look like/run in the browser!
1. Visit https://postgresql.com/try?version=14.x
2. Visit https://nodejs.com/try?version=16.15.1
3. Visit https://edit.com
I miss a feature where I can share a link with some data/schema pre-seeded (maybe from a gist?)
Snaplet.dev is a tool that copies, minimizes and transforms your production database into a shareable file.
Are there namespaces and cgroups and SECCOMP and blocking for concurrent hardware access in WASM, or would those kernel protections be effective within a WASM runtime? Do WASM runtimes have subprocess isolation?
- TIL about teh Endokernel: "The Endokernel: Fast, Secure, and Programmable Subprocess Virtualization" (2021) https://arxiv.org/abs/2108.03705#
> The Endokernel introduces a new virtual machine abstraction for representing subprocess authority, which is enforced by an efficient self-isolating monitor that maps the abstraction to system level objects (processes, threads, files, and signals). We show how the Endokernel can be used to develop specialized separation abstractions using an exokernel-like organization to provide virtual privilege rings, which we use to reorganize and secure NGINX. Our prototype, includes a new syscall monitor, the nexpoline, and explores the tradeoffs of implementing it with diverse mechanisms, including Intel Control Enhancement Technology. Overall, we believe sub-process isolation is a must and that the Endokernel exposes an essential set of abstractions for realizing this in a simple and feasible way.
- [x] Linux containers
- [ ] WASM with or without WASI
eWASM has costed opcodes; basically like dynamic tracing in CPython.
Are there side channels for many or most of these sandboxing methods; even at the CPU level?
> gVisor is an application kernel, written in Go, that implements a substantial portion of the Linux system surface. It includes an Open Container Initiative (OCI) runtime called runsc that provides an isolation boundary between the application and the host kernel.