WASM will replace containers

What we have now is lots of hype, mostly by folks clueless of their history, in the venture to sell their cool startup idea based on WASM.

I don't think there's much of a hype cycle -- most of the air has been sucked out of the room by AI.

There aren't actually that many Wasm startups, but there are companies leveraging it to great success, and some of these cases are known. There is also the usefulness of Wasm as a target, and that is growing -- languages are choosing to build in the ability to generate wasm bytecode, just as they might support a new architecture. That's the most important part that other solutions seemingly never achieved.

The ecosystem is aiming for a least-changes-necessary approach -- integrating in a way that workflows and existing code does not have to change. This is a recipe for success.

I think it's a docker-shaped adoption curve -- most people may not think it is useful now, but it will silently and usefully be everywhere later. At some point, it will be trivial to ship a small WASM binary inside (or independent of) a container, and that will be much more desirable than building a container. The artifact will be smaller, more self-describing, work with language tooling (i.e. a world without Dockerfiles), etc.

It needs something to make it a must have for some area of adoption. I just don't see it yet.

It's a similar but quite different solution.

Java

- was designed with a lot of tight system integration foremost, sand boxing being secondary

- a ton of the sandbox enforcement where checks run in the same VM/code as the code they where supposed to sandbox, like you Java byte code decided if Java byte code should be able to access file IO etc.

- Java Applets are, at lest for somewhat more modern standard, a complete security nightmare _in their fundamental design_, not just practically due to a long history of failure.

- a lot of the security design was Java focused, but the bytecode wasn't limited to only representing possible Java code

- Java "sandboxing" targeted a very different use-case/context the "WASM replace containers" blog is speaking about, mainly the blog is about (maybe micro-) servies while Java sandboxing was a lot about desktop application. I.e. more comparable with flatpack and their sandboxing is also (sadly) more about compatibility then security (snap does that better, but has other issues).

And especially the last point one is one to really important as we are not speaking about WASM replacing sandboxing e.g. for dev tools and similar but sandboxing for deployment of micro services written with it in mind. In such context

1. you (should))always run semi trusted code, not untrusted code

2. when giving access to other resources (e.g. file system) it's often in a context where you normally don't need any form of dynamic access management (like you need on a desktop) which means _all the tech underlying to containers can be used with WASI_. Like there is no reason not to still use cgroups, dropping privileges and co integrated in your WASI VM in the same way docker and co uses them.

3. (I kinda thing) there is a (subtle/very slow) trend to not rely only on container isolation but e.g. have a firecracker micro vm run multiple closely coupled containers (a pod/side care container) but place not closely coupled containers in different micro VMs.

The true challenge isn't WASI, but that it's competing with docker->kubernets where docker is "one thing fit's all (badly)" solution which can not only run your services but can also run all kind of dev tooling, legacy applications etc. without requiring any changes to them and can (badly but often good enough) simulate your deployment locally with compose. Then to make the competition hard kubernets has been become somewhat of a "standard" interface to deployment, especially in the cloud, this might suck, but also mean you use OIC images both locally in in production. And that is what the WASI for service sandboxing use-case is competing with OIC images and software running them, nut just docker.