Ask HN: If money's not a problem, why Docker over Heroku?

The team at circleci actually wrote some great blog posts about this. First, a tongue-in-cheek post highlighting the question you're asking here:

http://blog.circleci.com/its-the-future/

Followed by a post answering this question:

http://blog.circleci.com/it-really-is-the-future/

I know you are saying, "let's say" they are mutually exclusive, but I would highlight that they are not just _not mutually exclusive_, there is actually an open-source PaaS that is built on top of Docker (CoreOS, Fleet) to be as close as possible to Heroku-compatible. http://deis.io

And, it's not really a given that it's cheaper to use Docker. Scaling costs more, however you do it. If your project is short-lived, then the up-front hardware costs of building a cluster out of bare metal might just eclipse the aggregate amount you would spend on Heroku in that span.

Even buying the machines an hour at a time from AWS, building a cluster out of them and configuring the load balancing through ELB, without counting the time you'd spend on all that, might not really save you any money unless you are actually using a whole lot of dynos.

For the sake of argument, putting all of that aside, do you want a platform that just works, and you just pay the bill, or do you want to know how it works and have some direct control over actual downtime, upgrades, etc?

It's not really fair comparing Heroku to Docker. One is a platform/service provider, the other is a piece of software (not even a full platform stack.)

One is an open source platform, the other is a commercial entity. The worst thing you can do is to complete depend everything on a product by a company. If they decide to kick you out, you can't switch over to something else easily.

Heroku is a PaaS offering that offers its key value in that it provides a simple environment that caters to a lot of workloads. The way it does this is make many decisions for you. If your workload don't suit those decisions they may be sub-optimal. However the value is that your given limited sizing options, rather then having to decide amongst the millions of configuration options you would have with AWS or dedicated hosting. However you follow the Heroku documentation properly and you should be able to have a fairly performant solution.

Docker is containerisation. It allows you to run many containers on a single server. It can be configured in millions of ways, and part of a much larger stack. All it does is handles a small number of problems associated with running multiple applications on a single server (and the surrounding problem space). You can use whatever programming language / database / messaging stack / middleware / web server / etc you like, with the caveat that you need to either build the configuration (or use someones pre-configured image).

So the answer to your question really is why would someone need more flexibility then heroku offers, in which I can think of :

1.) Hosting outside of EU / US. Heroku does not have APAC / South America / African hosting at least according to documentation. https://devcenter.heroku.com/articles/regions

2.) Use of technology component not provided by Heroku. (Programming Language / Database / etc)

3.) Add-ons may not be suitable to provide key technology. (I really am uncomfortable with a Database being far away from application code, so a Database as a service makes me nervous, like Heroku Add ons). Heroku only provide Postgres and Redis.

4.) Each Application is a separate Heroku line item. A docker configuration could host thousands of rarely accessed applications. Outside of storage there is little resource costs for a rarely-used application.

5.) Ability to move. A docker container can be moved to anywhere. You want to host on Azure, you can. Rackspace offering something cheap, go there. AWS, your good. Get acquired and need to run in a corp VMWare environment... your good. Heroku apps tend to get tied into the platform as you deal with herokuisms and work around that environment. While the application can be moved, if your application is significant you will spend time re-ballancing.

They don't have to be mutually exclusive.

Cloud Foundry gives you an installable PaaS that has pathways for accepting either sourcecode or, in current betas, Docker containers.

You can run it inhouse on OpenStack or vSphere, or you can mount it on AWS.

See: http://docs.cloudfoundry.org/

And for the Docker-only dev sandbox: http://lattice.cf/

Heroku has a history of making technical changes that are actually worse performance-wise and reliability-wise. One of the more notable ones was the switch from an "intelligent" request routing mechanism (Heroku's routing mesh would route requests to dynos based on their load) to a random load-balancing scheme (blind, with no regard for existing dyno load), causing requests to frequently be routed to overworked dynos while leaving open ones idling and twiddling their virtual thumbs. This change was eventually called out and documented by the folks at Rap Genius [0]; Heroku eventually responded, though I don't know off the top of my head whether they went back to their previous (and arguably much-superior) routing system.

This, combined with the rather abysmal tooling (and, of course, the rather abysmal pricing) around Heroku, left a bad enough taste in my mouth to avoid Heroku for most (if not all) of my personal projects, the sole exception at the moment being heroku-sucks.herokuapp.com. My current dayjob employer (a Rails consultancy) has switched away from Heroku entirely, moving instead to Cloud66 (we haven't gone the container route yet, but we're actively working on it).

[0]: http://genius.com/James-somers-herokus-ugly-secret-annotated