25 ms·

The Docker+WASM Technical Preview

201 points by soheilpro 4y ago

gigel82 4y ago
Insert "BUT WHY?" GIF here. Seriously, if you're in a position to be running native code in your environment why would you chose WASM? If you're building WASM for the web, is it really more expensive to build a pure native target out of the same source? Surely, performance wise you'll always be ahead going native.
- AlmostAnyone 4y ago
  The same reason you're using Docker itself
- nateabele 4y ago
  Put simply, more powerful isolation than Docker (with explicit, granular managed effects), and a simpler operating model, i.e. no container orchestration. You can actually compile modules from disparate stacks that call into one another in a single runtime.
  - javaunsafe2019 4y ago
    And for just that give up all the freedom docker runtimes give us? I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve. And I don’t understand why docker is supporting this as docker + wasm makes no sense at all as wasm wants to replace docker as the runtime provider …
    - nateabele 4y ago
      > And for just that give up all the freedom docker runtimes give us? Constraints give you freedom because they allow you to make guarantees. Checksums, reliable test suites, and good software abstractions are all examples. > I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve. Those are runtimes, not languages. Here's a list of languages that compile to WASM: https://www.fermyon.com/wasm-languages/webassembly-language-support https://www.fermyon.com/wasm-languages/webassembly-language-... IMO bash wouldn't make sense, but Java and Kotlin are there, as well as AssemblyScript, which is basically TypeScript.
      - javaunsafe2019 4y ago
        Oh, and I thought that they compile to native code and that therefore the kernel is the runtime …
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
- postalrat 4y ago
  So that your wasm images (or whatever they are called) can continue to run on whatever hardware cloud providers can build for as cheap as possible. Could be x86, arm, some native wasm hardware, who knows. As long as it's cheap.
mikesir87 4y ago
Michael Irwin from Docker here (and author of the blog post too). Happy to answer your questions, hear feedback, and more!
- petilon 4y ago
  What problem is this solving?
  - mikesir87 4y ago
    Depends on which "this" you're referring to. We (Docker) are trying to make it easier for developers to use the tools and capabilities they know and love to build, share, and run Wasm applications. As far as Wasm itself, it's designed to provide a fast, lightweight, secure, and portable binary format. While it was originally designed to help bring native code to the browser, it's quickly spreading to the server side. Many folks are using it for edge/IoT, but it's growing into other areas (saw demos today of even using it in databases as psuedo stored procedures). Happy to dive in more if you have more questions!
    - deleted 4y ago
      [deleted]
    - petilon 4y ago
      I didn't get anything from that. My question was not about WASM but Docker+WASM project. Why problem does it solve?
      - synergy20 4y ago
        the only thing I see is that after wrapping wasm inside a docker you can leverage all those docker tools(k8n,etc)? the docker solves portability and scalability issues with a reasonable overhead, so wasm hides inside docker can benefit from some?
      - saidinesh5 4y ago
        Easy orchestration and deployment is the only thing I can think of. Because of docker's infrastructure. But tbh if orchestration is really the concern, Docker + wasm seems less efficient than having a dedicated app that can orchestrate multiple wasm modules within the same process. But maybe that's something docker can solve later as the actual requirements emerge.
tester756 4y ago
Great work, WASM is the future! But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like that and it doesn't seem like we're getting close
- k__ 4y ago
  They just want to protect the frontend from the C#/Java crowd.
  - tester756 4y ago
    No chance, we're already compiling those to our wasm-based frontend apps
    - throwaway290 4y ago
      You can run Java in the browser now but at least you can't touch DOM...
- skohan 4y ago
  What compromises does WASM have relative to plain old native code?
  - mikesir87 4y ago
    There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too). There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries. But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!
nateabele 4y ago
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.)
- VikingCoder 4y ago
  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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- matai_kolila 4y ago
  > 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.
- timanglade 4y ago
  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 4y ago
    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 https://github.com/vmware-labs/mod_wasm
