Why are you building your applications to need specific kernels/distributions? That sort of goes against the spirit of 12-factor apps -- if a particular kernel/OS is part of the app, put it in the app. (Thus, use a full VM.) Docker is for when that isn't the case.

Well because for one it was tested and developed on one distribution. Because one might have chosen to use system level packaging instead of copying code to /var/local or /opt. So it is taking advantage of transactional updates to the system, transitive dependencies, pre-post install scripts. The downside it being tied to a packaging system.

Also certifications. Government agencies for example will accept only certain OS-es have been certified. Sometimes it is simply because there are features on some distribution or kernels that aren't in others.

Basically, what you're saying is, Docker sucks at being a foreign porting target for things developed for some other system. Well, everything sucks at being a foreign porting target. Don't do that. Test and develop your app using Docker. Install your app into the container using Docker. These are the things Docker is for--it's a development aid, not some performance-boosting alternative to virtualization. You have to integrate it into your app's workflow; you can't just tack it on as some final "and then we also generate a Docker container version of our app" step at the end, or you lose every advantage Docker gives you.

Docker is made to, basically, develop apps the same way you develop them when using a PaaS like Heroku (or, more specifically, a PaaS like Dotcloud): have a frozen base+runtime image; compose a "slug" consisting of exactly the stuff in your build/ directory and layer it on top; and tell the target host to launch it. To upgrade, create a new slug, and rolling-restart your old instances into new instances.

I think you misunderstood. I never said Docker sucks. I said there are ways to handle various kernel+distro combinations with Docker just by having various hosts that runs those kernel+distro combinations, that was in defense of LXC.

I haven't used Docker yet, I am only familiar with LXC so far so I was commenting on that. If one does have a uniform or a restricted set of platforms that can also act as LXC hosts then well why not take it and run with it. It is more efficient and that might translate into performance and cost savings.