The "why not containers" is quite thin here, considering the incumbent position would be just to run your WASM things in containers:
The heavier your containers are, the more difficult everything else becomes. They take longer to build, they need more resources to run, they are more expensive to store, etc.
At shuttle we're convinced that a lot of the pains experienced by software engineers in the post-Docker world can be traced back to that very simple statement: containers are often too heavy for the job.
Why not use small lightweight containers? You can just have a layer with the WASM runtime.
because a web backend has a particular pattern of deployment that you can exploit and bake into your system that changes less often than the meat of your web app itself. You could either build out that pattern using container orchestration or using programs running inside container orchestration that in turn orchestrate the more lightweight wasm binaries. I think what you would find is the later to be faster, responsible and stable. It is basically a trade off between writing that logic at say the k8s operator / custom resource layer, or placing that logic inside containers running on k8s that each run wasm binaries.
For the more fixed configuration viewed as an alternative to using K8s... I think most people using containers don't need or want K8s, and most people using K8s wouldn't see this as replacing it. And besides this the service configurations would seem orthogonal to the runtime.
As far as faster, responsible and stable - WASM currently is slower and less stable, and the container world has good options to provide improvements sandboxing/isolation (like gvisor, firecracker, etc).
Comments
The "why not containers" is quite thin here, considering the incumbent position would be just to run your WASM things in containers:
Why not use small lightweight containers? You can just have a layer with the WASM runtime.
because a web backend has a particular pattern of deployment that you can exploit and bake into your system that changes less often than the meat of your web app itself. You could either build out that pattern using container orchestration or using programs running inside container orchestration that in turn orchestrate the more lightweight wasm binaries. I think what you would find is the later to be faster, responsible and stable. It is basically a trade off between writing that logic at say the k8s operator / custom resource layer, or placing that logic inside containers running on k8s that each run wasm binaries.
For the more fixed configuration viewed as an alternative to using K8s... I think most people using containers don't need or want K8s, and most people using K8s wouldn't see this as replacing it. And besides this the service configurations would seem orthogonal to the runtime.
As far as faster, responsible and stable - WASM currently is slower and less stable, and the container world has good options to provide improvements sandboxing/isolation (like gvisor, firecracker, etc).