When I tell other CTOs and engineers that we rely heavily on Heroku to run our business, they invariably have the same reaction: Why? Why not AWS? Are you joking? Have you heard of Google Cloud? Are you an idiot?
This happens without fail. With. Out. Fail. The argument usually goes something like this: Why pay more for a PaaS when you can build it yourself on Google or AWS—and have it just how you want it? To which I say: Poppycock. These people are missing the real benefits of PaaS, and perhaps some basic economic sense as well.
We’ve been using Heroku extensively at Rainforest QA since early 2012 to run our automated QA testing service. We deploy almost everything in Heroku—for production, staging, and QA for most apps. It’s stable, it makes economic sense, and it precisely suits our needs.
Here are the main arguments I hear against Heroku, and why I think they are (mostly) fallacious.
(which run the code in any GitHub pull request in a complete, disposable app on Heroku)
A recent major addition worth mentioning is , which gives us a BAA (business associate agreement for HIPAA compliance from Salesforce.com. It has some teething issues, but If we were to build HIPAA compliance ourselves it would take a couple of engineers a month or more of work. Instead, those engineers are moving our product forward and making our customers happier.
#2. PaaS is too expensive
But Heroku is soooo expensive! This is herd thinking and ignores the cost of finding, recruiting, and training great devops people to build and maintain your snowflake infrastructure. Not to mention the cost of retaining these people, putting them in an office, and providing ping pong tables or whatever else it takes to keep them happy.
Then there is the opportunity cost of hiring people in devops and sysadmin roles instead of product engineering. And those costs increase linearly as your business scales. With Heroku, you have diminishing marginal costs at scale.
And don’t forget the additional cost of your lack of focus. If you’re dealing with peripheral infrastructure matters, you’re not focused on making your product better.
Paying Heroku means you don’t have to worry about building your infrastructure and keeping it available at all times—and it still costs the same or less than hiring and retaining those additional ops people.
#3. PaaS is too constraining
But… but… my snowflake! A lot of people think their application or architecture has unique needs. In most cases, it doesn’t—and if it does, it probably shouldn’t. However, I’m prepared to accept a few legitimate reasons you might not be able to use Heroku. Here they are:
- You need tons of CPU or RAM. Heroku won’t scale as far as AWS, and configurations are a bit less flexible. If you really need thousands of servers, AWS (or even bare metal) may be more economical. But Heroku supports some pretty sizeable instances. For most people, it should be more than enough.
- You need bare-metal servers or specialty processors. If you’re doing machine learning or other GPU-intensive work, Heroku might not be a great fit. However, you can still take a hybrid approach like we do. We use Heroku, but also bare-metal servers to get the best performance for our virtualization platform.
- You need non-HTTP RPC, such as gRPC. Any inbound traffic that is not WebSocket, HTTP, or HTTPS isn’t supported by the Heroku router today.
- You can’t work within the supported application models. For instance, if you need internode-communications, so that a group of app servers can behave as one for something like Erlang or Elixir, or you need a unique routing setup, then Heroku is not for you.
There may be a few other reasons, but often they are not essential to your business. If you can design your application to fit in the Heroku model, you get many benefits. The major one is consistency across applications—from deployment, to monitoring, to logging, to scaling.
#4. Heroku doesn’t do Docker
But I must have Docker! Fret no more. Since early September, you can . Even before that, Heroku included somewhat similar capabilities to Docker, allowing you to ship around containerized builds of your app. It didn’t match Docker feature for feature, but you could think of Heroku as being a hosted, managed version of Docker. In any case, that concern is now gone.
#5. Heroku is not secure enough
But Heroku is not secure! LOL. Unless you’re in a heavily regulated industry, like finance, or you require a particular certification that is not supported by Heroku, this should not be an issue. There is no reason to believe Heroku is meaningfully less secure than AWS. It has a whole team devoted to managing the security of its platform; do you? Plus, you’re going to be making a ton of one-off decisions while you’re rolling your own infrastructure, none of which will have been tested. Heroku made these decisions long before you, and they’ve been tested at a scale most companies can only imagine.
Plus, unlike your custom environment, Heroku is consistent and uniform. It has boundaries that are clearly defined, which means your attack surface is going to be smaller. That also means it’s easier to understand, so you’re less likely to do something by accident that creates a vulnerability.
And by the way, engineers love a consistent deployment environment, for all sorts of reasons besides security.
Ultimately, every company needs to make the best decision for its business and its customers. But remember, those customers don’t care if you’re on a cutting-edge, homegrown work of art or a general purpose PaaS. They care that your service works, that it improves over time, and that you don’t get hacked. Heroku has worked very well for us, and it probably would for you.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to .