WASM can, but does not replace containers. What is different is that instead of 20 applications running in 20 containers, 1000 applications will comfortably fit in one container, with better sandboxing than the linux process model at the application level.
I really wish you knew how silly this sounds & is. Why would you even run 1 container for 1000 applications if you're saying that WASM provides better sandboxing? Why wouldn't you just run a single WASM process? Also, containers are generally meant for single processes to provide isolation for each app, not to have all your apps running together with the same access.
What many people don't get between WASM & containers is that containers don't need software developers to make changes to support containers. WASM however relies on software developers to make changes to their apps. Otherwise, you have to emulate an entire architecture in WASM which doesn't perform well. It is the difference between VMs, which emulates physical hardware & containers which doesn't need to emulate the hardware cause it provides the sandboxing using kernel features.
> I really wish you knew how silly this sounds & is. Why would you even run 1 container for 1000 applications if you're saying that WASM provides better sandboxing? Why wouldn't you just run a single WASM process? Also, containers are generally meant for single processes to provide isolation for each app, not to have all your apps running together with the same access.
Better sandboxing does not mean completely foolproof sandboxing, and defense-in-depth is a practice for a reason. The idea is a vulnerability in the runtime (your Wasm runtime) would mean system access. A vulnerability in the container runtime underneath (a different layer of security) would mean system access, and then a VM (if there was one underneath) is another layer to break through. This means to get to "root access" on a machine, there are now 3 layers of security to escape.
Running a single wasm process offers better isolation because it is deny-by-default, running a program as a process, or w/ cgroups + namespaces a a container has a wide surface attack surface. You can achieve greater density of applications with Wasm than you can with containers because of the lighter footprint thank a userspace process.
Containers are a hack that packages the assumption of an operating system and a bunch of other files and dependencies into essentially a tarball to make apps run. You must deal with isolation at the OS level (seccomp, etc). Wasm gives you greater control -- you don't have the "same access" for every app, you can vary access infinitely and dynamically, without worrying about OS primitives much more easily with WebAssembly.
It's OK if you think this is silly -- no one is forcing you to adopt the technology, it'll either come around or it doesn't.
> What many people don't get between WASM & containers is that containers don't need software developers to make changes to support containers. WASM however relies on software developers to make changes to their apps. Otherwise, you have to emulate an entire architecture in WASM which doesn't perform well. It is the difference between VMs, which emulates physical hardware & containers which doesn't need to emulate the hardware cause it provides the sandboxing using kernel features.
This is not necessarily true -- WebAssembly support is being added in languages upstream, and the goal (and reality for some programs today) is that compiling to WebAssembly does not require drastic changes. It's not perfect, but this is a stated goal, and is what is playing out in reality. The WebAssembly ecosystem is working very hard both internally and with upstreams to work with use cases/patterns that exist today, and make using WebAssembly close to a no-op/config change.
Any sysadmin/devops person can tell you that the move to containers was/is not pain free. I'm not promising Wasm will be pain free either, but the idea here is that change is happening upstream -- the ecosystem is working to make it pain free. It will be more like changing a few flags (e.g. building for ARM rather than x86) and following the errors. Some languages will be easier to do this in than others.
You'll just wake up one day and your python toolchain will be able to compile to WebAssembly natively with no extra tooling if you want. Maybe you don't have a stack that can make use of that yet, and maybe Django won't be fully supported early on, but Flask more likely will be.
