Time to Leave Heroku Behind
For anyone not familiar with Heroku, it was a platform that originally rose from the desire to deploy applications without worrying about any kind of infrastructure. Don’t worry about load balancers, don’t worry about standing up VMs, don’t worry about securely connecting your applications to a database… Heroku would do all of that for you, at a cost, and all you needed to deploy apps was git push.
Even today, plenty of people love the simplicity that Heroku can provide, especially when it comes to accelerating application development with smaller or less experienced teams. But when you look at Heroku terms of service, there’s something rather insidious within it. More specifically, there’s something missing from it.
SLAs for Days
When people offer services in exchange for money, there’s usually a key metric that people care greatly about: SLAs. It stands for “Service Level Agreement” and it defines what constitutes a minimum level of service that will be provided, what kind of recourse will be executed in the event of unacceptable loss of service, and what exemptions might exist to the agreement.
One big example is compute instances across the public cloud providers. Google, for example, has an SLA for their Compute Engine service. In it, Google defines the minimum uptime for various Compute Engine services, that a loss of service beyond what is defined will receive financial credits, the level of credits based on the excess loss, and exemptions to receiving financial credits (e.g. if a hurricane takes out an entire data center you don’t get credits).
These SLAs are crucial metrics when considering the value proposition of a service. For example, it’s entirely subjective whether you want to pay $100/mo for 99% uptime or $250/mo for 99.9% uptime. A 99% uptime means you could get up to 13.5 days of unpaid downtime per year. A 99.9% uptime means you reduce your downtime tolerance to only 9 hours a year. Is that extra $150/mo worth having nearly 2 weeks of additional uptime for your service? It depends.
Heroku Has No SLAs
As the section title states, Heroku has no SLAs. It’s missing from their terms of service. This means that Heroku has no financial obligation to ensure their services are run properly or with any kind of minimum uptime requirement.
The most recent incident which caused production problems to applications for an extended period of time, and for which the only recourse was a manual solution and not something Heroku even bothered to do on behalf of customers, was Issues using data products.
That outage hit my company at about 5am PST. Thankfully we had people awake and working around that time (most of our engineers are EST), but it’s ridiculous that we had to scramble to manually debug and fix an outage caused by our very expensive service provider because they decided to disable a security add-on for our database that then prevented any of our applications from communicating with it.
I could go into detail about where Heroku’s theoretical SLAs would be for them to minimize their financial obligations to customers, but I won’t, because the fact that they currently have no SLA is the only thing we need to care about. Nearly every similar service I’ve looked at has SLAs when you are a paying customer. I can’t reiterate that point strongly enough.
And we need to remember that Heroku isn’t cheap. Heroku pricing for their “dynos”, which are their basic compute unit, are $50/mo/standard-tier dyno. Standard-tier dynos have no CPU guarantee and only 1 GB of memory. You could deploy an N2 general-purpose VM through Google Compute Engine for approx. $56/mo and that gives you a dedicated 2 virtual CPUs and a whole 8 GB of ram. Basically, Heroku has a huge markup on their resources. The typical range of cost difference is that Heroku will be 4 to 10 times more expensive than a cloud provider.
So not only is Heroku not cheap, but 29 hours of downtime would have easily blown through the Google Compute Engine SLA of 99.5% which only allows for about 3.5 hours of downtime every month. If you experienced this kind of outage with Google, you’d be getting some money back for sure, because Google dropped the ball and they have a responsibility to you, the paying customer. Heroku, on the other hand, told me to basically f-off because they don’t have any obligation to keep these services up and running.
To be fair, dynos weren’t the affected service here, so comparing the outage at Heroku to Compute Engine isn’t an apples-to-apples comparison. I’m only using it to illustrate SLAs generally. Which in this case is more than fair because 0% guaranteed uptime is going to be less than anything any other comparable service provides.
Alternatives
We’re not without alternatives to Heroku. Heroku is certainly the OG here but that’s not always better. There are PaaS competitors such as Render, Netlify, Firebase, Engine Yard, Gigalixir, and all the major public cloud providers have their own “push-to-deploy” offerings as well, such as Google App Engine and AWS Elastic Beanstalk.
Not all of Heroku’s competitors have uptime guarantees but this is where you need to conduct your value comparison. Some competitors might not have uptime guarantees yet charge less than Heroku. Or some might have specific features that come out-of-the-box that you need which Heroku might charge extra for. But some are both comparably priced and have SLAs guaranteeing some minimum uptime. Engine Yard, for example, is about the same cost ($50/mo) but has a 99% uptime guarantee. That’s infinitely better uptime guarantee compared to Heroku.
Personally, I find quality of service has declined slowly but steadily with Heroku. Whether that decline coincides with it being acquired by Salesforce, I don’t know and I can’t say. But it is absurd to me that Salesforce, an extremely profitable company with vast developer resources at their disposal, can’t bring SLAs to Heroku. I might even go as far as to say it’s outright disgusting that they won’t hold themselves financially responsible for the costly services they provide through Heroku.
I already stopped using Heroku like 6 years ago and never looked back. It’s incredibly simple to get something up and running even on Kubernetes these days with GKE Autopilot and ECS, so Heroku isn’t quite as relevant and necessary as it once was. It still could provide value in certain scenarios, but the fact they have no obligation to provide a minimum level of service given their high cost factor has merely reinforced my decision to remain as far from them as possible. I would encourage others to do the same.
