Heroku Reviews

I first used Heroku to deploy and host Facebook apps, and I’m a big fan ever since.

Lately, I’ve been doing development with node.js and since Heroku supports it (wonder if they were first to offer it), it was a no-brainer:

• deployment via command line with git: nice way to enforce best dev practices
• package management with NPM – everything will be fetched and installed for you
• built-in SSL support on *.herokuapp.com subdomains
• easy monitoring: just type ‘heroku logs’
• easy scaling: just type ‘ps:scale web=x’ or ‘ps:scale worker=x’
• support of environment variables: one example – running multiple instances from the same git repo
• pretty good docs and tutorials
• tons of add-ons: you are free to do pretty much anything (I use Mongolab add-on for Mongo hosting)
• affordable!

Nodejitsu is another service focusing on node.js primarily, but I’ve been reluctant to switch because I just like Heroku so much.

It’s also super cool that they support multiple environments via buildpacks, I’d love to look under the hood and find out how they made it work (and here’s a great post describing their polyglot platform in high-level)

In contrast to the one-language-per-career programmer, today’s up-and-coming developers can often utilize many languages effectively. Borrowing a term from linguistics, we can call these versatile new developers “polyglot programmers.”

For the latest Show&Tell demo, I talked about benefits of using Heroku (as one of the PaaS options) for rapid deployment and easy hosting, so here’s the deck.

This week I’m working on a recommendation chart for cloud hosting, so I’ll share that as well soon.

A blog post went viral this week and uncovered an issue in PaaS provider, Heroku’s routing mesh, which has caused a significant degradation of Ruby on Rails app performance. Essentially, over the past three years Heroku moved from “smart” to “random” web request routing among an account’s “dynos”, Heroku’s processing units. Each dyno runs about $35/month.

The change in architecture, which is explained in detail here, is only a portion of why Heroku is catching heat. Here are the real reasons:

Same cost, less value

First and foremost, there have been no reductions in price for the net reduction in capacity provided by the service. This is especially frustrating to the community at a time when other PaaS providers like Amazon Web Services (AWS) continue to lower their prices. Heroku’s platform leverages AWS in its architecture. Over time, users were purchasing more dynos for their accounts with diminishing returns. Each additional $35 dyno does not provide $35 in value.

Appearance of deception

Second, Heroku boasts robust monitoring tools that allow you to see the performance of your applications across many layers of their architecture. However, the monitoring tools provided by Heroku and New Relic don’t reflect the area of latency caused by random request routing. For a highly sophisticated platform provider, this oversight comes across to the community as deceptive rather than as an oversight.

Lack of coherent communication

Finally, there was no communication to customers about the change, and no consistent and coherent documentation. In fact, documentation around Heroku’s site was confusing and contradictory. Again, the appearance of deception.

Response

Heroku is responding openly and humbly, which is the proper way to handle the situation, but there are many who don’t think the responses go far enough. They want monetary reparations as well. I’d guess Heroku is considering concessions quietly by necessity as they are part of a publicly traded company and any concessions could have an impact on current and prior period financials of the company.

The whole debacle reminds us that the lack of transparency over time can cause much larger PR problems for companies than the issues themselves. Individual customers have the platform to tell their story and initiate change.

Valuable Features:

Improvements to My Organization:

Room for Improvement:

Most of my projects lately have been deployed on Heroku. They’ve developed a really nice set of tools to get your Rails (and other) apps from a git repo out into the world. They do really smart things regarding database connections to make things easy to push live. If you follow the standard setup, you’ll be running on Postgres hosted at Heroku.

Often, we want to take data that may be out on a live app (staging or production level) and setup a development machine to have that data. For complex data models and complex data setups, this can be the only way to debug issues that may not have been covered by standard unit/integration tests. With PGBackups, a heroku add-on, and a couple small Rake tasks, this is a snap.

Read the rest of this post here:
http://rcode5.wordpress.com/2013/06/30/easy-postgres-backuprestore-from-heroku-with-pgbackups-and-rake/

Valuable Features:

Room for Improvement: