DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. 5 Foolish Reasons You're Not Using Heroku

5 Foolish Reasons You're Not Using Heroku

Maybe it's time to reconsider why you aren't using Heroku for your cloud needs. We look at why this is, and why it shouldn't be.

Russell Smith user avatar by
Russell Smith
·
Sep. 12, 18 · Presentation
Like (3)
Save
Tweet
Share
9.87K Views

Join the DZone community and get the full member experience.

Join For Free

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 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 runs 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.

Infrastructure app application Docker (software) AWS Build (game engine) Machine learning security Engineer

Published at DZone with permission of Russell Smith, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Perform Local Website Testing Using Selenium And Java
  • Top 10 Best Practices for Web Application Testing
  • 4 Best dApp Frameworks for First-Time Ethereum Developers
  • How To Set Up and Run Cypress Test Cases in CI/CD TeamCity

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: