This article explains:

  • The benefits of using Heroku as a platform for new products.
  • Why a startup organization’s application will probably outgrow Heroku.
  • The three specific signs that it’s time to evaluate the benefits of migrating from Heroku.

834 words, estimated reading time 3:50 minutes.

Part 1 – How Did We Get Here?

Many startups choose to launch their product on Heroku. It makes a lot of sense. The Heroku PaaS is the result of countless hours of operational wisdom from industry experts, lovingly codified into a developer-friendly experience. You can run a responsibly crafted (from an infrastructure standpoint) application in minutes. If you haven’t yet, just take a moment to consider how amazing that is. Thanks Heroku!

But maybe you’re not a brand new startup anymore. Maybe you’ve growth-hacked your way into a runaway success. The customers are lining up and things are getting real.

Growth Happens

Heroku lets you get off the ground quickly by supporting you with an excellent, general purpose infrastructure and without having to think about implementation details like servers, DNS, and delivery pipelines.

At scale though, implementation matters, and the Heroku one-size-fits-all approach may start to feel like it doesn’t quite fit anymore.

This is similar to something Ruby on Rails shops often experience. Rails make it very easy to start a new project. But easy doesn’t mean simple. There’s a lot of complexity hidden in the framework. At scale that complexity starts to matter. That doesn’t mean you can’t scale a Rails app, but you may start to find that the framework is often driving your technical choices.

How do you know when infrastructure requirements start driving architecture instead of being informed by it? Here are some signs that your Heroku infrastructure may not be supporting you as well as it once was.

Signs It’s Time to Move from Heroku

Any of the following three conditions indicate that you have probably outgrown Heroku:

  1. Deployments Are Getting Harder To Coordinate.
  2. You’re Doing Backflips To Please Your Compliance-Mandated Customers.
  3. Your Heroku Bill is Huge.

1. Deployments Are Getting Harder to Coordinate

Distributed Service Graphic

If you have started to build tooling to coordinate the Heroku tooling, then you may want to consider another deployment pipeline.

Heroku is really good at making the right thing easy to do. If you build your app on Heroku, you are a priori following many 12-factor practices.

But monolithic apps are trivial when it comes to managing deployments. Things can become much more complicated when you start moving towards a microservices architecture. Even a modest number of components (say 10) and three environments means you’ve got 30 Heroku “app” pipelines to manage. In which order do they need to be deployed? There are more than three million ways to deploy 10 apps.

2. You’re Doing Backflips to Please Your Compliance-Mandated Customers

Compliance Logos

You can certainly meet just about any compliance requirements at Heroku. But it can be more expensive and cumbersome than necessary.

Unless you pay a premium for Heroku Private Spaces, you won’t get the network isolation enterprise customers expect. That network isolation is generally the default model for AWS and other cloud providers these days. Also, not all Heroku add-ons will work in Private Spaces.

Role-based access control exists in Heroku but it is very limited. Again, this is not a problem for a single app, but in the world of distributed microservices, the Heroku model may require additional tooling.

In contrast, AWS has a very sophisticated mechanism for allowing temporary access to resources based on role. This dramatically simplifies much of the work involved in enforcing separation of duties.

3. Your Heroku Bill is Huge.

Heroku Costs

Heroku is effectively a value-added reseller of Amazon Web Services. If you are surprised by the size of your last invoice, here is a good exercise for you. Heroku and AWS make pricing available on their sites. Compare the resources you are using in Heroku to the equivalent from AWS. That’s one data point but not the most interesting.

Now look over the AWS catalog and think about what your architecture might look like if you had all of those services at your disposal. Would it be much different? What would that cost?

An important point to make here is that this doesn’t take into account any staffing resources you may need in migrating to AWS. You may not have staff with the right skillset or (more often) the bandwidth. But remember that you are not alone in this journey and the long-term cost savings can be significant.

Where Do We Go from Here?

This article lists three signs that it may be time to migrate from Heroku to some other platform such as AWS. But the actual process requires more careful analysis of current issues as well as careful evaluation of alternatives.

Contact Telegraph Hill Software to discuss the many ways we can help you.

About the Author

Matt Valdez

Matt Valdez

Principal Consultant

Matt is a technology leader with hands-on expertise in distributed systems, site reliability and continuous delivery.