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

121–130 of 371 posts

Re: WASM will replace containers

#121

Post by hardwaresofton »

gchamonlive wrote: post #53
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.

So basically virtual machines, those we can spin up with lxd or firecracker. Not that they don't have file access, it's just that's finnicky compared to containers (I'm thinking docker/podman)

Yes, but note the difficulty of building a specialized I/O or drivers for controlling access in a virtual machine versus the WASI model.

Also, startup times are generally better w/ availability of general metering (fuel/epochs) for example. The features of Wasm versus a virtual machine are similar but there are definitely unique benefits to Wasm.

The closer comparison is probably the JVM -- but with support for many more languages (the list is growing, with upstream support commonplace).

Re: WASM will replace containers

#122

Post by invalidname »

LeFantome wrote: post #99

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…

Yes. It doesn't provide the roughly 20 years of advancements in JVM technology either. Modern observability and JVM scale is at a different level. The trend was to get the maximum use of hardware. Specifically get away from virtualization to containers. This bucks the trend for absolutely no tangible benefit.

Re: WASM will replace containers

#123

Post by DaiPlusPlus »

hardwaresofton wrote: post #108
danpalmer wrote: post #100

Earlier quoted context omitted.

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 implementat…

Good point! This is the hard work that people are undertaking right now. Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces: https://github.com/WebAssembly/WASI/tree/main/wasip2 This is what people are building on, in the upstream, and in the bytecode alliance You're absolutely right about e…

> the flagship feature there is async without function coloring

Correct me if I’m wrong, but that’s only possible if you separate runtime threads from OS threads, which sounds straightforward but introduces problems relating to stack-lifetimes in continuations so it introduces demands on the compiler and/or significant runtime memory overhead - which kinda defeats the point of trying to avoid blocking OS threads in the first place.

I’m not belittling the achievement there - I’m just saying (again, correct me if I’m wrong) there’s a use-case for function-colouring in high-thread, high-memory applications.

…but if WASI is simply adding more options without taking anything away then my point above is moot :)

Re: WASM will replace containers

#124

Post by mdaniel »

ein0p wrote: post #71

I've yet to see a single example of WASM in the wild. How is it supposed to "replace" anything, if nobody is using it?

1Password actually bundles it with everything they ship (browser, desktop, even their golang cli): https://github.com/1Password/onepassword-sdk-go/tree/v0.1.7/... and then use extism to cross over its boundary https://github.com/1Password/onepassword-sdk-go/blob/v0.1.7/...

They compiled their rust libraries to wasm and it allows reuse of those rust bits across everything

The other famous example I know of, but haven't used, is Figma https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

Re: WASM will replace containers

#125

Post by TZubiri »

danpalmer wrote: post #96

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 pr…

Wasm: client, user's device

Containers: server, dev's device

Cmon OP try to keep up

Re: WASM will replace containers

#126

Post by mdaniel »

diego_moita wrote: post #22

Hmm, not sure... Author's argument is "because it is easier today and will be as powerful as containers in the future". Well, what about it gets as powerful but 3 times more complex? Frankly, I find it quite messy to develop WASM in C++ without downloading an emscripten ... container . Yeah, AFAIK, there is no WASM compiler in WASM. Oh an there is the *in the browser*, also. Yeah, but the truth of the matter is that…

> Yeah, AFAIK, there is no WASM compiler in WASM.

What would you do with one if you had it? Run it on your wasm OS?

Re: WASM will replace containers

#127

Post by TZubiri »

Thaxll wrote: post #39

"Learning how to use Docker is a distraction" As if you need to learn anything, you get your Dockerfile and that's it, what else there is to learn? Your WASM app still need Kubernetes to run so it's not adding any value. The complexity is not in running your app in Docker, the complexity is running your container somewhere, and WASM does not help at all with that. WebAssembly is not going anywhere, it's pretty clear…

Disagree.

It's not trivial to manage a running container or group of, with firewalls and filesystems and whatnot.

My biggest gripe is that it's quite redundant with the os and tends to reinvent stuff. You end up needing to learn, doc, and build towards both os layer fw and container layer fw for example.

Re: WASM will replace containers

#128

Post by danpalmer »

DaiPlusPlus wrote: post #123
hardwaresofton wrote: post #108

Earlier quoted context omitted.

Good point! This is the hard work that people are undertaking right now. Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces: https://github.com/WebAssembly/WASI/tree/main/wasip2 This is what people are building on, in the upstream, and in the bytecode alliance You're absolutely right about e…

> the flagship feature there is async without function coloring Correct me if I’m wrong, but that’s only possible if you separate runtime threads from OS threads, which sounds straightforward but introduces problems relating to stack-lifetimes in continuations so it introduces demands on the compiler and/or significant runtime memory overhead - which kinda defeats the point of trying to avoid blocking OS threads in t…

Further to this, my (very basic) understanding is that the actual threading implementation will be left up to the integrator, so some implementations may not actually implement any concurrency (a little like the Python GIL in a way), while others may implement real concurrency, therefore meaning that subtle threading bugs could be introduced that wouldn't be seen until you run in other environments.

Re: WASM will replace containers

#129

Post by danpalmer »

josephg wrote: post #104
danpalmer wrote: post #100

Earlier quoted context omitted.

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 implementat…

True. Its probably worth creating a validation suite for wasi which can check that any given implementation implements all the functions correctly & consistently. Like, I'm imagining a wasm bundle which calls all the APIs it expects in every different configuration and outputs a scorecard showing what works properly and what doesn't. I suspect you're right - unless people are careful, it'll be a jungle out there. Jus…

I understand your point but sadly I think it's too idealistic (not that we shouldn't strive for these goals). We already have those sorts of tests for browsers, and browser compatibility is still a problem. We have acceptance tests for other areas, like Android's CTS tests, but there are still incompatibilities.

That also assumes that everyone involved wants compatibility, and that's unlikely. Imagine a world where every WASM implementation is identical. If one implementation decides to change something to implement an improvement to differentiate themselves in the market, they'll likely win marketshare from the others.

Most companies implementing WASM will tend to want to a) control the spec in their own favour, and b) gain advantages over other implementations. And this is why we can't have nice things.

Re: WASM will replace containers

#130

Post by danpalmer »

TZubiri wrote: post #125
danpalmer wrote: post #96

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 pr…

Wasm: client, user's device Containers: server, dev's device Cmon OP try to keep up

Well, not quite, that's an oversimplification. As I mentioned I think there's a place for WASM as the common unit of business logic, for things like plugins.

Implementing a FaaS runtime like Lambda is actually quite hard to do in a way that is both safe and multi-language. Compiling down to a safe, sandboxed bytecode, is not a bad idea, regardless of whether you're doing that to run it in a user's browser, or to run a FaaS function on some cloud infra, or to write a server-side plugin to a SaaS product.

Post reply on HN