
How We Moved from Heroku to Containers with No Docker Experience - sergiotapia
http://stackshare.io/proleads/how-we-moved-from-heroku-to-containers-with-no-docker-experience
======
wrs
If you're only containerizing a Ruby application and nginx, I don't really see
how containers are much better than old school Capistrano-style rsync
deployment. (How often does your nginx version change, after all?) At the cost
of an awful lot of additional tooling and somewhat unstable infrastructure.

For our simple Ruby workers, we just use Puppet to set up app server VMs with
Ruby and nginx. Deployment consists of updating the Ruby code directory. It's
pretty much cloud provider independent, as long as your provider can make a
Linux VM, and it works fine, just like it did in 2010. :)

~~~
tra3
I find this attitude interesting. By the same reasoning why are .debs better
than building from source, and the ultimate - horse drawn buggies vs
automobiles.

I've seen containerized applications described as "statically linked apps",
it's one blob with dependencies included. I'm moving in that direction (vs
cap-style deployments) because it guarantees that all machines are identical
(from QA to staging, to production). Spinning up additional machines becomes
trivial.

~~~
wrs
Containers add their own considerable complexity to the stack. If the
dependencies are complicated enough, or you need fast scaling/reconfiguration
on the fly, then containers can certainly be a net positive. But if you're
adding Docker, Compose, DCHQ, and whatever else to your stack just so you can
put Nginx and some Ruby code in a container, I'm questioning whether that ends
up being a net benefit over Puppet/Chef + rsync.

~~~
tra3
I hear you. I like the idea of "deploying" a pre-built image. Capistrano
"just-in-time" deployments (particularly deployment time "bundle") seem a
little non-deterministic. Docker is certainly non-trivial though, but I think
(I hope), it's a net win. Time will show.

In my mind, it certainly parallels the binary package (debian) vs build-on-
demand package (arch? OS X brew) approach. Both seem to work, but I certainly
prefer the debs.

~~~
brady8
That's where Ansible + Capistrano can work together nicely.

No need to change your application or deviate significantly from a "vanilla"
Ubuntu install - just add your nginx, Passenger configs to Ansible, build the
server, and then deploy with Capistrano.

------
samcheng
What about people who don't want Heroku (or Heroku-style) dynos as application
servers and workers, because you pay excessively for RAM and CPU and wrestle
with configuration constraints, but want to keep the rest of the PaaS
ecosystem?

I'm comfortable maintaining a fleet of stateless application servers, but
don't want to maintain my own database servers, or queue servers, or SSL
endpoint, or logging aggregator, etc. etc.

Is this a feasible setup?

~~~
ctide
At a previous company, we initially set everything up at Heroku. As things got
cost prohibitive, we moved them one by one to AWS. Since Heroku is setup on
AWS, it was easy enough to connect to our Heroku postgres instance from AWS
web servers and it doesn't add any extra latency vs. running direct on Heroku.
Over time, we slowly migrated everything off to our own infrastructure on AWS,
but we were able to leverage Heroku to avoid all of that development effort
until it was cost effective to do so. You'll need to deal with your own SSL
endpoint if you run your web servers on AWS, but it's pretty trivial to do so
with ELB.

~~~
holografix
Out of curiosity: does Heroku give you a better deal as you grow? I know for a
fact Salesforce will discount their licenses more and more and you buy bigger
quantities and sign up for longer contracts. It'd be surprising if Heroku
doesn't do this at all...!

~~~
toyg
They have the opposite model: give it away to small players to hook them up,
then rake it in from heavy users.

------
siliconc0w
This is a submarine for DCHQ which looks to be some proprietary docker
orchestration service that doesn't list prices and doesn't have an open source
version. Pro tip - customers don't want to be forced to talk to your sales
team before they can try your product.

~~~
chris_st
It does look like an advertisement.

I guess it's changed since you last looked -- DCHQ does have a pricing link on
their front page now.

------
dantiberian
I'd be really curious to know how many servers they're running. You can get a
lot of iron for $3200/month.

Also, if I read that correctly it looked like they maintained two sets of
infrastructure and one was always spare so they could do green/blue
deployment. That sounds like a great opportunity to use on demand instances so
you only pay for what you use.

------
jacques_chester
For those who want a less all-or-nothing migration path from Heroku, might I
suggest looking into Cloud Foundry? Several of the buildpacks (most notably
Ruby) are derived from Heroku's upstream repos.

If you decide later that you want to build your own containers, Cloud Foundry
has you covered there too, with a pathway for Docker images to be placed,
launched and monitored on an equal basis with buildpack droplets.

I'm biased, of course. I work for Pivotal, which donates the majority of
engineering time to Cloud Foundry.

------
blantonl
The cloud environment is becoming a "wild wild west" just like the app stores
were a few years ago. It all has to do with how much money is being made in
those markets. Maybe this is the result of AWS finally breaking out their
revenue numbers.

There is so much marketing and plugging of alternatives to [INSERT CLOUD
PROVIDER/LAYER HERE] that there really isn't any substance to all this other
than reading like an advertisement.

