Hacker News Reader

Comment by derefr | Hacker News Reader

It surely is exciting, but I do wish more people would throw in with the Docker-based PaaSes that already have some momentum (Dokku, Flynn, etc.), rather than making their own. I mean, I guess the required glue left over is about on the level of a static site generator, which explains why everyone thinks doing one as a weekend project will be great fun--but just like a static site generator, one weekend (or even one fulltime developer) isn't gonna make something I'm willing to build projects for clients on top of. Which is something I really, really want to do.

So let's pick a project to be "the Rails of PaaSes" soon, okay? I neeeed one. :)

View on HN

Does Flynn actually have any momentum yet? From what I can see they reached their funding goal then dropped under the radar, I even popped by their IRC channel to see if anything was active there but found it to be partially infested with tumbleweeds.

Not bashing it or anything I'm just interested in its progress but can't find anything!

Others will correct me if I'm wrong, but Deis particularly makes sense, since Dokku has a more restricted scope, and Flynn isn't out yet.

Also, the required glue is a bit more complicated than you think, especially when you want to be able to scale and/or deploy on multiple servers. You need to store some extra info somewhere (at least in a database, at best in a distributed one like zookeeper, doozer, or etcd). Then things get exciting :-)

Gabriel Monroy, creator of the Deis project here..

> I do wish more people would throw in with the Docker-based PaaSes that already have some momentum (Dokku, Flynn, etc.), rather than making their own.

We at OpDemand have been working on Deis (and its proprietary predecessor) long before Dokku, Flynn or even Docker existed. Also as jpetazzo mentioned, Dokku is not really a PaaS but rather a single server Heroku-style deployment system. Flynn is still in planning stages AFAIK.

> I guess the required glue left over is about on the level of a static site generator, which explains why everyone thinks doing one as a weekend project will be great fun

Are you equating Deis/Flynn with a static site generator? If so, you're dramatically underestimating the amount of work required to build a distributed PaaS that can support production applications. The difference in LOE between Dokku and Deis/Flynn is exponential.

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.

I did miss the point of Dokku. Unfortunately, I didn't realize that until after I'd already burned 3 hours on it.

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.

Reply on news.ycombinator.com