WASM will replace containers

I think this author is so far off the mark that it makes me wonder if they were high when they wrote this

> In the year 2030, no one will remember Kubernetes.

As a sys admin, no, we will have to remember. Once a system is in place and "functions", they tend to stay for a long time.

While I don’t doubt the utility of WebAssembly, I do have to kind of roll my eyes at the ignorance of history going on.

Servers were the future of code after mainframes because of simplicity and write-once run-anywhere code but without all the complexity, they just needed similar networking and storage solutions as mainframes had to be viable first.

Virtual machines would be the future of bare metal servers, allowing code to be written once and run anywhere, eliminating the complexity of bare metal servers. VMs just needed better networking and storage first to be viable.

Containers would replace the complexity of VMs and finally allow code to be written once and run anywhere, once orchestration for storage and networking was figured out.

Serverless would replace containers and allow code to be…

You get the idea.

The only thing holding back code from truly being “write-once, run anywhere” is literally everything that keeps it safe and scalable. The complexity is the solution. WebAssembly will start with the same promise of a Golden Path for development, until all the ancillary tooling ruins the joy (because now it’s no longer a curiosity, but a production environment with change controls and SOPs) and someone else comes along with an alternative that’s simpler and easier to use, because it lacks the things that make it truly work.

I don’t particularly care how it’s packaged in the end, so long as it runs and has appropriate documentation. Could be a container, or a VM template, or an OS package, or a traditional installer, or a function meant for a serverless platform.

Just write good code and support it. Everything else is getting lost in the forest.

One can use something like https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container.

E.g. here's I can read host filesystem even though uname says weird things about the kernel container is running in:

  $ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm  /bin/bash
  root@7862d7c432b4:/# ls /app
  bin   home            lib32       mnt   run   tmp      vmlinuz.old
  boot  initrd.img      lib64       opt   sbin  usr
  dev   initrd.img.old  lost+found  proc  srv   var
  etc   lib             media       root  sys   vmlinuz
  root@7862d7c432b4:/# uname -a
  Linux 7862d7c432b4 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux

Gvisor let's one have strong sandbox without resorting to WASM.

> 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.

Correct -- note that the async implementation does not address parallelism (i.e. threading) -- it's a language +/- runtime level distinction.

The overhead is already in the languages that choose to support -- tokio in rust, asyncio in python, etc etc. For those that don't want to opt in, they can keep to synchronous functions + threads (once WASI threads are reimagined, working and stable!)

You can actually solve this problem with both multiple stacks and a continuation based approach, with different tradeoffs.

> 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 :)

Didn't take it as such! The ability to avoid function coloring does not block the implementations of high-threads/high-memory applications, once an approach to threading is fully reconsidered. And adding more options while keeping existing workflows in place is definitely the goal (and probably the only reasonable path to non-trivial adoption...).

How to do it is quite involved, but there are really smart people thinking very hard about it and trying to find a cross-language optimal approach. For example, see the explainer for Async:

https://github.com/WebAssembly/component-model/blob/main/des...

There are many corners (and much follow up discussion), but it's shaping up to be a pretty good interface, and widely implementable for many languages (Rust and JS efforts are underway, more will come with time and effort!).