In my world of bootstrapped, smaller apps looking for market traction, even if things go well, a few Linodes should be enough to handle most of the traffic I'll ever need to deal with, so this kind of thing is kind of foreign to me. I'm curious how people utilize it in practice.
In a nutshell, for me the value is in trivial repeatability. I can reproduce the entire build toolchain, test environment and produce artifacts all from a few KiB git repo which centres around the Dockerfile and submodules to dependencies.
Some of my ARM stuff takes hours to cross-compile and involves enormous amounts of fiddly babysitting normally. Dockerfiles have RUN statements (think lines a shell script) which are cached. My adjustments toward the end of a Dockerfile take only seconds to test and produces the exact same result as if it had really run each statement from the start, which doesn't sound like much but turns out (for me) to be pretty liberating compared to constantly trying to fight other automation where you have to dance around short-circuiting stuff to re-use bits of a past build to save time and get only a handful of "pristine" iterations in a day (that might differ to the iterations you rolled by hand).
There's two types of ARM builds, ones which can cross-compile and those that can't. The ones which can't cross-compile are done with qemu-binfmts and we chroot into an ARM filesystem and run the build there.
Perhaps the only useful contribution would be the fact that I persist the ccache up to the docker host with a shared ccache volume, and that helps enormously especially for the qemu-binfmts builds which can be quite slow.
For example, say I need libfoo, I have an amd64 host (being the docker container). Sometimes I just can't get the libfoo:armhf or libfoo-dev:armhf package installed because it would break/conflict with the amd64 host's version of it in some way. xapt often helps but then sometimes screws up by re-packaging something that has an "all" arch (non-arch-specific) to something armhf specific (eg. foo-data). This ultimately either conflicts with the host or fails to be named properly in such a way that it meets the build-deps of the project.
Sometimes I know it would be easier in some cases to avoid the debian packaging ecosystem, but for my workflow and distribution requirements it brings a lot of benefits.
Edit: see here https://wiki.debian.org/EmdebianToolchain
I've been running Dokku on DigitalOcean lately and it has been great (though I'm planning on eventually moving to Deis, now that DigitalOcean supports CoreOS).
https://github.com/progrium/dokku https://flynn.io http://deis.io
And if they don't, well having a fresh image that is easily rebuildable makes it easier for me to give demos than to spin fresh VMs. Arguably I could have done the same with Vagrant, but really didn't need the overhead of the VM.
But for using it in deployment, no.
For me, my VMs are actually dead simple and relatively homogeneous. Fresh install + lock down SSH + lock down iptables + install Git + install Docker.
Then I build from the correct Dockerfile and open whichever port(s) on the VM. Bang, instant node that does [whatever]. Time to upgrade the DB/mail server/app? Build from the new Dockerfile, stop the existing container, bring up the new one. No worrying about installing/uninstalling the correct dependencies on the VM and getting into an inconsistent state.
That's what Docker does for you.
Don't get me wrong, I think docker is great, but this whole "I get simple idempotent machines" is a solved problem. Docker excels at bundling applications with all their dependencies as an modern analogue to statically linking, or a Linux equivalent to OSX's .app
I think the point of Docker is that it decouples that "destroy a system and start a new one" from the VPS/cloud/server provider you're using; you can talk about "logical" systems as separate from whatever they're actually running on.
Personally, my use of NixOS means that I don't have the problem, so I don't need Docker. My systems get generated from scratch (logically speaking) whenever I upgrade without having to tear down the VM, and then some simple logic figures out which services to restart.
I find it's easier to make the OS part as simple as possible and use Docker for everything else since you can strictly enforce that your Dockerfile will always build the same way regardless of which OS you build it on.