maxmcd 4y ago
Nice. I'm excited because there are lots of different ways to run WASM on a server, different ABIs, different runtimes, etc etc. A big move like this might make it easier to standardize around some kind of server-side WASM happy path and also provide pressure to move some of the Wasi feature work along faster.
deleted 4y ago
[deleted]
nuc1e0n 4y ago
Very nice. More lightweight virtualisation is a thing to celebrate :)
syrusakbary 4y ago
This is great. We’ve been chatting with Docker for a little bit (I’m Syrus, from Wasmer) and it’s great to see that they are making progress on improving the developer experience around WebAssembly. However, I see Docker (and thus, Kubernetes) is as technologies of the past (I don’t intend to start any flamewar, I really believe this by heart). Metal compute (Web 1.0) lead to VMs which then lead to Containers (Web 2.0 / Cloud) and now we are seeing what the next wave will look like thanks to WebAssembly. Of course, there’s ton of profit that has been generated thanks to the added complexity of current technologies and abstractions. We have now the opportunity to rethink what the future will look like. Long live Wasm
- afiori 4y ago
  If the containers become old tech and docker poses itself as the new "wasm delivery and registry platform" it is a net win for them. The only risk is if splitting the effort damages them in both fields...
- tevlon 4y ago
  Solomon Hykes, the father of Docker agrees: https://twitter.com/solomonstre/status/1111004913222324225?s=20&t=hpPmqRbqkHWWtJRSsAIgdQ https://twitter.com/solomonstre/status/1111004913222324225?s... the tweet is from 2019
  - samkon 4y ago
    Don’t forget this tweet from a day earlier, which he quotes: > “So will wasm replace Docker?” No, but imagine a future where Docker runs linux containers, windows containers and wasm containers side by side. Over time wasm might become the most popular container type. Docker will love them all equally, and run it all :)
- _mme 4y ago
  I don't know Syrus nor Wasmer :) However, I'm genuinely interested - why would this make Kubernetes obsolete? If Wasm rules the future, as you believe, why shouldn't it run in a pod?
pjmlp 4y ago
Mainframe and microcomputer language environments welcome the new kid on the block.
lolinder 4y ago
Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?
- theplumber 4y ago
  I guess it's a wasm runtime. Basically a way to execute a wasm binary just like you use docker to execute a x64 binary
  - stoplying1 4y ago
    Except that would've been too easy to understand, and instead seems like they're using wasmedge anyway. Needlessly confusing, why do companies do this?
    - theplumber 4y ago
      A reason could be standardised build/deployment/testing.
- deleted 4y ago
  [deleted]
- timanglade 4y ago
  "Docker+Wasm" is just a shorthand for the Technical Preview build, which allows you to build both traditional container apps, as well as Wasm apps. Behind the scenes, we try to let Wasm apps be developed largely without interference from any container technology — just giving you a good local environment you can use to code against. That said, if you want, we do offer the ability to run Wasm apps within a Docker Compose application. We do also offer the possibility to package Wasm apps within an OCI image, with an embedded Wasm runtime (WasmEdge) so you can a) easily share these via an image registry like Docker Hub, AWS ECR, etc. and b) easily run this anywhere you’d run a container. That said it’s not mandatory, and if you want the benefits of (a) without the benefits of (b) you can easily unpack the image to just get the Wasm payload and run that however you want. We dove into the details of the approach at Kubecon today, and the video should be coming out shortly.
AkshatJ27 4y ago
For some reason I thought this was gonna be a demo of running docker in your browser through WASM. kinda disappointed that's not it :p
- syrusakbary 4y ago
  Funnily enough, I believe that's completely achievable with enough time spent on it (probably a few weeks of an engineer working full time). We have technology like WebVM [1] (from leaningtech / CheerP) or Copy86 [2] that already allows x86 machine code execution/emulation on the web. If you add an OCI client layer on top that is executable in the browser, it should be possible to run Docker containers in the browser. [1] https://webvm.io/ https://webvm.io/ [2] https://copy.sh/v86/ https://copy.sh/v86/
  - piersj225 4y ago
    Sorry I can't reset my docker password to double check, but I think something like this exists [1]. I'm not sure what its limits are, but its a great tool for learning. [1] https://labs.play-with-docker.com/ https://labs.play-with-docker.com/
    - syrusakbary 4y ago
      I just played with it and it doesn't execute the container in the browser. It executes it remotely and proxies the stdin/stdout and such from/to the browser (the browser is just a client instead of a runner)
