Should your startup use Heroku?
Note: For the purpose of this piece, Heroku is synonymous with other analogous services like EngineYard and Clever Cloud. AWS is synonymous with Microsoft Azure and Google Compute Engine (although they aren’t quite the same).
Projects and companies usually consider the tradeoffs in using Heroku or AWS in early stages. The focal point of this consideration is usually time; Heroku allows you to focus on your app by removing the need to maintain web infrastructure.
What do we mean by web infrastructure? This may include but is not limited to: database hosting/backups/replicas, static file hosting, web server & asynchronous work server configuration and scalability, configuration management, managing dependencies for software, and deployment of updates to your application.
Simply enumerating web infrastructure tasks doesn’t give a clear picture for why we’d consider Heroku. Let’s assume for every 9 hours you spend working on your application, you spend 1 hour of time building and maintaining your web infrastructure. Assuming 48 working weeks in one year, you’ve spent 4.8 weeks on infrastructure.
This is the typical walkthrough most engineering teams have when choosing Heroku. But it’s not quite as simple as it seems. We’ve enumerated key benefits of choosing either Heroku or AWS below.
In favor of a managed service (Heroku)
- Easy deployments with no setup cost (it is relevant to emphasize no setup as the primary benefit because you can achieve this on AWS)
- Automated backups with no setup cost
- A plethora of simple integrations
- Avoiding obvious security blunders
- AWS user management, when not done right, holds massive potential for security breaches.
- Avoid certain types of downtime
- Heroku has simple rollbacks of SSL keys, environment variables, etc. Messing one of these up in AWS is hard to audit and track.
A theme emerges - using Heroku makes it hard to encounter a serious human error. This is far more valuable than it sounds. See this list for a list of famous outages of prominent web services and their causes.
In favor of directly interfacing with services (AWS)
- Cheaper (raw cost, not factoring in time to integrate)
- Use languages and frameworks that aren’t on Heroku. Build novel and powerful architectures.
- Greater potential for performance.
- Ambiguity of how Heroku internals work can cause issues. These aren’t horrible, but its critical to be aware of these. The problem is that these idiosyncracies are numerous and its pretty hard to have a good idea of what type of system you’re buying into unil you encounter an issue.
- Rapgenius famously left Heroku due to an error in how Heroku reports response times (Heroku’s reported response times differed from what a reporting tool logged)
- Any “owner” can download an app’s replicated database
- An ephemeral file system.
- You may only have one SSL certificate per app
- Avoid certain types of downtime
- If Heroku goes down, so do you. You remove a layer of dependency by using AWS.
We can summarize the benefits of using AWS as having more flexibility and tools.
An evolving landscape
A plethora of open source tools for making AWS infrastructure management easier too, such as Ansible, Puppet, Chef, and Salt.
Is it possible to get the best of both worlds? A startup called Convox has a great value proposition, to bring the best of Heroku while still being able to use AWS directly.
A bit of anecdotal advice on this entire matter is to not obsess over this too long - pick a system after understanding the tradeoffs and use it cleanly. Successful projects have a track record of using a variety of platforms.