3 ms·

WASM solves a different problem to containers. Where WASM does well is in running sandboxed code efficiently, because that's where it started out. I think WASM

WASM solves a different problem to containers. Where WASM does well is in running sandboxed code efficiently, because that's where it started out. I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic. Containers don't solve that problem. They aren't a particularly good security boundary, and they are much heavier weight, in terms of bytes and startup costs, than WASM binaries, because they are deeply integrated into the OS for networking, etc. However, when what you need to do is ship a binary with a bunch of accoutrements, dependencies, files, etc, and then run multiple processes, multiple threads, and use more of the OS primitives, containers are an ergonomic way to do that, and that suits Infrastructure-as-a-Service much more closely.

TZubiri 2y ago
Wasm: client, user's device Containers: server, dev's device Cmon OP try to keep up
- danpalmer 2y ago
  Well, not quite, that's an oversimplification. As I mentioned I think there's a place for WASM as the common unit of business logic, for things like plugins. Implementing a FaaS runtime like Lambda is actually quite hard to do in a way that is both safe and multi-language. Compiling down to a safe, sandboxed bytecode, is not a bad idea, regardless of whether you're doing that to run it in a user's browser, or to run a FaaS function on some cloud infra, or to write a server-side plugin to a SaaS product.
  - verdverm 2y ago
    This is what CUE is exploring for WASM, the ability to have custom functions or plugins that can be shipped with modules and run anywhere. It will be super cool, but they are blocked on upstream changes to the WASM runtime
  - TZubiri 2y ago
    Yeah sure, there was a time people believed that about javascript, and node.js ended up being a tool used to build website middle-ends and BFF to connect to actual backends. The user's device which can be a smartphone or a latpop and the developer's device which can be a 24 hour online server or a 24 hour online server, are just two completely different devices that cannot be abstracted away. WASM is a technology that was born for the frontend, and js was a technology that was born for the frontend, you can for sure metastasize the web front towards the back, but then you end up with a web bias in the frontend (why not make the backend in swift, or Java for phones?, or whatever language will be used for new tech like LLM voice assistants?) and of course a frontend bias in the backend. Not a good look, let's stop it with the full stack thing, let's specialize, half of use do backend, half of you do frontend, and then we keep on specializing, if everyone does everything we'll cover no ground.
shortrounddev2 2y ago
I think WASM will end up being more useful as a universal language VM on client machines than it will as a tool for browser computation
konaraddi 2y ago
Cloudflare, Fastly, and Amex use WASM in their FaaS implementations
- danpalmer 2y ago
  Yeah and that's where it makes a lot of sense. Less sense is replacing containers where you're using much more of the stack. FaaS hasn't replaced VMs, Kubernetes, Containers, etc, so it seems unlikely that WASM would for similar reasons.
- verdverm 2y ago
  There are a lot of package compatibility issues, not everyone has migrated or will migrate away from things like fs access I'm going through this now, giving a full Cloudflare tech stack a shot, but I'm nearing a limit before I just go back to containers
- andrew_rfc 2y ago
  Cloudflare actually uses workerd which is a V8 isolate (which does support WASM with a lot of caveats.)
  - yencabulator 2y ago
    And you can tell it's really always Javascript with the ability to call into WASM. WASM on Cloudflare Workers is clearly a second class citizen.
- andrethegiant 2y ago
  Amex?
  - konaraddi 2y ago
    Internally yeah https://thenewstack.io/amexs-faas-uses-webassembly-instead-of-containers/ https://thenewstack.io/amexs-faas-uses-webassembly-instead-o...
