Hm. Controversial opinion is a good way to describe it. The thing is: Docker or Podman is just the runtime coordinated and controlled by Kubernetes or Nomad in

Hm. Controversial opinion is a good way to describe it. The thing is: Docker or Podman is just the runtime coordinated and controlled by Kubernetes or Nomad in our case. Nomad practically already supports a hypothetical WASM runtime or offers simple hooks into this: You have e.g. a java driver in Nomad, which downloads a fat jar from an artifact store, cgroups it as far as I know and launches it with one of the available JVMs. There's a bunch of these drivers, even down to IIS pools. Some generic WASM runtime would slot right in there. However, we don't use them. Once you use them, you're again coupling the application runtime to OS updates and management. Staying in the Java example, currently teams are entirely free to use whatever Java version they want. If they want to update multiple times per year to the latest versions - entirely feasible for tight services with low technical debt and good tests - they can do so. As soon as the JVM becomes part of the OS configuration again through the Java driver, us as in infra-ops are immediately blocking all Java updates across the entire infrastructure again. And on top of that, we have a team providing base Java images with a jvm baked in, so most nomad workers pull the JVM layer once after it's released and then the layer is cached locally forever until no application needs it anymore. So it's not much more storage-expensive than putting the JVM on the disk directly. But that's the smaller part of the problem. Nomad isn't just the driver runtime. I can tell Nomad to run 5 instances of an application and to spread them across AWS regions, or VSphere HVs / Racks as well as possible. And Nomad will implement and maintain this, almost regardless of what the infrastructure does. I can drain workers and shift applications around without really knowing them, since this management is configured in the jobs. Again - this decoupling of OS and infrastructure management and application management makes a container orchestration valuable at a larger scale. The runtime below it is an important detail, but it's a detail for average REST service deployments. A WASM runtime may slot in as being faster and more cost efficient or it may not. Who knows.