Engineyard or Heroku?

Web-based software is becoming more and more service-oriented. You probably know about software as a service (SaaS – e.g. Salesforce) and infrastructure as a service (IaaS – e.g. Amazon) but probaby not platform as a service (PaaS). Companies like Engineyard and Heroku make it easier to launch and scale a web application. For the most part, you can setup an account, run a few commands for basic configuration and you’ve launched in the Cloud. This is an order of magnitude easier than it was just 5 years ago. If you just felt your heart skip a beat, please take a few minutes to catch your breath. When you’re ready, let me help you decide what platform to launch your next application on.

Heroku is great for quick applications. The best Rails candidates I interview deploy their code challenges on there and send me a link. The smallest configuration on Heroku gives you a 5MB shared database and 1 “dyno”, their unit of measure for CPU. It’s free and you can even get add-on’s like New Relic performance monitoring thrown in. To scale up, you can pay more for dynos and a more powerful database. Setup is fairly painless, though I had to google for help when their “happy-path” documentation didn’t work exactly the way it was intended. The most annoying thing is that for the smallest configuration, the first request you make to the site takes 30-60 seconds to complete because their servers are dynamically provisioning you resources. Heroku hides much of the Operations side of things from you and that’s an intentional choice. It’s clear that they’d like to make the deployment process idiot-proof. I think that’s great for interview code challenges and school projects but if you’re serious about your application, you need to use Engineyard.


You need to be in control. Over the years I’ve seen EBS volumes become read-only all of a sudden, MongoDB refuse to resolve internal hostnames for a subset of instances, and even instances mysteriously become unreachable or “disappear”. Putting your servers in the Cloud has a huge drawback: you don’t have physical access to the hardware. When things go wrong–and they inevitably do–you need to have access. Since you’re saving money by not buying your own hardware up front and using IaaS, the next best thing is having as much control of your instance as possible. With Engineyard, you can ssh into every single machine and customize your own recipes. Essentially, they setup the default configuration but at the end of the day you can do whatever you want. For everything from Cron to Redis, I customize the configuration and understand exactly how processes are running. I analyze the CPU and memory usage and even the IO performance because I need to tune things like how many workers should be on each application instance. Control is critical when debugging issues. You’ll need to install custom monitoring and benchmarking to find out why your Memcached servers are maxing out at 80% memory utilization for example.

You need expertise. PaaS is your world-class Operations team. Even if you hired one or two Operations people, it is unlikely they will be experts in all the technologies you’re using. Given that I’ve never used paid Heroku Support, I can’t speak to their experts, but Engineyard definitely knows their stuff. They try to cover as many areas as possible in-house and through partnerships, cover others. I know that they have a great in-house MongoDB presence because their team helped me with my Sharding migration. I’ve gotten DBAs from Percona to look over my slow mysql queries, advice from Durran Jordan of Mongoid over IRC, and just as I was looking into Neo4j for some graph-based projects, I heard that they were actively talking with Neo Technology about a partnership. When your application has a problem and Google doesn’t help, you can either call a really smart friend like a contestant on “Who Wants to Be a Millionaire” or you can leverage the collective expertise of Engineyard and their network. They know your application and infrastructure really well and you may be seeing the same problem as another one of their clients. This expertise model works and just makes sense.

You need support. When you’re in the Cloud, you need someone to have your back. You can install a Heroku add-on like “Redis To Go”, but what happens when things break? As a engineer I’m pretty paranoid and rightfully so. I’m weary of things labeled “X to go” or “Y in a box”. Furthermore, I believe that if you’re going to use a technology in production, you should install it yourself. It’s critical that you develop a long-term relationship with a team that knows your specific application and infrastructure. When you read an email from Engineyard at 9am telling you how at 5am they detected a problem and brought your site back up without waking you from your precious 6 hours of sleep, you’ll know what I’m talking about. When it’s 3am and you’ve been wrestling with an issue that’s keeping your site down and your friends at Engineyard are still up and walking you through hell, you’ll know what I’m talking about. Heroku support may be just as good, I don’t know. But I’ve been in the trenches with these guys and I can tell you that whoever you choose, you better be able to count on them when the CEO is calling you to ask when the site will be back up.

If you’re serious about your application, you’ll take these points into consideration and weigh them heavily against cost and hype. Engineyard’s worth the money.
Disclosure: Badgeville is an Engineyard customer and so was Howcast when I was there

5 thoughts on “Engineyard or Heroku?

  1. Depending on your needs heroku might get you very far, very fast. I like to use it for clients whose biggest hurdle is not the technology, but in rapidly building a product and iterating quickly. If you already know your customer base, your eventual architecture, and how big your app is going to get, you might prefer to jump ahead to engine yard or amazon, but if you are launching a new app and are still in the process of discovery and exploration, you may find heroku is a good place to start. I work with a lot of small startups and prototype apps, and I think heroku is great for that. Its easy to launch an app quickly, engage users, add new features, scale it up and down as needed, lots of plugins to help you along, while keeping your IT costs reasonable.
    Now if the app really takes off, in a sustained way (not just a press-release spike), you will have to decide what changes you want to make to the architecture, and if you have outgrown heroku. I think its great to have Heroku, EngineYard, and Amazon as deployment options. They all have great free options, and each of them has their sweet spot.

    • Thanks for your thoughtful response, John. I like how you’ve framed the discussion around Heroku, EngineYard, and Amazon being separate options that aren’t mutual exclusive. I think that’s where I was trying to go as well, eventually. The argument is too often a question of “A or B” whereas we should really just understand what best fits our individual need at that moment. If more people understood this, then we’ll all be moving forward.

  2. Full control means also you have full responsibility. That means you need to dedicate quite some time on server setup and maintenance. With Heroku you have highly skilled engineers woking on your server units in case something goes wrong. So especially for small teams who like to focus on development rather then server maintenance Heroku might be the better choice.

  3. Thanks for throwing that in Dr Nic. I was not saying that EY doesn’t. Sorry if it came across like that.😉 But with Heroku you have much less to worry about compared to EY as far as I know, as you don’t have to install stuff yourself via ssh. But correct me if I’m wrong, I have never used EY so far. With Heroku you just add some addons if you need extra functionality, no need to worry about updates, as all is managed for you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s