Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

Post reply on HN
Print view View original

261–270 of 313 posts

Re: WebAssembly: Docker Without Containers

#261

Post by quickthrower2 »

robertlagrant wrote: post #260
quickthrower2 wrote: post #252

Earlier quoted context omitted.

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.

Yes it depends on your philosophy. Lego vs. bespoke art would be my analogy. No right answer, it depends on what you want to build. I think a lot of what I might call uncharitably “webshit” which is the run of the mill stuff that is still very valuable for solving problems can run on turnkey containers.

Re: WebAssembly: Docker Without Containers

#262

Post by laurencerowe »

kllrnohj wrote: post #257
laurencerowe wrote: post #220

Earlier quoted context omitted.

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.

From what I understand, wasmtime's fast startup is conceptually similar to forking a process per instantiation, but much faster since it uses lazy initialization and has fewer operating system resources to setup.

Some of those techniques can be applied to native code too, see "On-demand-fork: A Microsecond Fork for Memory-Intensive and Latency-Sensitive Applications" https://www.cs.purdue.edu/homes/pfonseca/papers/eurosys21-od...

But I think wasmtime can always be faster to instantiate since the guarantees provided by the runtime allow it to safely reset and reuse instantiations:

"We implemented an “instance allocator” in Wasmtime that makes use of this copy-on-write (CoW) technique for very fast instantiations. It also uses a Linux syscall known as madvise to quickly “reset” the page mappings back to the original read-only heap image, so we can reuse the same mappings over and over when the same Wasm program is re-instantiated many times. (One might imagine this would be the case in a server serving many requests, for example!)"

https://bytecodealliance.org/articles/wasmtime-10-performanc...

Re: WebAssembly: Docker Without Containers

#263

Post by moyix »

Is there some page or document that explains how this actually works from the point of view of a traditional container / UNIX process worldview? Like, have the WASM folks implemented an emulation layer for Linux system calls? For libc? POSIX? Or maybe you need to modify your traditional programs so that they use WASM APIs instead? Just very confused at the moment :)

I get the core idea of compiling other languages to WASM, but at the end of the day they have to talk to the outside world somehow right?

Re: WebAssembly: Docker Without Containers

#264

Post by peterhunt »

moyix wrote: post #263

Is there some page or document that explains how this actually works from the point of view of a traditional container / UNIX process worldview? Like, have the WASM folks implemented an emulation layer for Linux system calls? For libc? POSIX? Or maybe you need to modify your traditional programs so that they use WASM APIs instead? Just very confused at the moment :) I get the core idea of compiling other languages to…

I believe this is what WASI is https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

Re: WebAssembly: Docker Without Containers

#265

Post by klabb3 »

my123 wrote: post #159
chriswarbo wrote: post #70

Earlier quoted context omitted.

> For example, making sure build works accross different platforms and machines Unfortunately Docker only works on Linux, since it's tied to specific syscalls. Those on other platforms (e.g. macOS) can only run it in a VM (e.g. the Docker Desktop application is built on top of a VM running Linux) > here are too many ways that something may break, incorrect SDK versions, missing dependencies etc. AFAIK Docker doesn't…

> Unfortunately Docker only works on Linux And Windows. On Windows, Docker can actually create and manage Windows containers in addition to Linux ones. macOS just doesn't have the namespacing primitives for such a scenario as far as I'm aware.

> Docker can actually create and manage Windows containers in addition to Linux ones.

The reason why I’m bullish on WASM is the hope that there will not be a “Linux container” or a “x86 binary”, but only universal binaries and libraries. Unlike the JVM though, they’ll be sandboxed and don’t impose a GC with 200 tuning parameters. Lastly, there is language interop on an FFI level between any two languages that bind against WASM. In short, it’s an interop dream of mine.

That doesn’t mean I endorse premature shilling of everything WASM. That can do more harm than good.

Re: WebAssembly: Docker Without Containers

#266

Post by klabb3 »

nashashmi wrote: post #188

I once imagined a time in a far, faraway land where the new OS secretly in development was nothing more than a thin interface between the hardware and the software. And the software was a VM. And this was codenamed Fuchsia. And was being worked on by Google. They took away the lessons learned from CHromeOS with its LXC containers and Android Container. And realized the new OSs of the future can be anything and everyt…

Fuchsia natively does not use VMs for isolation (although there might be some compat effort that tries to do that). In fact, fuchsia is shipped to one of the lowest-end devices on the market - an old gen smart display. It also uses content addressable FS to deduplicate shared deps. Remember, nightmares aren’t real.

Re: WebAssembly: Docker Without Containers

#267

Post by bombolo »

laurencerowe wrote: post #220
kllrnohj wrote: post #204

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…

> you can use a new instance per request

I doubt this will ever be as fast

Re: WebAssembly: Docker Without Containers

#268

Post by laurencerowe »

bombolo wrote: post #267
laurencerowe wrote: post #220

Earlier quoted context omitted.

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…

> you can use a new instance per request I doubt this will ever be as fast

What approach would be faster that provides similar isolation? It certainly seems a lot faster than fork and seemingly faster than the on-demand-fork I mentioned elsewhere.

Re: WebAssembly: Docker Without Containers

#269

Post by pnt12 »

cstrahan wrote: post #206
greiskul wrote: post #181

Earlier quoted context omitted.

It's not about the software being complicated to install without Docker. It's about Docker making the installation process uniform no matter the software.

I think you're missing the GP's point. What docker provides is a way to shrink-wrap a given build and all of its runtime dependencies. Despite popular misconception, what docker does not give you is a deterministic way to build that software. A Dockerfile provides the RUN steps necessary to build the software, but dependencies must still be fetched over the network, introducing non-determinism. You can spend 6 months…

> Despite popular misconception, what docker does not give you is a deterministic way to build that software.

I read an interesting thought: reproducibility is a spectrum. Docker isn't as reproducible as nix, but when used with version control and ci/cd, is damn more reproducible than zips with code and ftping them to servers.

Re: WebAssembly: Docker Without Containers

#270

Post by my123 »

klabb3 wrote: post #265
my123 wrote: post #159

Earlier quoted context omitted.

> Unfortunately Docker only works on Linux And Windows. On Windows, Docker can actually create and manage Windows containers in addition to Linux ones. macOS just doesn't have the namespacing primitives for such a scenario as far as I'm aware.

> Docker can actually create and manage Windows containers in addition to Linux ones. The reason why I’m bullish on WASM is the hope that there will not be a “Linux container” or a “x86 binary”, but only universal binaries and libraries. Unlike the JVM though, they’ll be sandboxed and don’t impose a GC with 200 tuning parameters. Lastly, there is language interop on an FFI level between any two languages that bind ag…

WASM performance just isn't there. At scale, evaluating the costs just made me shudder.

For server scenarios, no, this just isn't it.

The JVM does a lot of very useful things that WA does not try to handle. Java is not going anywhere and is still going to need a GC. The WA runtime does _not_ handle memory safety inside of the app at all as of today...

Post reply on HN