Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

251–260 of 313 posts

Re: WebAssembly: Docker Without Containers

#251
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.

"nice" threading support is not there

but you can have threaded wasm code in any evergreen browser since a more then a year as far as I'm aware

Basically the trick is that you use multiple web-workers with the same WAS program and the same shared buffer. Then you also add some JS glue code to coordinate which thread is the main thread and which threads you use as thread pool (e.g. in rust/wasm with rayon you can set it up as worker pool).

Now there are some drawbacks (last time when I used it, might have gotten better):

- threads are started/managed from outside (so don't expect any kind of "spawn" function to work, generally spawning new threads is non-trivial and so is (properly) cleaning up old threads, through if you need a fixed worker pool it's all fine)

- there where some limitations wrt. threading/synchronization which made certain usages of concurrency rather slow (through many where fine)

- no "synchronized" operations mustn't be called from WASM code called by the main JS thread. This means in most situations you need to pass data to web workers and then to WASM (instead of e.g. passing it to WASM and then using in wasm a mpmc-channel to pass it to the worker pool). There are some optimizations around passing pointers as numbers to/from the web-workers but it's limited and not nice. Or at least wasn't ~a year ago.

- bugs in Safari leading to strange crashed for code running in all other browsers nicely under unclear and non-debuggable circumstances (probably fixed, I hope)

Anyway all in all using rust->wasm with rayon and a thread pool was already surprisingly viable ~1 year ago.

Re: WebAssembly: Docker Without Containers

#252
post #247

This totally missed the point. I use Docker where the compilation story (and cross-compilation story) is a mess (looking at you, Python) and I don't have the resources to figure it all out. With Docker, I can get a portable image working in a few hours. It's a hack, but it's a convenient one. WASM does not offer this.

It’s people who see the potential of this emergent technology getting prematurely excited. It promises to neutralize the playing field like Java promised, and Docker. I’ve seen WASM do some cool shit, don’t count it out. Just factor in the irrational exuberance.

I am bullish on WASM because technical merits aside it is in the browser and so it will be widely used because everyone knows it will be widely used. JS now runs on or is a source everywhere for example: embedded, frontend, backend, edge, mobile. WASM will be the same.

In addition with so many compile to JS technologies and chains, WASM is sort of another choice. Not a big deal for a team to choose it.

I don’t know enough about will it replace docker. But a lot of docker use cases are a bit of a leaky abstraction over what you are trying to achieve. For example why do I need to know what Alpine Linux is in order to run a node app? OK there is a node image that hides this detail but barely, you end up having to think about this sort of stuff.

Re: WebAssembly: Docker Without Containers

#253

This totally missed the point. I use Docker where the compilation story (and cross-compilation story) is a mess (looking at you, Python) and I don't have the resources to figure it all out. With Docker, I can get a portable image working in a few hours. It's a hack, but it's a convenient one. WASM does not offer this.

This seems backwards to me. Docker is built on Linux process controls and requires the Linux kernel. I believe Docker on MacOS/Windows requires a Linux VM.

> Unfortunately, one of the challenges of running Docker on macOS or Windows is that these Linux primitives are unavailable. Docker Desktop goes to great lengths to emulate them without modifying the user experience of running containers. It runs a (light) Linux VM to host the Docker daemon with additional "glue" helpers to connect the Docker client, running on the host, to that VM.

https://mirage.io/blog/2022-04-06.vpnkit

WASM and WASI would actually be a cross compatibility story because you could compile to an architecture and syscall interface that is platform agnostic.

Re: WebAssembly: Docker Without Containers

#254
post #247

Earlier quoted context omitted.

It’s people who see the potential of this emergent technology getting prematurely excited. It promises to neutralize the playing field like Java promised, and Docker. I’ve seen WASM do some cool shit, don’t count it out. Just factor in the irrational exuberance.

I am bullish on WASM because technical merits aside it is in the browser and so it will be widely used because everyone knows it will be widely used. JS now runs on or is a source everywhere for example: embedded, frontend, backend, edge, mobile. WASM will be the same. In addition with so many compile to JS technologies and chains, WASM is sort of another choice. Not a big deal for a team to choose it. I don’t know e…

