It really depends on what you are trying to do with it, for example we have around 15 different integration test configurations that run every night for which VMs may better suited as we want to test installation and deployments automatically for 3 distributions (6 different versions ex. Ubuntu 14.04, ubuntu 16.04, centos 6, centos 7 etc..) and the last 2 windows server. The good thing is that they reproduce the customer environment.
But they have large down sides as well which slow us down. They are a pain to maintain as they are somewhat undocumented (you make a poc for 1 and management always wants more without improvments), a lot of edge cases cause issues which are tough to reproduce (locally sometimes impossible and waste a lot of time) and it takes them a while to start, run, etc.
This is not too tragic for nightly tests as we get the results in the morning but for tests which are started every hour, you do not want to wait that long to verify your changes work/didnt break anything. You can do these in stages, where you create different images based on the result of a previous job (run basic tests that cover base functionality that should always work, then run more in depth tests, then run performance tests at the end to ensure no significant degradation was introduced, etc..) and send out notifications asap in case of failure. The Dockerfile is essentially the documentation as you can see what is installed/configured. You can run everything locally just as it would in a k8 env. which for some reason every one always struggles with.
I am sure there are also edge cases with Docker that are a pain as well but the other selling points show it may be the right direction. You just havevto find use cases and evaluate them.
I'm not sure what that has to do with Singularity?
I know that the HPC clusters I've used in the past few years have all supported Singularity, but none have supported Docker (aside from our small lab cluster). Many HPC admins are (understandably) hesitant to allow non-admins access to start Docker containers (requiring root), but Singularity has no such user permission issues -- and it's faster than initializing a full VM to run a job. I don't expect that to change so long as starting a container requires root-effective permissions.
I suspect that many data scientists will be in a similar situation w.r.t HPC clusters (except for those that are using custom clouds like Seven Bridges).
Sorry for the mix up, I was replying to rb808's post using the HN app on my tablet, no idea what happened :(.
Regarding HPC, from what I remember they usually have old kernels which are running (2.6) for compatibility reasons where Docker usually is not supported (unless it is backported like in RHEL).
But they have large down sides as well which slow us down. They are a pain to maintain as they are somewhat undocumented (you make a poc for 1 and management always wants more without improvments), a lot of edge cases cause issues which are tough to reproduce (locally sometimes impossible and waste a lot of time) and it takes them a while to start, run, etc.
This is not too tragic for nightly tests as we get the results in the morning but for tests which are started every hour, you do not want to wait that long to verify your changes work/didnt break anything. You can do these in stages, where you create different images based on the result of a previous job (run basic tests that cover base functionality that should always work, then run more in depth tests, then run performance tests at the end to ensure no significant degradation was introduced, etc..) and send out notifications asap in case of failure. The Dockerfile is essentially the documentation as you can see what is installed/configured. You can run everything locally just as it would in a k8 env. which for some reason every one always struggles with.
I am sure there are also edge cases with Docker that are a pain as well but the other selling points show it may be the right direction. You just havevto find use cases and evaluate them.