|
|
|
|
|
|
by pmontra
1331 days ago
|
|
|
So docker+WASM does not build a Linux container image with the WASM application inside but it builds a WASM application packaged as a docker image and started with docker run instead of (say) an ELF or Windows or Mac binary started with the OS exec, whatever it is? If this is the case I'd leave docker outside the name of the technology. I imagine the confusion. At least one customer of mine doesn't fully get the difference between a docker image and a VM yet, after years they are using docker in production. |
|
|
With this preview, we are leveraging the OCI specification that defines how to build an image. Linux/Windows containers are the most common use of this specification, but many other types of artifacts exist (OPA policies, Helm charts, etc.).
When using any of these other artifact types, tooling has to know how to use that specific artifact type and run it (eg, extract the image and run it as a container or extract the Helm chart and deploy it). In our Wasm use case, we are doing the same thing... package and ship a Wasm module and we'll extract it and run it on the new Wasm runtime. That runtime then "converts" the Wasm module into native machine code for the OS you're running on.
> If this is the case I'd leave docker outside the name of the technology. I imagine the confusion.
That's great feedback! While most know us as "the container company", our mission doesn't even talk about containers. We want to help all developers succeed by reducing app complexity. We can certainly do more to help educate folks between the different types of workloads you might be running. We're still very early on in this process, so stay tuned (and keep the feedback coming)!