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

201–210 of 313 posts

Re: WebAssembly: Docker Without Containers

#201

Post by ridruejo »

paulgb wrote: post #133
ridruejo wrote: post #129

Earlier quoted context omitted.

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

“Threading support” in this sense is a bit of a misnomer, it’s really support for thread-safe memory constructs. Creating threads is left up to the runtime. On the web, this is done with WebWorkers, but on the server side I don’t think there is yet a standard way to do it supported by major runtimes.

Support on the server side is planned, still waiting for standardization https://github.com/bytecodealliance/wasmtime/issues/888

Re: WebAssembly: Docker Without Containers

#202

Post by mdeeks »

ridruejo wrote: post #132
nine_k wrote: 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…

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 giant "FU, too bad". Left an extremely bad taste in our mouths. Obviously we're going to focus heavily on dumping Docker Desktop as fast as possible in the next quarters.

Re: WebAssembly: Docker Without Containers

#203

Post by Sohcahtoa82 »

ptx wrote: post #171
nine_k wrote: post #102

Earlier quoted context omitted.

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…

> Docker's value proposition is emphatically not security [...] It's the ability to deploy [...] gnarly and imperfect software This sounds like a recipe for disaster to me and is why I haven't gotten into Docker. If the software being deployed is too complicated to build and install without Docker, but Docker doesn't provide secure isolation, how can you be sure that this "gnarly and imperfect" mess of a system is se…

> how can you be sure that this "gnarly and imperfect" mess of a system is secure?

You can't.

But it's not like escaping a container is going to happen because of a simple bug. You need an exploitable vulnerability in the containerized app that creates a path to escaping the container.

But yeah, if you want to isolate an app for security reasons, then you need a VM.

Re: WebAssembly: Docker Without Containers

#204

Post by kllrnohj »

ridruejo wrote: post #200
kllrnohj wrote: post #134

Earlier quoted context omitted.

> Fast - it can offer native-like speed via the JIT/AOT capabilities of most runtimes. No cold starts, unlike booting a VM or starting a container. What do you mean? This bullet point had a rocket emoji! Surely you don't actually want evidence to support a rocket emoji?!?

No cold-starts means no overhead of starting a process to answer a request like most container-based serverless environments (without having to keep pre-warmed instances which kind of defeats the purpose) A couple references regarding cold-starts and performance in serverless environments. https://www.fastly.com/blog/lucet-performance-and-lifecycle https://arxiv.org/abs/2010.07115

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?

Re: WebAssembly: Docker Without Containers

#205

Post by layer8 »

sitkack wrote: post #184
pjmlp wrote: post #67

Earlier quoted context omitted.

Well, http://nestedvm.ibex.org/

You realize nestedvm is compiling native code to MIPS and then inlining the MIPS interpreter into the generated class files? Had the JVM supported unsigned types, none of this would have been necessary. Wasm is a refinement of the ideas in the JVM, with a couple good JVM on Wasm solutions already existing. The best of which is CheerpJ. Instead of referencing NestedVM, you should link to GraalVM which I know you are a…

Unsigned types are trivially emulated using signed types. All arithmetic operations except division/remainder and comparison are identical on the bit level, and the latter are supported via `Long.divideUnsigned()` and friends, which can JIT to the native unsigned operations of the underlying platform.

The main difference with regard to compiling “arbitrary” programs between the JVM and WASM is that the JVM doesn’t have untyped linear memory like WASM does. WASM isn’t type-safe within the linear-memory regions (which is what allows C-like languages to be compiled more directly), whereas JVM ensures type safety for all objects.

Saying that “WASM is a refinement of the ideas in the JVM” is simply wrong, they have different design goals and therefore implement different design trade-offs.

Re: WebAssembly: Docker Without Containers

#206

Post by cstrahan »

greiskul wrote: post #181
ptx wrote: post #171

Earlier quoted context omitted.

