[nateabele]

Apologies in advance for a bit of a rant, but I sincerely hope the tools growing up around WASM significantly diminish the need for Docker. As an industry, we're so bad at isolation that we have to put a computer (container) inside a computer (VM) inside a computer (hardware) just to achieve any sort of sane guarantees.

Then we immediately trade any semblance of sanity for container orchestration.

(And please don't try to convince me that Kubernetes is sane. I operated a production SaaS on it for 4 years, and spent another year at a DevSecOps consultancy with 40+ CKAs—sanity and familiarity are not the same.)

[timanglade]

Broadly, we agree. The goal of this Technical Preview is not to encourage Wasm to be mediated by containers in production, but rather to enable people to locally build & package Wasm apps easily. In production, that could look like a number of different scenarios, from "bare metal" edge (just running in a Wasm VM), to running your Wasm workloads in a nomad/k8s cluster if that’s what you need (e.g. if you want hybrid container/wasm orchestration).

[nateabele]

Hey Tim, I appreciate your willingness to engage. What I'm getting at is a bit more pointed. In terms of composability, Docker and WASM are opposites: Docker requires a stand-alone runtime, and an orchestration layer, etc., whereas a WASM module & runtime can be embedded directly into my application, into a browser, or into (comparatively) simple, time-tested tools like Apache[0].

So, to your point, the opportunity here is to provide WASM-native alternatives to existing container-specific technologies, that are more composable by design, because they don't have to deal with the complexity of trying to ape an extra operating system just to run some software.

For example, I'd love to see container orchestration be supplanted by something like a la carte Erlang-style service discovery—that's a primitive that could easily be composed with other primitives, and wouldn't result in the combinatorial explosion of nouns we see in systems like k8s / Swarm / others.

[0] https://github.com/vmware-labs/mod_wasm

[timanglade]

No disagreement here! Just to contextualize: Docker — the company as it exists today — is singularly focused on the development experience, i.e. the inner loop of code/test/build, not the outer loop of deploying to production (which is largely controlled by cloud platforms and k8s at this point). I know that separation can seem arbitrary, considering containers are largely successful because they help bridge the two, but that’s just the reality of what we’re focused on in our daily jobs @ Docker.

Within that framework, we see Wasm as extremely compatible with our goals of improving the local development experience, and yes, giving people alternatives to container-centric approaches. I’m personally inclined to agree with the points you are making about opportunities in orchestration, but we’re starting today by just trying to give people to a solid toolset that lets you iterate on your Wasm apps locally, and easily export the resulting artifacts, so you can deploy them as you see fit. In the process we try to be careful about shedding any container-centric assumptions, while porting over some of the wins of the docker tooling that we think can translate well to Wasm (easy local dev environment, standard artifacts, broad platform compatibility across Windows/Linux/M1, etc.) We will happily work with anyone interested in working with us to improve the production/deployment landscape for Wasm, and in fact I would say the main reason that drove us to launch this technical preview today, was to attract feedback on how the Wasm community (ourselves included) could best deliver an alternative path to production for applications going forward.

Hope this makes sense and that I understood your point accurately!

[nateabele]

> Hope this makes sense and that I understood your point accurately!

I'm happy to hear all of that and, yes, I believe you did.

> Docker [...] is singularly focused on the development experience, i.e. the inner loop of code/test/build, not the outer loop of deploying to production (which is largely controlled by cloud platforms and k8s at this point).

I would push back on this a bit: although it may not be a focus, and that's totally fair, deployment is undeniably part of the developer experience, particularly within the context that containers were born into (i.e. DevOps values of continuous deployment & no silos). I certainly wouldn't presume to tell you what to do, but I would suggest that Docker is uniquely situated to address developer experience from end to end.

> We will happily work with anyone interested in working with us to improve the production/deployment landscape for Wasm

If you gave us a path out of containers for the end-to-end developer experience, I believe many of us would be eternally grateful. Let me know how I can help.

[VikingCoder]

Time to watch "The Birth & Death of JavaScript" again.

I don't remember exactly when he says it's time to get rid of containers and VMs, but it's in there...

https://www.destroyallsoftware.com/talks/the-birth-and-death...

[rglover]

> As an industry, we're so bad at isolation that we have to put a computer (container) inside a computer (VM) inside a computer (hardware) just to achieve any sort of sane guarantees.

We don't. But shortsighted design, rushing, and herd mentality around "hyped" tech make it a virtual certainty more like this will exist, just in different shapes and sizes.

You can run most stuff on a baremetal box or VM w/ direct install of dependencies. All of this container stuff, sorry to say, is a grift save for some extreme multi-tenant use cases.

[matai_kolila]

> sanity and familiarity are not the same

I know this wasn't your main point, but if I could reasonably tattoo this onto my forehead I would.