microservices, serverless...
Truly buzzword compliant, this article.
WASM will replace containers
261–270 of 371 posts
Re: WASM will replace containers
#262There is one thing that makes WASM very awkward: projecting APIs into a sandbox.
If this was done in a way that works in mechanical sympathy with a wide range of languages I think WASM would be more successful. Making an API available inside a sandbox is painful. You have to manually roll something that can deal with memory, marshal calls and parameters etc. I'm not suggesting it is easy. I'm merely pointing out that this is what I see as the main obstacle to adoption.
I am not interested in "generic" access to system resources (filesystem, network etc) at all. In fact, I can't think of any scenario where I'd actually want to do that. I want to provide APIs that deal with external resources in narrowly defined ways.
It is much easier to do this securely when you explicitly have to provide functionality rather than say "here's the filesystem" and then try to clamp down access.
I want to use WASM on servers. Primarily in Go. I want to be able to create a bunch of APIs that provide narrow access to persistence and communication and project those APIs into the sandbox. In a manner that is interoperable and easy to use from various languages. I don't want to have to craft some application specific marshalling scheme.
If projecting APIs into sandboxes in a (mostly) language agnostic way that is natural, safe and easy to use, it'd be easy enough to write system interfaces. I have no idea why so few people see this as important since I feel it should be self-evident.
(And yes, being able to offer concurrency would be nice, but that's a much smaller issue than the problem of there being no good way to marshall APIs into WASM containers)
Re: WASM will replace containers
#263"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…
When did docker started using LXD ? i never knew.
Re: WASM will replace containers
#264Earlier quoted context omitted.
Unlikely as that was whenever you stopped having to write Xorg.conf by hand, ie the mid 2000s.
As long as, people use their computers as PC towers from 2000, without hardware video decoding, sleep states, modern UEFI features. There is naturally the version that works, keeping the Linux kernel, and replacing the userland with managed language frameworks, I have heard they are making a huge success in mobile devices and throwaway laptops.
Hardware video decoding has worked perfectly for decades.
Sleep worked perfectly until Microsoft decided that device manufacturers should replace sleep with overheating in your bag (a much better sleep mode than, y'know, actual SLEEP).
Not sure what "modern UEFI features" means. Whenever something is described as "modern" that screams to me that someone is trying to conflate recentness with quality which is a red flag. UEFI itself has worked fine for as long as it has existed as far as I know?
Why you would replace the userland with "managed language frameworks" is quite beyond me.
Re: WASM will replace containers
#265Earlier quoted context omitted.
Except that it's implemented in all browsers with nothing extra to install. All third party browser plugins failed eventually.
And now we have all plugins back, that is the only utility for WebAssembly, doing two level translation of bytecodes.
WebAssembly is no more a plugin than JavaScript is.
Re: WASM will replace containers
#266Earlier quoted context omitted.
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 implementat…
I have a funny feeling that some day we'll see Docker ported to wasm to "abstract it away cleanly". History is a circle and all that.
Re: WASM will replace containers
#267When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm. To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it…
If you skip the async stuff, Rust in WASM works quite well. I also found that Go has quite good WASM support.
I think the "WASM as containers" and "WASM as .jar" approaches are rather silly, but language support is good enough to use the technology if you think it's a match. I don't think it will be for most, but there are use cases where pluggable modules with very limited API access are necessary, and for those use cases WASM works.
Plus, if you want to run any kind of game engine in the browser, you're going to need WASM. While I'm not replacing my Steam install with a browser any time soon, I have found that WASM inside itch.io runs a lot faster and more stable than Winlator when I'm on my Android tablet.
Re: WASM will replace containers
#268"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,…
> But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. [...] Maybe put the whole thing into a container?
Since this is an emerging ecosystem, why not take a different spin on security, and instead try e.g. capabilities? Instead of opening a connection to the DB, or a listening socket, you get FDs from your runtime. Instead of a path where you can read/write files, such as assets or local cache, you get a directory FD from openat (not sure right now if that could be bypassed with "..", but you get the idea).
Bonus: you can get hot code reloading for very cheap.
Re: WASM will replace containers
#269I don't think that WASM will replace containers. They will continue to move closer to each other but still have their advantages in different fields.
Right now I can run containers and WASM workloads in the same k8s clusters. I dont even have to think about it with runtimes like crun/youki or wasmedge. The OCI image format is the universal package format. It always has all its need and the tooling is broad and mature.
With containers I can basically put any app in any language in there and it just runs. WASM support is far from that, there is migration toil. Containers are and will be more flexible then WASM
Re: WASM will replace containers
#270[dead]