[flagged]
I also think your fixed perspective that these are & always will be different levels of the stack is an inadequate fixedness, lacks the mental agility to comprehend many of the things wasm is growing into. For years already, standard libraries like wasi are attempting to become fairly complete platform libraries. Instances of wasm run in effectively process trees of chroots, so the simar parity is apparent.
It's absolutely coom sense to be comparing startup times across the two. There have been endless efforts to try to make cold boot containers or container snapshots as fast as possible. And this again extends backwards in time to comparisons versus vm's as well, with efforts like the Xen Zerg demo trying to make vm's fast enough to boot a vm per request. https://news.ycombinator.com/item?id=5243360
Getting back to a process per request or process per session model is a holy grail, one that every virtualization/containerization technology has explored. It would greatly alter the application development model & potentially greatly enhance security, could help radically reshape resource management. This article is doing a fine job pointing to the future, to what we are unlocking. We absolutely should compare versus what the technology of today (containers) can do. The comparison is spot on.
It's a meaningful comparison because they often solve the same business problem; you need to run some code in an isolated/managed environment. Whether that's done through a process tree or a single process is an implementation detail for many purposes; not being able to run multiple processes might have implications for some use cases, but a lot of systems (e.g. docker/kubernetes, or especially anything serverless) are oriented around using a container for a single process.
A comparison between WASM and "containers" is meaningless, because the binaries being executed by a container runtime could be written in WASM. The executable format and the packaging format are separate concerns.
This might be easier to think about if you imagine the article was written as "native code vs containers" -- what conclusions (if any) could you draw from the benchmarks in an article with that premise?
If someone wants to try to advertise some weird custom platform that uses WASM as an intermediate bytecode for its packaging format then that's fine, but they'll need to pick a different name.
Besides, words are just approximations of thoughts, and even on the best of days the delineations aren't crisp. There's a critical mass of people using WASM+containers to refer to WASM ... plus containers (especially those built on the core tech supported by the WASM mission -- WASI -- like the platform tested in the article).
If containers and WASM are in fact competing technologies, as you and the article imply, then this shouldn't be possible.
On the other hand, if WASM is a format for executable code as I claim, then packaging WASM as a container image and executing it in a container runtime is fine and should work as well as any other machine-independent bytecode (such as JVM).
Because it's sandboxed, you can use it without a container. I think that's what you don't seem to undestand. There are several companies offering WASM-based "containers" in the cloud - which don't need any actual container, the WASM runtime has the same type of capability of a container, to isolate processes running on the same hardware securely.
It's even possible to make an actual Docker container run purely on a WASM runtime, as Docker itself is doing now! https://wasmlabs.dev/articles/docker-without-containers/
The difference between WASM and JVM is that WASM was designed to be both (1) a compilation target for memory-unsafe languages like C, and (2) have verifiable control flow so it's easier to write a provably-secure JIT.
> Because it's sandboxed, you can use it without a container. I think
> that's what you don't seem to undestand.
The reason to deploy software as a container image (instead of a standalone binary) is that a container image contains a full chroot, including auxiliary files that aren't embedded into the main binary. Whether the binary is native machine code or WASM doesn't matter -- the tradeoffs of bundling everything into one binary vs placing them on disk are the same regardless of executable format.
The reason to run a sandbox is to restrict which system resources a process can access or interfere with. You can sandbox a process whether or not it runs in a container.
> All bytecode is sandboxed by definition
Oh my... you probably mean "all bytecode COULD be sandboxed"... try sandoboxing JVM bytecode... they tried that for years :D didn't quite work.
> The reason to deploy software as a container image (instead of a standalone binary) is that a container image contains a full chroot,
No. Stop trying to tell us what a container should be used for. A container's main usage nowadays is to run multiple isolated "processes" or set of processes in a safe manner, making the most of the hardware... coincidentally, you can also do that using WASM. Get over your outdated worldview, mate.
EDIT: please read the link I provided. From the creators of Docker:
"If WASM+WASI existed in 2008, we wouldn't have needed to create Docker."
How does that align with your definition of what a container is or isn't?
Docker's great win is that you don't even need to recompile your software to use it, much less port it to what's essentially a new non-POSIX operating system.
> As an aside, to what degree does WASI exist _now_?
IMO (again, no direct involvement) a better approach would be to start with a low-level API that is capability-based from the beginning. Something like EFI, or (more experimentally) an RPC-oriented syscall API resembling Fuchsia/Plan9. Then the various sorts of magic integers and process state found in POSIX can be layered on top of that as a library.
The good news is that the people working on WASI do seem aware of what they've gotten themselves into, and I think a lot of the chaos (shifting repos, broken docs, etc) is just the natural outcome of them exploring the solution space. My expectation is that they'll be forced to drift pretty far from POSIX if they want a workable design, but maybe they'll surprise us.
That doesn't make any sense to me. Just because you can put a thing inside another thing doesn't mean they don't also solve an overlapping set of problems.
* WASM competes with native machine code (x86, ARM, etc) as the format of an executable binary.
* Container images compete with Apt, RPM, and tarballs as a packaging and configuration mechanism.
* Container runtimes compete with systemd as a way to manage process trees.
There is no overlap here.
WasmEdge is a container runtime designed for running Webassembly
If you check the whole article, you'll find the (simple and basic) benchmark comparing a rust "hello world" running with runc, and (apparently) the same code compiled to Wasm and running in WasmEdge.
It's not just comparing pure WASM (bytecode) but the WASM+WASI (runtime) which is what this article's WasmEdge (runtime) is about.
It's a meaningful comparison when the original creator of Docker containers also compared them:
>Solomon Hykes / @shykes@hachyderm.io @solomonstre
>If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task!
-- from 2019-03-27t20:39:47 https://twitter.com/solomonstre/status/1111004913222324225
> It's not just comparing pure WASM (bytecode) but the WASM+WASI (runtime)
You still need a syscall shim to provide the WASI implementation, and you need a WASM VM to run it.
> It's a meaningful comparison when the original creator of Docker
> containers also compared them:
Docker container images are architecture-specific, and it took years before their distribution protocol supported specifying the architecture. If the existence of an architecture-agnostic bytecode would have avoided the need for Docker, then the JVM would have filled that niche perfectly.
And if you look at the Docker code, the vast majority is about configuring the runtime environment of the container (networking, bind-mounts, logging) and persisting that state across reboots. There is no syscall shimming like in gVisor or a WASI implementation, it's all about setting up a chroot and then calling `exec()`.
If WASM had existed in 2008, maybe the Docker folks would have enabled it as an entry-point format, but you'd still need a way to ship all the other stuff that goes along with the main binary.
It's baffling that people feel the need to fabricate ways for WASM/WASI to be important, when the projects themselves are already so interesting. Architecture-agnostic plugins! A clean slate for a capability-based syscall ABI! A genuine chance at running unmodified userland programs in memory-safe sandboxes! Get excited about that, not about someone poorly re-implementing AWS Lambda.
[0] Maybe one day most small shell tools will be in WASM+WASI, and the typical Linux distribution will have relatively little native code installed by default.
https://next.redhat.com/2023/02/01/running-webassembly-workl...
> Actually there is support for using WASM as a container runtime.
Some container runtimes (such as `runc`) execute a native binary. There are also container runtimes that execute a WASM+WASI binary.
So trying to compare WASM with "containers" is like asking "should you deploy your code as x86 or as a container", which isn't a useful question.
Wikipedia describes CGI as "In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.[1]
Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs.[2]
A typical use case occurs when a web user submits a web form on a web page that uses CGI. The form's data is sent to the web server within an HTTP request with a URL denoting a CGI script. The web server then launches the CGI script in a new computer process, passing the form data to it. The output of the CGI script, usually in the form of HTML, is returned by the script to the Web server, and the server relays it back to the browser as its response to the browser's request.[3]"
Which bears little resemblance here imo.
The typical way to deploy CGI during the '90s was to have a compiled program in C/C++, which would be executed once per request. There were entire frameworks built around this "process per request" model, with various optimizations like pre-warming (start the process, connect to db, wait for request on stdin) and variant protocols (SCGI).
Any time you have an execution model based on running a single address space per request, it's fundamentally CGI-ish. It doesn't have anything to do with the implementation language. The limitation of CGI is that state can't be persisted in-process between requests.
---
Going back to the thread, there's multiple aspects when thinking about the structure of a hosted service:
1. Whether state is shared between requests (CGI vs long-lived process).
2. Whether the binary is native code (x86/ARM/) or bytecode (WASM/JVM/).
3. Whether the binary is standalone or comes with additional files.
4. If it needs additional files, whether it's distributed as a package (apt/rpm) or chroot (container image).
Does breaking those different concepts down into a list help? You can see that trying to compare the performance of "WASM deployed as standalone binary with CGI execution model" and "native code deployed in container image" just isn't meaningful. The article is mixing up too many different ideas when trying to benchmark.
I think what the article is implicitly doing is comparing WASM bytecode running under a container runtime that executes it directly (e.g., without a full chroot). Your point, iiuc, is that there are many variables here, of which x86 vs WASM is only one, and that the benefits here might not be due so much to WASM so much as they are due to the other factors.
I didn't understand where CGI-ness comes into it though, as I don't think there's any difference between this kind of container and any other in terms of the duration or when it's starter up, but perhaps your point is that it's lacking some "full" environment, which makes is akin to CGI? I guess a more accurate comparison would be against an x86 binary being executed with some kind of minimal docker runtime, then? I guess the article could be interpreted generously then as a comparison between a thin docker runtime and a thick docker runtime.
On the container side Docker also has native WASM support in a technical preview [0]. I don't think they see WASM as a threat, but rather as an addition to how apps and services can be delivered.
The other day I found an InfoWorld article "Solving the SBOM crisis with WebAssembly Components" [1] that features a diagram on the evolution of Application Development Stacks (by Cosmonic, one early adopter Wasm vendor) that indicates the trend. Idea is to tackle some of the complexity in current infra setups that have become like "Rube Goldberg machines".
It is interesting, but beware hype cycle trends.
[0] https://www.docker.com/blog/announcing-dockerwasm-technical-...
[1] https://www.infoworld.com/article/3694902/solving-the-sbom-c...
Thankfully there is work like the Containerd Sandbox API which enables new architectures like this. https://github.com/containerd/containerd/issues/4131
It's still being used to spawn a wasm processes per instance for now, but container runtime project Kuasar is already using the Sandbox API to save significant resources, and has already chimed in in comments on HN to express a desire to have shared-process/multi-wasm-instamxe runtimes, which could indeed allow sub ms spawning that could enable instance per request architectures. https://github.com/kuasar-io/kuasar
Cloudflare's blog post at https://blog.cloudflare.com/cloud-computing-without-containe... contains a graph in which requests are handled in 200 microseconds, orders of magnitude faster.
And for CGI model, there is a reason why servlets, ISAPI handlers and Apache language modules came to be.
Maybe compare those to start with, then sell how great WebAssembly is for server side. /s
Kata Container is a secure container runtime that uses hardware virtualization technology as an additional layer of defense. This allows it to provide stronger workload isolation while still being lightweight and performing like regular containers.
The article title could have been better worded, though.