jauntywundrkind 2y ago
You've shown that wasm solves a sandboxing/security concern that containers don't. But wasm also has done a lot to enable a portable easy to ship blob/inage, and is rapidly tackling the distribution problems that has been key to container's success. I'm not sure what we can really put firmly on containers side here, what makes them distinct or lasting as compared to what wasm is shaping up to be. The various wasm runtimes already offer an array of low level threading and networking capabilities. Higher level services like http servers can be provided by runtimes with very optimized native backends, that have excellent performance characteristics but still "appear" as regular wasm. There may be niche long term users of containers for these reasons, but it's unclear to me that the systems programming capabilities will be much of a moat for containers: if anything, I think we'll see wasm implementations competing to provide the fastest performance for the same well specified interfaces in a hot war competition. The main counter-factor against wasm that I see is just interia. Change is slow. These runtimes are still early. Wasm language targets have been around for a while but at various quality/polish levels. Wasm components are still effectively brand new, a year and a month after release, and the specs are still undergoing major updates to figure out how exactly async is going to work & there's very few runtimes keeping pace with this radical upshift. Its happening & I believe in wasm, but this is a long change and the capabilities aren't really truly here yet.
- afiori 2y ago
  Docker-like containers will likely exists as long as there linux servers, maybe the trendiness will leave them behind, but they are a plainly good technology to deploy and distribute application with many fantastic usecases. I too do see a future where Wasm is way more widespread but as of now we are deploying a small app with a MySQL in single docker container. I suspect that we won't be running MySQL compiled to a Wasm container anytime soon* * I suspect that we could with the right transpilations/interpreters but for sure we won't
p12tic 2y ago
Container security boundary can be much stronger if one wants. One can use something like https://github.com/google/gvisor https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container. E.g. here's I can read host filesystem even though uname says weird things about the kernel container is running in: $ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash root@7862d7c432b4:/# ls /app bin home lib32 mnt run tmp vmlinuz.old boot initrd.img lib64 opt sbin usr dev initrd.img.old lost+found proc srv var etc lib media root sys vmlinuz root@7862d7c432b4:/# uname -a Linux 7862d7c432b4 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux
- udev4096 2y ago
  gVisor is solid but it comes with a perf hit. Plus, it does not work on every image
  - yencabulator 2y ago
    FWIW the performance loss got a lot better in ~2023 when the open source gVisor switched away from ptrace. (Google had an internal non-published faster variant from the start.)
weinzierl 2y ago
I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic. I really hope WASM takes over as a plugin mechanism. I don't think it will lead to fragmentation because communities will form around their preferred language, it will just not be enforced anymore. And forcing a plugin language did not work so successfully to prevent fragmentation anyway, see GNU Guile or vimscript.

TZubiri 2y ago

Wasm: client, user's device Containers: server, dev's device Cmon OP try to keep up

danpalmer 2y ago
Well, not quite, that's an oversimplification. As I mentioned I think there's a place for WASM as the common unit of business logic, for things like plugins. Implementing a FaaS runtime like Lambda is actually quite hard to do in a way that is both safe and multi-language. Compiling down to a safe, sandboxed bytecode, is not a bad idea, regardless of whether you're doing that to run it in a user's browser, or to run a FaaS function on some cloud infra, or to write a server-side plugin to a SaaS product.
- verdverm 2y ago
  This is what CUE is exploring for WASM, the ability to have custom functions or plugins that can be shipped with modules and run anywhere. It will be super cool, but they are blocked on upstream changes to the WASM runtime
- TZubiri 2y ago
  Yeah sure, there was a time people believed that about javascript, and node.js ended up being a tool used to build website middle-ends and BFF to connect to actual backends. The user's device which can be a smartphone or a latpop and the developer's device which can be a 24 hour online server or a 24 hour online server, are just two completely different devices that cannot be abstracted away. WASM is a technology that was born for the frontend, and js was a technology that was born for the frontend, you can for sure metastasize the web front towards the back, but then you end up with a web bias in the frontend (why not make the backend in swift, or Java for phones?, or whatever language will be used for new tech like LLM voice assistants?) and of course a frontend bias in the backend. Not a good look, let's stop it with the full stack thing, let's specialize, half of use do backend, half of you do frontend, and then we keep on specializing, if everyone does everything we'll cover no ground.

shortrounddev2 2y ago

