5 foolish reasons you’re not using Heroku
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.
#1. Heroku is NIH (Not Invented Here)
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:
- Your engineering team lacks the time to learn the skills and do the job properly—unless you hire additional people who are extremely smart.
- You can’t hire additional people who are extremely smart. Great people are very expensive, hard to find, and probably already working somewhere else.
- You rarely need to build an infrastructure only once. When your needs change, you’ll have to build it all over again.
- Your custom infrastructure won’t be battle-tested until YOU’VE battle tested it. Or rather, until your customers and engineers have. Don’t put them through that. Just don’t.
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:
- Heroku lets us focus on what we do best—building an automated QA platform.
- Having some architectural limitations imposed on you can actually be a good thing. They liberate you from choice and analysis paralysis.
- Heroku is constantly adding features that actually do move our product forward.
Here are just a few of the Heroku features we love:
- High-availability Postgres
- Encryption for Postgres turned on by default
- Log drains (a standard way to do log collection and forwarding)
- Review Apps (which run the code in any GitHub pull request in a complete, disposable app on Heroku)
- The Heroku add-on marketplace
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.
#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 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.
#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 newtechforum@infoworld.com.
Source: InfoWorld – Cloud Computing
Recent Comments