I’m a huge fan of Heroku. I mean I’m a huge fan of Heroku. Their platform is much closer to exactly how I would want things to work than I ever thought I would get. However in the past few weeks Heroku has had a number of serious outages…enough to the point where I started thinking that maybe we needed to start working out a backup plan for when our various Heroku-hosted applications were down. That’s when I realized a big problem, and it’s not just a problem with Heroku but with any Platform-as-a-Service:
The moment you need to have failovers or fallbacks for a PaaS app is the moment that it loses 100% of its value.
Think about it: to have a backup for a Heroku app, you’re going to need to have a mirror of your application (and likely its database as well) running on separate architecture. You will then need to (in the best case) set up some kind of proxy in front of Heroku that can detect failures and automatically swap over to your backup architecture, or (in the easiest case) have the backup architecture up and ready to go and be able to flip a switch and use it.
The backup architecture is obviously going to have to be somewhere else (preferrably not on EC2) to maximize the chance that it will be up when Heroku goes down which leaves you with the glaring problem that if you have to mirror your apps architecture on another platform, all of the ease of deployment and worry-free infrastructure evaporates. This leaves you with two options:
- Put your faith in your PaaS provider and figure that they will (in general) be able to do a better job of keeping your site up than you could without hiring a team of devops engineers.
- Scrap PaaS entirely and go it on your own.
A “PaaS with fallback” simply doesn’t work because it’s easier to mirror your architecture across multiple platforms than you control than it is to mirror it from a managed PaaS to a platform you control.
Don’t Panic
Note that I’m not telling anyone to abandon Heroku or the PaaS concept; quite the opposite. My personal decision is to take choice #1 and trust that while Heroku may have the occasional hiccup (or full-on nosedive) they are still providing high levels of uptime and a developer experience that is simply unmatched.
Heroku has done a great job of innovating the developer experience for deploying web applications, but what they need to do next is work on innovating platform architecture to be more robust and reliable than any other hosting provider. Heroku should be spread across multiple EC2 availability zones as a bare minimum and in the long run should even spill over into other cloud providers when necessary.
If they can nail reliability the way they’ve nailed ease-of-use even the most skeptical of developers would have to take a look. If they could say with confidence “Your app will be up even if all of EC2 is down” that’s yet another powerful selling point for an already powerful system.
The Third Option
There is actually a third option: if your PaaS is available as open source then you will be able to run their architecture on someone else’s systems, giving you a backup that is at least a middleground between the ease of PaaS and the reliability of Do-it-Yourself. The two current players in this arena are Cloud Foundry and OpenShift.
While Heroku currently has them beat for developer experience (in my opinion) and the addon ecosystem makes everything just oh-so-easy, it might be worth exploring these as a potential middleground. Of course, if Heroku would open source their architecture (or even a way to simply get an app configured for Heroku up and running on a third-party system with little to no hassle) that would be great as well.
In the end I remain a die-hard fan of PaaS. It’s simply amazing that, merely by running a single command and pushing to a git repo, I can have a production environment for whatever I’m toying with available in seconds. After the past few weeks, however, I am spending a little more time worrying about whether those production environments will be up and running when I need them to be. And that’s the problem with PaaS.
