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

WASM will replace containers

creston.blog

Post reply on HN
Print view View original

91–100 of 371 posts

Re: WASM will replace containers

#91

Post by tyingq »

Capricorn2481 wrote: post #73
resonious wrote: post #23

Earlier quoted context omitted.

This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.

I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?

The closest way to visualize it is probably how cloudflare offers something kind of like a container (if you squint) via it's workers product.

https://blog.cloudflare.com/announcing-wasi-on-workers/

I assume the merit for cloudflare is lower overhead cost per worker than if they had done something more like AWS lambda. Explained better than I can, here: https://developers.cloudflare.com/workers/reference/how-work...

It does currently present a lot of restrictions as compared to what you could do in a container. But it's good enough to run lots of real world stuff today.

Re: WASM will replace containers

#92

Post by porridgeraisin »

paulgb wrote: post #42

> WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.) This is true if your wasm code is purely computational, but if it interacts with the outside world it’s a different story. Each V8 runtime has a subtly different interface, so code that runs on cloudflare V8 might not run in Bun or Deno. Not to mention if you want to support WASI t…

> Bun

Nit: bun uses javascriptcore

Re: WASM will replace containers

#93

Post by moribvndvs »

One benefit of being an old engineer is watching how excited people get when they rediscover something that has gone around the bend over and over again. I swear if you fuckers reinvent DCOM I will shit in your hats.

Re: WASM will replace containers

#95

Post by josephg »

not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime.

And the nice thing about that is you can pick which environment a wasm bundle runs in. Want to run it on the browser? Sure! Want to give it r/w access to some particular path? Fine! Or you want to run it "natively", with full access to the host operating system? That can work too!

We just ("just") need wasi, and a good set of implementations which support all the different kinds of sandboxing that people want, and allow wasm containers to talk to each other in all the desirable ways. Make no mistake - this is a serious amount of work. But it looks like a very solvable problem.

I think the bigger adoption problem will be all the performance you leave on the table by using wasm instead of native code. For all its flaws, docker on linux runs native binaries at native speed. I suspect big companies running big cloud deployments will stick with docker because it runs code faster.

Re: WASM will replace containers

#96

Post by danpalmer »

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.

Re: WASM will replace containers

#97

Post by mikewarot »

Capabilities based Operating Systems will replace containers. WASM is a stepping stone to help the world better impedance match them conceptually.

If someone tacks on file system access to WASM, the whole system becomes worthless.

Re: WASM will replace containers

#98

Post by oppositelock »

Why does anything need to replace anything?

Containers, VM's, physical servers, WASM programs, Kubernetes, and countless other technologies fill niches. They will become mature, boring technologies, but they'll be around, powering all the services we use. We take mature technologies, like SQL or HTTP for granted, but once upon a time, they were the new hotness and people argued about their suitability.

It sounds like another way to distribute software has entered the chat, and it'll be useful for some people, and not for others.

Re: WASM will replace containers

#99

Post by LeFantome »

WASM does not run on real hardware. At best, WASM can be considered a virtual machine (in the way that the JVM and the .NET CLR are virtual machines). I guess we can call that a "runtime".

Containers package applications that run directly on real hardware (well, directly on a real kernel that is running on real hardware). There is no runtime. I am talking OCI containers here (Docker and Kubernetes). At least they can. Most containers are probably running on a Linux kernel that is running in a virtual machine (in the way that KVM, EC2, and VirtualBox are virtual machines).

WASM needs a runtime. That is, it is going to run inside an application. That application needs to run on a kernel. So, WASM will always be further from the hardware than a container is.

WASM solves the same "portability" problem that the JVM and .NET do. So, maybe WASM wins against those environments.

That is not the problem that containers solve though. Containers bundle applications with their dependencies. They replace "installation and configuration" with instantiation (deployment). WASM does not magically eliminate dependencies or the differences between environments (not even the difference between V8 implementations).

If anything, the technologies are complementary. Maybe, in the future, all our containers will be runing WASM applications.

Or maybe we will run a different kind of container that ONLY runs WASM applications and then WASM can replace the Linux kernel running in a VM that hosts all our OCI containers today. Perhaps that is what the author really envisions. Even then, it sounds like more of a complement than a true alternative.

Re: WASM will replace containers

#100

Post by danpalmer »

josephg wrote: post #95
not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…

This assumes that everyone implements the same set of APIs that work in the same way.

More likely, the browser will implement some that make sense there, some browsers will implement more than others, Cloudflare workers will implement a different set, AWS Lambda will implement a different set or have some that don't work the same way... and now you need to write your WASM code to deal with these differing implementations.

Unless the API layer is, essentially, a Linux OS or maybe POSIX(?) for Docker, which I doubt it would be as that's a completely different level of abstraction to WASM, I don't have a lot of faith in this being a utopian ideal common API, given that as an industry we've so far failed almost every opportunity to make those common APIs.

Post reply on HN