- dwaite 4y ago
  I think the biggest challenge here is getting the resources through the browser - e.g. enough memory to run a decent container, or the ability to open a listening port.
s17n 4y ago
As a rule of thumb, when a company is writing blog posts about how "they see" X as a "complementary technology" to their technology... they are in trouble.
ThinkBeat 4y ago
oh good two buzzwords slammed together. I read that press release or whatever a couple of times and I still can't figure out what the point is. When I first saw it I was hoping that it would free Docker from the chains of VMs. (On Windows and Mac) If images target WASM then you should be able to run on them on any platform supporting WASM right? I dont think that is what it does.
jiggawatts 4y ago
This prescient talk "The Birth & Death of JavaScript" by Gary Bernhardt in 2014 is slowly but surely coming true: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- heavyset_go 4y ago
  I'd love to see this future, but I wonder if a WASM VM can match the performance of something like V8 that is fine-tuned to run a single language well.
  - corysama 4y ago
    That’s pretty much the point of WASM, isn’t it? V8 is a billion dollar investment in running as best as possible a language that is very, very difficult to run performantly. WASM instead opens up options to run well languages that are much easier to run performantly.
    - heavyset_go 4y ago
      Definitely it is, and it does open doors for this, I'm just curious if running say, a JavaScript or Python interpreter on top of WASM would be more performant than V8, given that there could be two layers of VMs, ie the WASM VM and the JS/Python VM running on it. I'd hope that they'd be comparable in performance, especially when it comes to doing client-side web app things in languages other than JavaScript.
      - corysama 4y ago
        That wouldn’t work out. The C Python interpreter is slower than v8. A WASM Python interpreter would be at most as fast as the native C implementation
      - afiori 4y ago
        Currently JIT in wasm is incomplete. That is a wasm program cannot modify itself (it would need to create new modules and ask the host to load them with a shared memory) So compiling JS to wasm would probably be limited to the performance of interpreting JS on native
marmada 4y ago
How does this work with things like WASI--back when I did WASM things I recalled that WASM relies on imported functions for things like Io, etc. so what functions is the Docker runtime providing here?
- galangalalgol 4y ago
  I am very confused about how wasi calls work in something like wasmer or wasmtime vs a browser. My guess is the former expose a runtime directly to the wasm executable, and in the browser this has to be done via autogenerated js bindings?
theanonymousone 4y ago
Continuing the thread of "not getting it", I try to make an analogy to the fictional "Docker+JVM" to get a better idea. Is such an analogy logical?
theanonymousone 4y ago
"Docker+WASM" would be waaay more exciting to me if it was about compiling Docker to WASM bytecode and running it in the browser.
code_runner 4y ago
My first thought was “what would docker have to do with the client side”… I didn’t realize wasm was running server side these days and apparently with some success? I wouldn’t have considered running my Java or python on wasm because it’s all server side… that’s just what it does… but the single execution environment with sandboxing is very interesting. I definitely need a wasm crash course
dravigon 4y ago
I for one love this now this reduces attack area by making my app as run time plus i get to integrate it with existing tooling like kubernetes and my app can scale. It is a win win
Havoc 4y ago
What language is everyone using in Wasm? I’m tempted to go rust route but that may be a little too low level for wasm in the web context. So maybe go?
pjmlp 4y ago
It looks like EAR files just got re-invented.

201 points by soheilpro 4y ago

Insert "BUT WHY?" GIF here. Seriously, if you're in a position to be running native code in your environment why would you chose WASM? If you're building WASM for the web, is it really more expensive to build a pure native target out of the same source? Surely, performance wise you'll always be ahead going native.

