Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

121–130 of 313 posts

Re: WebAssembly: Docker Without Containers

#121

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

Re: WebAssembly: Docker Without Containers

#122
post #65

Earlier quoted context omitted.

This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

> you have tp put it in a VM , which gives you a performance penalty

This claim is dubious for many configurations of hardware accelerated virtualization. The hardware creates another ring 0 for each guest kernel, and guests run at the same level as the host. It's true that layering things like filesystems and networking incur overhead, but it's just as easy to pass through a physical disk, and bridge virtual TAP interfaces to physical NICs.

Hardware virtualization is very flexible, and there's a configuration out there that will meet the performance requirements of the vast majority of projects.

Re: WebAssembly: Docker Without Containers

#123
post #121

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications.

Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.

Re: WebAssembly: Docker Without Containers

#124
post #10
post #6

Earlier quoted context omitted.

Expect now you need to compile / port everything to WASM+WASI...

Hey! A WasmLabs team member here :). We're planning to port several runtimes as part of our WebAssembly Language Server initiative [1]. Porting things to Wasm+WASI is sometimes challenging. There are some deep-dives in our blog around this topic [2]. [1] https://github.com/vmware-labs/webassembly-language-runtimes... [2] https://wasmlabs.dev/articles/php-wasm32-wasi-port/

I'll start by saying I'm a big fan of wasm but just a couple of comments about the articles.

I really with the WebAssembly community would stop quoting that tweet from Solomon Hykes. It's taken somewhat out of context and while at the time it was a big shoutout to the wasm underdog it's now a bit over used. Wasm really needs to justify itself with more than just a tweet and I think that it can.

"Polyglot - 40+ languages can be compiled to Wasm" is a bit misleading which anyone would see if you listed the 40+ languages. A lot of them are going to be very obscure ones and a lot of the popular ones are on that list. Factually correct but you're just setting people up to be disappointed. "40+ languages oh boy!.....What the heck is Zig? and no Python?!" (yes, I know you can sort of run Python if you run the entire interpreter)

Re: WebAssembly: Docker Without Containers

#125
post #6

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Solomon Hykes (co-founder of Docker) https://twitter.com/solomonstre/status/1111004913222324225

Expect now you need to compile / port everything to WASM+WASI...

Which si way easier than supporting 15,000 distros of linux

Re: WebAssembly: Docker Without Containers

#126
post #123
post #121

Earlier quoted context omitted.

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.

This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html

Re: WebAssembly: Docker Without Containers

#127
post #102

Earlier quoted context omitted.

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies . It's more like Flatpak or AppI…

> Oh shucks. Docker's value proposition is emphatically not security.

Congratulations, you have just discovered the additional value that WASM will bring to the Docker approach.

Re: WebAssembly: Docker Without Containers

#128

Earlier quoted context omitted.

Although that's true (ish... you can run WASM on the JVM now, and also LLVM bitcode), that takes you into the realm of why you'd want to. On the browser side, you could maybe make a ChromeOS style argument of just wanting to run everything in a browser no matter what, it's nice for it to be sandboxed etc. But if you look at what your Postgres is doing it's sort of a Linux VM, and you can run those already at full spe…

LLVM on the JVM is news to me, have a link?

https://www.graalvm.org/latest/reference-manual/llvm/

Re: WebAssembly: Docker Without Containers

#129
post #121

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

Threading support is already implemented in some browsers and well on its way to standardization https://webassembly.org/roadmap/

Should address that concern. However there is another way of looking at performance and is in the context of serverless where typically single threaded performance is inportant, as well as cold start time etc and that’s why Wasm is popular in that scenario

Re: WebAssembly: Docker Without Containers

#130
post #93

Earlier quoted context omitted.

There are serious attempts at secure container runtimes (see gVisor) and runtimes that run container images in a real VM (see Firecracker). This meme that containers are inherently insecure just because Docker doesn't attempt to be a security product needs to die. Docker hasn't been the only player in the container runtime space for a long time.

Insecure is a very strong word, world has been running on Docker for sometime and it works fine and is not as insecure has you seem to think.

The world does not rely on docker for security at all, cloud providers put each tenant of container runtimes behind an additional barrier, like a VM.

Secure runtimes are a superior solution to virtualisation and separate kernels. There are only two secure runtimes in common use - for javascriot and webassembly.

The point about hardware support is very unfair - if you invest the same level of effort and hardware support into webassembly, you can also i prove its performance. Thats like compaining that electric cars suck because there are no chargers - its just infra.

Post reply on HN