I started to use Dokku, got it installed and my app deployed, then realized that it only supported one app. Such a strange design decision for a virtualization platform. It really drove home to me how unfinished these new PaaS solutions are. We're still another five years or so from "the Rails of PaaSes".
I'm going to double down on 12 factor. The kind of encapsulation involved, storing the app in code, config in the environment, data in persisted resources, is ten times better than virtualization.
Allow me to apologize if I sound blunt, but I think you missed the point of Dokku. It is a, what, 100 lines shell script? It supports a single app, but you can run it multiple times. The same way that Heroku supports a single app per git repository. It's a kind of design decision, and not a limitation per se.
Dokku is a demonstration of what you can achieve with Docker + a very little shell script. In my humble opinion, it's very promising that you can achieve so much (something that lets you deploy applications in a Heroku-compatible way) with so little.
Also, 12-factor is totally orthogonal: you (not you specifically, but the general developer) should use 12-factor as much as possible (because most of it can be considered as "best practice", I think), then you can deploy on IAAS, PAAS, your own machines, etc.; and using 12-factor just makes the whole process easier.
That's an odd statement. Isn't 12-factor a requirement for Docker apps? It's not like you're "stopping and forking containers" in production; that's just a convenience for development. The image you deploy to production is supposed to be a sealed "slug" with an ephemeral container on top, like on Heroku.
With a 12 factor app, you don't need virtualization. The entire app is stateless, all state is pushed off to various resources. All you have to do is pull the repo and run the service.
12 factor is not a requirement for Docker. You're perfectly free to violate 12 factor by storing state in the file system, config in your code. Heroku makes you implement quite a bit of 12 factor through their ephemeral filesystem, but it cannot enforce following of the entire spec.
Virtualization, in my opinion, has become a crutch we lean on to avoid having to restructure apps. If you need, say, a cron job, instead of doing it the 12 factor way and using beanstalkd, you'll just run cron on your container. (not sure if that's possible but you get the idea)
Virtualization and 12 factor aren't quite orthogonal, they do overlap a bit. The former is an 'easy' solution, you just build your app however you like and as long as it will run in a container, you're fine. The latter is much harder, you have to make your app totally stateless.
I've never seen Docker/LXC as a "virtualization" solution; it's an isolation tool, to firewall off exploited services from their siblings and hosts (which then allows things like PaaS multitenancy.) Used in that sense--where anything that breaks isolation (like host-mounted volumes) is disallowed--Docker does indeed require 12-factor-structured apps, to do anything of use.
I'm going to double down on 12 factor. The kind of encapsulation involved, storing the app in code, config in the environment, data in persisted resources, is ten times better than virtualization.