I think WASM will end up being more useful as a universal language VM on client machines than it will as a tool for browser computation

konaraddi 2y ago

Cloudflare, Fastly, and Amex use WASM in their FaaS implementations

danpalmer 2y ago
Yeah and that's where it makes a lot of sense. Less sense is replacing containers where you're using much more of the stack. FaaS hasn't replaced VMs, Kubernetes, Containers, etc, so it seems unlikely that WASM would for similar reasons.
verdverm 2y ago
There are a lot of package compatibility issues, not everyone has migrated or will migrate away from things like fs access I'm going through this now, giving a full Cloudflare tech stack a shot, but I'm nearing a limit before I just go back to containers
andrew_rfc 2y ago
Cloudflare actually uses workerd which is a V8 isolate (which does support WASM with a lot of caveats.)
- yencabulator 2y ago
  And you can tell it's really always Javascript with the ability to call into WASM. WASM on Cloudflare Workers is clearly a second class citizen.
andrethegiant 2y ago
Amex?
- konaraddi 2y ago
  Internally yeah https://thenewstack.io/amexs-faas-uses-webassembly-instead-of-containers/ https://thenewstack.io/amexs-faas-uses-webassembly-instead-o...

jauntywundrkind 2y ago

You've shown that wasm solves a sandboxing/security concern that containers don't. But wasm also has done a lot to enable a portable easy to ship blob/inage, and is rapidly tackling the distribution problems that has been key to container's success. I'm not sure what we can really put firmly on containers side here, what makes them distinct or lasting as compared to what wasm is shaping up to be. The various wasm runtimes already offer an array of low level threading and networking capabilities. Higher level services like http servers can be provided by runtimes with very optimized native backends, that have excellent performance characteristics but still "appear" as regular wasm. There may be niche long term users of containers for these reasons, but it's unclear to me that the systems programming capabilities will be much of a moat for containers: if anything, I think we'll see wasm implementations competing to provide the fastest performance for the same well specified interfaces in a hot war competition. The main counter-factor against wasm that I see is just interia. Change is slow. These runtimes are still early. Wasm language targets have been around for a while but at various quality/polish levels. Wasm components are still effectively brand new, a year and a month after release, and the specs are still undergoing major updates to figure out how exactly async is going to work & there's very few runtimes keeping pace with this radical upshift. Its happening & I believe in wasm, but this is a long change and the capabilities aren't really truly here yet.

afiori 2y ago
Docker-like containers will likely exists as long as there linux servers, maybe the trendiness will leave them behind, but they are a plainly good technology to deploy and distribute application with many fantastic usecases. I too do see a future where Wasm is way more widespread but as of now we are deploying a small app with a MySQL in single docker container. I suspect that we won't be running MySQL compiled to a Wasm container anytime soon* * I suspect that we could with the right transpilations/interpreters but for sure we won't

p12tic 2y ago

Container security boundary can be much stronger if one wants. One can use something like https://github.com/google/gvisor https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container. E.g. here's I can read host filesystem even though uname says weird things about the kernel container is running in: $ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash root@7862d7c432b4:/# ls /app bin home lib32 mnt run tmp vmlinuz.old boot initrd.img lib64 opt sbin usr dev initrd.img.old lost+found proc srv var etc lib media root sys vmlinuz root@7862d7c432b4:/# uname -a Linux 7862d7c432b4 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux

udev4096 2y ago
gVisor is solid but it comes with a perf hit. Plus, it does not work on every image
- yencabulator 2y ago
  FWIW the performance loss got a lot better in ~2023 when the open source gVisor switched away from ptrace. (Google had an internal non-published faster variant from the start.)

weinzierl 2y ago

I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic. I really hope WASM takes over as a plugin mechanism. I don't think it will lead to fragmentation because communities will form around their preferred language, it will just not be enforced anymore. And forcing a plugin language did not work so successfully to prevent fragmentation anyway, see GNU Guile or vimscript.