AlmostAnyone 4y ago
The same reason you're using Docker itself
nateabele 4y ago
Put simply, more powerful isolation than Docker (with explicit, granular managed effects), and a simpler operating model, i.e. no container orchestration. You can actually compile modules from disparate stacks that call into one another in a single runtime.
- javaunsafe2019 4y ago
  And for just that give up all the freedom docker runtimes give us? I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve. And I don’t understand why docker is supporting this as docker + wasm makes no sense at all as wasm wants to replace docker as the runtime provider …
  - nateabele 4y ago
    > And for just that give up all the freedom docker runtimes give us? Constraints give you freedom because they allow you to make guarantees. Checksums, reliable test suites, and good software abstractions are all examples. > I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve. Those are runtimes, not languages. Here's a list of languages that compile to WASM: https://www.fermyon.com/wasm-languages/webassembly-language-support https://www.fermyon.com/wasm-languages/webassembly-language-... IMO bash wouldn't make sense, but Java and Kotlin are there, as well as AssemblyScript, which is basically TypeScript.
    - javaunsafe2019 4y ago
      Oh, and I thought that they compile to native code and that therefore the kernel is the runtime …
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
postalrat 4y ago
So that your wasm images (or whatever they are called) can continue to run on whatever hardware cloud providers can build for as cheap as possible. Could be x86, arm, some native wasm hardware, who knows. As long as it's cheap.

mikesir87 4y ago

Michael Irwin from Docker here (and author of the blog post too). Happy to answer your questions, hear feedback, and more!

petilon 4y ago
What problem is this solving?
- mikesir87 4y ago
  Depends on which "this" you're referring to. We (Docker) are trying to make it easier for developers to use the tools and capabilities they know and love to build, share, and run Wasm applications. As far as Wasm itself, it's designed to provide a fast, lightweight, secure, and portable binary format. While it was originally designed to help bring native code to the browser, it's quickly spreading to the server side. Many folks are using it for edge/IoT, but it's growing into other areas (saw demos today of even using it in databases as psuedo stored procedures). Happy to dive in more if you have more questions!
  - deleted 4y ago
    [deleted]
  - petilon 4y ago
    I didn't get anything from that. My question was not about WASM but Docker+WASM project. Why problem does it solve?
    - synergy20 4y ago
      the only thing I see is that after wrapping wasm inside a docker you can leverage all those docker tools(k8n,etc)? the docker solves portability and scalability issues with a reasonable overhead, so wasm hides inside docker can benefit from some?
    - saidinesh5 4y ago
      Easy orchestration and deployment is the only thing I can think of. Because of docker's infrastructure. But tbh if orchestration is really the concern, Docker + wasm seems less efficient than having a dedicated app that can orchestrate multiple wasm modules within the same process. But maybe that's something docker can solve later as the actual requirements emerge.

tester756 4y ago

Great work, WASM is the future! But on the other hand I'm not really happy with the fact that I'm waiting for GC and DOM access since 2019 or something like that and it doesn't seem like we're getting close

k__ 4y ago
They just want to protect the frontend from the C#/Java crowd.
- tester756 4y ago
  No chance, we're already compiling those to our wasm-based frontend apps
  - throwaway290 4y ago
    You can run Java in the browser now but at least you can't touch DOM...
skohan 4y ago
What compromises does WASM have relative to plain old native code?
- mikesir87 4y ago
  There are a few things we're excited about, many of which we fully recognize are used in marketing/buzzword bingo. But, they really are around portability (compile to a Wasm module and run on any architecture), isolated sandboxing (leveraging much of the research and investment used to protect web browsers), and super fast startups (obviously depends on the app too). There are a few limitations right now, some of which lack of built-in garbage collection and multi-threading. You also have to use a language that can completely compile to Wasm, making it hard (sometimes impossible) to leverage already built libraries/binaries. But... the tech is growing rapidly and we're excited for it! Happy to dive in or answer more questions if you'd like!

nateabele 4y ago

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.)

VikingCoder 4y ago
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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
matai_kolila 4y ago
> 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.
timanglade 4y ago
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 4y ago
  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 https://github.com/vmware-labs/mod_wasm