It’s pretty cool to write a 3D game in godot, and see a browser run it like it’s nothin. It answers the question “but can it run linux/doom?” easily.

Does it have the marketshare to make AWS make significantly different decisions? Remains to be seen. I guess people paid money for serverless. Could go that way

Edit: I never thought node.js would take over half of the information sphere, so read me more like a graybeard who is too young to be one.

Re: WebAssembly: Docker Without Containers

#255

Earlier quoted context omitted.

The web has SharedArrayBuffer. It’s just difficult to work with.

Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.

Practically speaking, you just want shared memory in your threads. What would a shared heap offer that shared memory can't?

Re: WebAssembly: Docker Without Containers

#256
post #202

Earlier quoted context omitted.

Solomon is no longer at Docker (hasn’t been for a while) and Docker Inc is doing extremely well financially after the split and renewed focus on developers. This Wasm release also shows they are very forward looking… I am very positive on the company and what they are doing (no affiliation other than like Scott and the team over there)

Genuine question: How much of that financial improvement is due to them requiring companies to now pay for Docker Desktop on macOS? We found ourselves essentially with no option but to pay up for a full year on short notice. We want nothing of their other paid offerings like builds or repo hosting. The sales rep basically confirmed we're just paying for the thing we used to get for free now. The whole call was a gian…

Last time I checked, it was completely possible to install Virtualbox and normal Docker CLI on a Mac, and everything worked well (for me), without Docker Desktop at all.

But that last time was on Intel Macs; maybe the situation is completely different on ARM.

Re: WebAssembly: Docker Without Containers

#257

Earlier quoted context omitted.

Are we so what's-old-is-new-again as to be re-inventing fast-cgi at this point? And why are we pretending this has anything to do with WASM instead of just how your API/service is designed?

FastCGI reuses the same process for multiple requests. As I understand it wasmtime now supports very fast startup so you can use a new instance per request (avoiding the risk of inter-request bugs) with very low overhead (5 microseconds on their benchmark https://bytecodealliance.org/articles/wasmtime-10-performanc... .) With Firecracker I believe snapshot restore time is around 2-3ms. In my tests wasmtime ran about…

> As I understand it wasmtime now supports very fast startup

WASM startup isn't going to be any faster than native code startup. It's going to be strictly worse if anything thanks to the JIT, although you can AOT that to native and then just restore parity with native code.

Which just gets back to the speed of your startup depends on what your startup does.

Re: WebAssembly: Docker Without Containers

#258

Earlier quoted context omitted.

Genuine question: do you think people creating software that’s incredibly valuable for you should’t get paid? You had it for free for a long time? Lucky you!

I don't think anyone has a problem with that. The problem is really more one of "we operated so long without paying and now, blam, everyone pays next year". It'd be sort of like if github deciding "You know what, everyone now needs to pay $7 a month/user for github". Perfectly within their right, but also a little bit of whiplash for a large number of people. The next question is if this will last. There's already co…

Exactly! They decided that you would rather pay than migrate off it, so they can start charging, and stop leaving substantial money on the table.

It seems that their assumptions were correct.

Re: WebAssembly: Docker Without Containers

#259
post #185

Earlier quoted context omitted.

I think that security has always been a goal of FreeBSD jails and I believe they are a bit more hardened than docker

Docker only uses namespaces and cgoups. Docker does not provide and security or isolation. To have security and isolation with Docker you must use something external like SELinux or AppArmor. Hope that helps. Regards.

> Docker only uses namespaces and cgroups.

How is that not isolation?

Re: WebAssembly: Docker Without Containers

#260
post #247

Earlier quoted context omitted.

It’s people who see the potential of this emergent technology getting prematurely excited. It promises to neutralize the playing field like Java promised, and Docker. I’ve seen WASM do some cool shit, don’t count it out. Just factor in the irrational exuberance.

I am bullish on WASM because technical merits aside it is in the browser and so it will be widely used because everyone knows it will be widely used. JS now runs on or is a source everywhere for example: embedded, frontend, backend, edge, mobile. WASM will be the same. In addition with so many compile to JS technologies and chains, WASM is sort of another choice. Not a big deal for a team to choose it. I don’t know e…

> For example why do I need to know what Alpine Linux is in order to run a node app?

In case you need to install anything in it as well as your application.

Post reply on HN