What I Like:
- Easy administration. Our traffic happens to be extremely spiky (Friday's evening traffic is approximately 100x Monday's noon traffic, for example), and the ability to add and drop capacity very quickly is huge. It's literally a GUI slider, so even the non-technical business type can do it when I'm not available.
- Low systems administration overhead. There are a lot of things involved in successfully administering a system: making sure there's redundancy, setting up and maintaining (and testing restores on) backups, keeping the machines up to date, etc. This isn't entirely gone under Heroku, but it's significantly reduced.
- Rollback. I've only had to roll back once (to make sure I knew how!), but it was pretty darn simple. And when you're rolling back a change, you're already in a negative frame of mind, so it's really helpful to at least have an easy way out.
What I Dislike:
- No database access. We're on the shared database, so I can't actually log in and run a SQLquery. It's not a big deal most of the time, but it turns out that I'd become a little bit addicted to having this information when I look for data-related issues or want to see query plans to track down a performance bottleneck, etc. I don't like the feeling of being blind. I should note that this limitation does not exist if you're running on a dedicated database.
- Deployment. See below.
- Rollback. Yes, this one is on both lists! It's easy to roll back code. Rolling back things like database migrations is a whole different kettle of fish, and I have the same problems here that I do with deployment.
- A general feeling of blindness. I always feel like I'm missing something when I use herokulogs, like it's harder to grep through. I don't know that it's actually any better or worse than less and grep on a machine, but it's taking some getting used to.
- Worries about uptime. Just like everyone else, Heroku isn't perfect, and we have seen some downtime. It's pretty rare, but it's still worrisome.
A Note on Deployment:
With Heroku, you deploy using git. For me to deploy to staging, for example, I do this:
1. check out the staging branch (in our github account)
git checkout staging
2. merge whatever I need to
git merge blah
3. run the tests as a sanity check
bundle exec rake rcov
4. push my changes to github
git push origin HEAD
5. push my changes to heroku
git push heroku-staging staging:master
On the surface, this is pretty slick. I'm already using git for source control, so deployment is as easy as setting up a new remote and pushing to it. For anything that's more complicated than a simple git push, though, it gets a lot messier. Let's say I have a migration to run as part of this change. Then my push looks like this:
heroku maintenance:on && git push heroku-staging staging:master &&heroku rake db:migrate && heroku maintenance:off
Adding other things, like jammit, gets even messier. So overall, it sounds great, but I'm not a big fan. Things like chef and puppet and capistrano exist for a reason and are great to use, so I'm not sure we needed yet another way. I've wound up writing recipes to do most of the pushing for me so I don't miss a step, though, which helps.
Putting my money where my mouth is, are we sticking with Heroku? Yes, at least for now. The quick and easy scale-up and scale-down is huge, that trumps the quibbles. Oh, and the quibbles really are pretty minor.
Overall, Heroku is not for everyone, and I encourage anyone considering it to look very hard at things like cost, uptime, service levels, backup policies and timing, etc. Make an informed decision, but after my experience so far, I would at least consider Heroku next time.