> Docker's value proposition is emphatically not security [...] It's the ability to deploy [...] gnarly and imperfect software This sounds like a recipe for disaster to me and is why I haven't gotten into Docker. If the software being deployed is too complicated to build and install without Docker, but Docker doesn't provide secure isolation, how can you be sure that this "gnarly and imperfect" mess of a system is se…

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 happily using the latest release of some image, only to find that there's a critical bug or vulnerability that needs addressing ASAP. It kind of sucks for that complacency to turn to terror when you try to patch the software and rebuild, only to find inscrutable errors due to an absolutely bonkers build system.

"ERR: Version A of Foo is incompatible with version B of Bar"

Okay... but what happened here? What versions were we pulling before? Oh, the precise version isn't pinned in the build system, so.. I dunno. Great. It would really help if I knew if it was A that updated breaking B, or the reverse.

Then multiply that by 1000x.

And then add in (for Debian-esque base images) Apt repositories disappearing over time, git feature branches being deleted, tarballs falling off the edge of the internet, etc.

Now, before someone says "well, that's on you if your Dockerfile obscures so much build non-determinism!"

I agree with that statement! But that is a non sequitur with respect to the original premise: the build systems (and the web of dependencies they pull in) in third-party software you don't have ownership of is getting crazier and crazier, and Docker helps perpetuate this state of affairs, and the industry suffers as a whole.

Re: WebAssembly: Docker Without Containers

#207

Post by blacklion »

et1337 wrote: post #121
jeroenhd wrote: post #117

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.

The biggest missing thing (for production) is observability.

Look at old-good JVM. It has tons of tools to analyze and understand behavior of your production system. You could have thread dumps (stack traces of all existing threads) at any moment with negligible performance impact, you could dump heap and analyze it off-site, you could have tons of metrics, about each dark corner of mutexes, GC process, about JIT, including, if you need it, generated native code!

Many of these thing you could get on production, not in sand-box.

If you system behaves strangely, live-locks, consume more memory than you think it should, tharsh GC, you name it, you have all tools to understand what is wrong, find bugs or mis-configurations, etc.

With all these new-and-shiny WASM and not-so-shiny JS VMs you mostly in the dark now. Service become unresponsive? latency goes to the roof? Only thing you could do - restart.

It is not property of WASM per se, but this infrastructure is too immature now, comparing to 25+ year old technology.

Re: WebAssembly: Docker Without Containers

#208

Post by buu700 »

nine_k wrote: post #65
tony-allan wrote: post #2

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

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…

This is what initially confused me about comparisons between Docker and wasm, as someone who's long been a fan of both.

As far as I know, wasm won't let me apt-get install a bunch of stuff, set up cron jobs, glue together miscellaneous bash scripts, and magically run it without containers or VMs on any host architecture. That's the use case I'm most familiar with for Docker; wasm as I knew it was just a neat way to run untrusted native code on arbitrary machines with reasonable performance and security.

I think the disconnect is that Docker is also used as essentially a glorified package manager (sort of like Snap), combined with a runtime/interface that makes it convenient for devops purposes. From that perspective, I suppose there's not much difference between running a standalone binary inside its own dedicated Linux environment, and compiling it to wasm to run directly on the host OS, so long as the API remains unchanged.

It's just needlessly confusing to go as far as to call wasm a wholesale replacement for Docker. It's like saying Java is an alternative to Windows.

Re: WebAssembly: Docker Without Containers

#209

Post by skwee357 »

jeroenhd wrote: post #117

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…

Not exactly what you've asked for, but I did a "dummy" benchmark of Rust vs WASM on my blog[0]. WASM is impressive technology indeed, and it will be interesting to see whether it will get into the mainstream of software engineering.

[0] https://www.yieldcode.blog/post/native-rust-wasm

Re: WebAssembly: Docker Without Containers

#210

Post by jensenbox »

I stopped reading once I saw the article was targeting PHP. I am sure this is a great technology but really hard to see the benefit over standard docker.

Does anyone have a pro/con list for docker and wasm at the server?

Is there a "Use Docker when..." or a "Use WASM when..." style guidance?

Post reply on HN