maxmcd 4y ago

Nice. I'm excited because there are lots of different ways to run WASM on a server, different ABIs, different runtimes, etc etc. A big move like this might make it easier to standardize around some kind of server-side WASM happy path and also provide pressure to move some of the Wasi feature work along faster.

deleted 4y ago

[deleted]

nuc1e0n 4y ago

Very nice. More lightweight virtualisation is a thing to celebrate :)

syrusakbary 4y ago

This is great. We’ve been chatting with Docker for a little bit (I’m Syrus, from Wasmer) and it’s great to see that they are making progress on improving the developer experience around WebAssembly. However, I see Docker (and thus, Kubernetes) is as technologies of the past (I don’t intend to start any flamewar, I really believe this by heart). Metal compute (Web 1.0) lead to VMs which then lead to Containers (Web 2.0 / Cloud) and now we are seeing what the next wave will look like thanks to WebAssembly. Of course, there’s ton of profit that has been generated thanks to the added complexity of current technologies and abstractions. We have now the opportunity to rethink what the future will look like. Long live Wasm

afiori 4y ago
If the containers become old tech and docker poses itself as the new "wasm delivery and registry platform" it is a net win for them. The only risk is if splitting the effort damages them in both fields...
tevlon 4y ago
Solomon Hykes, the father of Docker agrees: https://twitter.com/solomonstre/status/1111004913222324225?s=20&t=hpPmqRbqkHWWtJRSsAIgdQ https://twitter.com/solomonstre/status/1111004913222324225?s... the tweet is from 2019
- samkon 4y ago
  Don’t forget this tweet from a day earlier, which he quotes: > “So will wasm replace Docker?” No, but imagine a future where Docker runs linux containers, windows containers and wasm containers side by side. Over time wasm might become the most popular container type. Docker will love them all equally, and run it all :)
_mme 4y ago
I don't know Syrus nor Wasmer :) However, I'm genuinely interested - why would this make Kubernetes obsolete? If Wasm rules the future, as you believe, why shouldn't it run in a pod?

pjmlp 4y ago

Mainframe and microcomputer language environments welcome the new kid on the block.

lolinder 4y ago

Does anyone have a good explanation for what Docker+WASM actually is? This announcement explains what WASM is and what Docker is, but I already knew both of those and am still confused about what Docker+WASM is. Is it just wrapping a WASM binary in a Docker container?

theplumber 4y ago
I guess it's a wasm runtime. Basically a way to execute a wasm binary just like you use docker to execute a x64 binary
- stoplying1 4y ago
  Except that would've been too easy to understand, and instead seems like they're using wasmedge anyway. Needlessly confusing, why do companies do this?
  - theplumber 4y ago
    A reason could be standardised build/deployment/testing.
deleted 4y ago
[deleted]
timanglade 4y ago
"Docker+Wasm" is just a shorthand for the Technical Preview build, which allows you to build both traditional container apps, as well as Wasm apps. Behind the scenes, we try to let Wasm apps be developed largely without interference from any container technology — just giving you a good local environment you can use to code against. That said, if you want, we do offer the ability to run Wasm apps within a Docker Compose application. We do also offer the possibility to package Wasm apps within an OCI image, with an embedded Wasm runtime (WasmEdge) so you can a) easily share these via an image registry like Docker Hub, AWS ECR, etc. and b) easily run this anywhere you’d run a container. That said it’s not mandatory, and if you want the benefits of (a) without the benefits of (b) you can easily unpack the image to just get the Wasm payload and run that however you want. We dove into the details of the approach at Kubecon today, and the video should be coming out shortly.

AkshatJ27 4y ago

For some reason I thought this was gonna be a demo of running docker in your browser through WASM. kinda disappointed that's not it :p

