When building products for our clients, more often than not, we recommend Heroku as their first hosting solution.

Admittedly, their pricing is on the premium side. But, I believe worth it for the completely managed aspect, as well as the ability to scale on-demand within seconds (a feature we were very grateful for recently as we supported an overnight explosion of growth on the Goodsixty platform).

But even if you use a service daily, you can miss some of the new features that are available to you. I don’t know why, but while Heroku is one of those amazing services that keep bringing more and more value to their offering, I’ve somehow managed to miss many of the new feature announcements.

So, I recently embarked on a Heroku quest – to dig down into those new features, seeing what I’ve missed and how Heroku continues to build upon the value they provide for us at CookiesHQ and our clients.

Heroku Preboot – A zero downtime deployment

One of the more annoying things with Heroku is that it restarts your application on every deploy or changes of ENV variable.

When you’re using Ruby on Rails, this not only results into a restart of your Dynos but also a reboot of your Rails app, causing everything to run much slower.

Well, on my quest I’ve discovered Heroku Preboot. In a very simplistic way, on new deploys or changes of ENV vars, Heroku will boot your app onto new “hidden” dynos, and wait a few minutes before routing traffic to it.

This means it gives your dynos and your app the time to safely boot before any users are directed to it, avoiding any slowness and allowing for those zero-downtime deployments.

Because this can result in two versions of your application being served at the same time, I would recommend you turn Preboot off if your deploy includes conflicting database changes (like renaming columns).

You can read more about Heroku Preboot in their documentation. Please take the time to read and understand the limitations!

Heroku Preboot is often coupled with the Zero downtime migration gem. This gem will force you to write your database migrations in non-blocking ways. It will inevitably require a little more technical gymnastics than you might like at first, but the pay off is ensuring transactional and non-blocking migrations on each deploy.

Heroku Postgres – database backups and timed rollback

Heroku have also introduced Postgres rollbacks. They allow you to revert to a previous version of your data, in the same way you can revert a previous version of your code.

This is an automatic backup that will allow you to revert back to data from up to 4 days previous.

From a maintenance and client service point of view, this is a big deal. It means that your database backups are always there, completely managed. If any big mistake happens, you can safely and quickly rollback to any given timestamp where you know the database was clean.

You find out more about Heroku Postgres database rollback in their documentation.

Alternatively, or additionally, you can still set up daily hard backup captures of your database using Heroku PG::Capture

Heroku Metrics – database queries diagnosis, connection pooling and other goodness.

Finally, in a “don’t forget about those” manner, these are some of my favourite features that I think we should all know about:

Heroku metrics have been there for a while now, available in your application dashboard. They not only give you insight about the heath of your dynos but also allow you to set up various alerts if your dynos were to suffer degraded performances.

Expensive Queries diagnosis will allow you to find, directly on your production data, the beginning of an explanation for your least performant queries.

If you’re using Heroku Preboot, you might want to invest some time reading about Heroku Postgres connection pooling that is now available in beta.

Release phase is also a useful addition to your toolkit to ensure you’re running your migration pre dynos booting rather than after the deploy has happen. The most important piece here is that, is an issue is raised during your migrations, the whole deployment will be rolledback.

Conclusions

If you’re following me on Twitter (@nicalpi) you know I’m not immune to moaning about Heroku pricing from time to time. I’ve looked at various alternatives in the past and will make this the subject of a future post.

But, given all the efforts from the Heroku team to help us deploy and maintain applications so easily, I still find myself recommending Heroku every time a startups needs an app hosting that works and supports them in the background!