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.
If it’s not lovingly pieced together by our team, it can’t be perfect for us, therefore it’s not good enough. The default these days is to use AWS (which, by the way, is also NIH), then hire people to piece together the currently-hip, my-startup-is-a-snowflake infrastructure on top. This line of thinking has several flaws:
If you think you can hire the very best people to piece together your infrastructure, you’re kidding yourself. But even if you could, the time you spend building this infrastructure rarely, if ever, moves your product forward (unless the infrastructure itself is a core part of your offering).
Here’s why I prefer my route:
Here are just a few of the features we love:
A recent major addition worth mentioning is Heroku Shield, 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.
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.
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:
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.
But I must have Docker! Fret no more. Since early September, you can deploy Docker images to Heroku. 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.
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.
Originally published on InfoWorld.com. Reprinted with permission. © 2018 IDG Communications, Inc. All rights reserved. https://www.infoworld.com/article/3229350/paas/5-foolish-reasons-youre-not-using-heroku.html
In our last post, we explored the pros and cons of Recompose and why we decided to remove it from our codebase. This post includes the strategy we used to approach the large task of implementing that refactor.
If you like many others don’t have an optimal environment setup, you are likely lacking an isolated QA environment for your integration tests.
In this post we're going to look at optimal environments for webapps. This is part two in a series - the first post looks at what are environments for?