Docker isn't a VM? In docker everything is native code. There is no emulation. It uses OS level sandboxing primitives to provide protection and isolation. Running an application in docker gives you the same performance profile as running it on the host because it is running it on the host. So if you write your job in C or Fortran you can beat any Java code on the JVM nearly everytime. Especially for linear algebra applications.

But in this use-case, you don't want to pick a VM; you want each task to specify a VM. A docker container is, effectively, an app that bakes in whatever VM it requires.

I can see the argument for managing workload definitions as an {app repo, VM descriptor} tuple—kind of like Heroku app definitions—rather than a single app+VM image blob. But when you're actually deploying them to run on machines, nothing beats baking everything into a reproducable static-binary-equivalent slug.

You don't need to let people run arbitrary docker images as workloads, but the ability to let people pick any VM—rather than just your preferred VM—while having this be just as safe and sandboxed, opens up a lot of flexibility.

(This is the same argument I give for Chromium's PNaCl, by the way: the advantage doesn't come from your ability to run one-off native apps in the browser; the true advantage is in <script>s that can specify exactly the interpreter engine—a PNaCl-binary VM—they need. Nobody seems to see eye-to-eye on this one, either.)