syrusakbary 4y ago
Funnily enough, I believe that's completely achievable with enough time spent on it (probably a few weeks of an engineer working full time). We have technology like WebVM [1] (from leaningtech / CheerP) or Copy86 [2] that already allows x86 machine code execution/emulation on the web. If you add an OCI client layer on top that is executable in the browser, it should be possible to run Docker containers in the browser. [1] https://webvm.io/ https://webvm.io/ [2] https://copy.sh/v86/ https://copy.sh/v86/
- piersj225 4y ago
  Sorry I can't reset my docker password to double check, but I think something like this exists [1]. I'm not sure what its limits are, but its a great tool for learning. [1] https://labs.play-with-docker.com/ https://labs.play-with-docker.com/
  - syrusakbary 4y ago
    I just played with it and it doesn't execute the container in the browser. It executes it remotely and proxies the stdin/stdout and such from/to the browser (the browser is just a client instead of a runner)
dwaite 4y ago
I think the biggest challenge here is getting the resources through the browser - e.g. enough memory to run a decent container, or the ability to open a listening port.

s17n 4y ago

As a rule of thumb, when a company is writing blog posts about how "they see" X as a "complementary technology" to their technology... they are in trouble.

ThinkBeat 4y ago

oh good two buzzwords slammed together. I read that press release or whatever a couple of times and I still can't figure out what the point is. When I first saw it I was hoping that it would free Docker from the chains of VMs. (On Windows and Mac) If images target WASM then you should be able to run on them on any platform supporting WASM right? I dont think that is what it does.

jiggawatts 4y ago

This prescient talk "The Birth & Death of JavaScript" by Gary Bernhardt in 2014 is slowly but surely coming true: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

heavyset_go 4y ago
I'd love to see this future, but I wonder if a WASM VM can match the performance of something like V8 that is fine-tuned to run a single language well.
- corysama 4y ago
  That’s pretty much the point of WASM, isn’t it? V8 is a billion dollar investment in running as best as possible a language that is very, very difficult to run performantly. WASM instead opens up options to run well languages that are much easier to run performantly.
  - heavyset_go 4y ago
    Definitely it is, and it does open doors for this, I'm just curious if running say, a JavaScript or Python interpreter on top of WASM would be more performant than V8, given that there could be two layers of VMs, ie the WASM VM and the JS/Python VM running on it. I'd hope that they'd be comparable in performance, especially when it comes to doing client-side web app things in languages other than JavaScript.
    - corysama 4y ago
      That wouldn’t work out. The C Python interpreter is slower than v8. A WASM Python interpreter would be at most as fast as the native C implementation
    - afiori 4y ago
      Currently JIT in wasm is incomplete. That is a wasm program cannot modify itself (it would need to create new modules and ask the host to load them with a shared memory) So compiling JS to wasm would probably be limited to the performance of interpreting JS on native

marmada 4y ago

How does this work with things like WASI--back when I did WASM things I recalled that WASM relies on imported functions for things like Io, etc. so what functions is the Docker runtime providing here?

galangalalgol 4y ago
I am very confused about how wasi calls work in something like wasmer or wasmtime vs a browser. My guess is the former expose a runtime directly to the wasm executable, and in the browser this has to be done via autogenerated js bindings?

theanonymousone 4y ago

Continuing the thread of "not getting it", I try to make an analogy to the fictional "Docker+JVM" to get a better idea. Is such an analogy logical?

theanonymousone 4y ago

"Docker+WASM" would be waaay more exciting to me if it was about compiling Docker to WASM bytecode and running it in the browser.

code_runner 4y ago

My first thought was “what would docker have to do with the client side”… I didn’t realize wasm was running server side these days and apparently with some success? I wouldn’t have considered running my Java or python on wasm because it’s all server side… that’s just what it does… but the single execution environment with sandboxing is very interesting. I definitely need a wasm crash course

dravigon 4y ago

I for one love this now this reduces attack area by making my app as run time plus i get to integrate it with existing tooling like kubernetes and my app can scale. It is a win win

Havoc 4y ago

What language is everyone using in Wasm? I’m tempted to go rust route but that may be a little too low level for wasm in the web context. So maybe go?

pjmlp 4y ago

It looks like EAR files just got re-invented.