4 ms·

Ok then. Let's say I write a webserver with WASI, compile it to a `.wasm` file, package it as an OCI container image, and deploy it in Kubernetes via a containe

Ok then. Let's say I write a webserver with WASI, compile it to a `.wasm` file, package it as an OCI container image, and deploy it in Kubernetes via a container runtime that loads the entry point into wasmtime. 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).

brabel 3y ago
WASM is a bytecode format like Java bytecode... the difference is that it's sandboxed. It can't do anything that's not explicitly given to it, including using WASI (the POSIX-like API for WASM code to "talk" to the system). 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/ https://wasmlabs.dev/articles/docker-without-containers/
- jmillikin 3y ago
  All bytecode is sandboxed by definition -- the VM decides which operations it delegates to the system. It is possible (and common!) to use JVM bytecode in a VM that restricts access to the underlying system, and in fact one of the original core use cases for Java (applets) relied on this functionality. 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. You don't seem to understand what a container is, or what a sandbox is. 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.
  - brabel 3y ago
    I see you like to ignore reality and go on with your own definitions for things. > 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?
    - remexre 3y ago
      As an aside, to what degree does WASI exist _now_? The spec seems to be in a state of flux as to what the language the spec is written in is, and the language new proposals are written in seems to have grown futures? On the other hand, as far as I can tell, the latest draft spec doesn't look to have support for UDP or scalable notification (epoll, kqueue, etc.), so is that really what people are using their existing software with? 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.
      - jmillikin 3y ago
        > As an aside, to what degree does WASI exist _now_? It's ... rough. The impression I get (as an uninvolved third-party) is that the WASI folks set out with a goal of writing a sort of capability-based POSIX that they could write a thin libc for, but partway through realized that POSIX embeds a lot of assumptions that aren't compatible with portability or capability-based security. 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.
IanCal 3y ago
> If containers and WASM are in fact competing technologies, as you and the article imply, then this shouldn't be possible. 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.
- jmillikin 3y ago
  But they're not solving overlapping sets of problems. That's the point. * 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.

brabel 3y ago

WASM is a bytecode format like Java bytecode... the difference is that it's sandboxed. It can't do anything that's not explicitly given to it, including using WASI (the POSIX-like API for WASM code to "talk" to the system). 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/ https://wasmlabs.dev/articles/docker-without-containers/

jmillikin 3y ago
All bytecode is sandboxed by definition -- the VM decides which operations it delegates to the system. It is possible (and common!) to use JVM bytecode in a VM that restricts access to the underlying system, and in fact one of the original core use cases for Java (applets) relied on this functionality. 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. You don't seem to understand what a container is, or what a sandbox is. 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.
- brabel 3y ago
  I see you like to ignore reality and go on with your own definitions for things. > 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?
  - remexre 3y ago
    As an aside, to what degree does WASI exist _now_? The spec seems to be in a state of flux as to what the language the spec is written in is, and the language new proposals are written in seems to have grown futures? On the other hand, as far as I can tell, the latest draft spec doesn't look to have support for UDP or scalable notification (epoll, kqueue, etc.), so is that really what people are using their existing software with? 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.
    - jmillikin 3y ago
      > As an aside, to what degree does WASI exist _now_? It's ... rough. The impression I get (as an uninvolved third-party) is that the WASI folks set out with a goal of writing a sort of capability-based POSIX that they could write a thin libc for, but partway through realized that POSIX embeds a lot of assumptions that aren't compatible with portability or capability-based security. 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.

IanCal 3y ago

> If containers and WASM are in fact competing technologies, as you and the article imply, then this shouldn't be possible. 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.

jmillikin 3y ago
But they're not solving overlapping sets of problems. That's the point. * 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.