DEV Community

Ben Halpern Subscriber for The DEV Team

Posted on

Why DEV hosts on Heroku (and how we configure our service)

Disclosure: Heroku is a DEV sponsor, but this post itself was not "sponsored" per se.

I chose to write this post because I wanted to provide some thought around how we think about these things at DEV. I get a lot of questions about this kind of thing, and my answer is usually "it depends". That being said, I've been a consistent user of Heroku for almost a decade, so there must be something that keeps me (and DEV) around.

There are a lot of great cloud choices, including another one of our sponsors: DigitalOcean. The hosting/cloud landscape is getting better and better for developers, but this isn't an apples-to-apples discussion. These aren't commodities, they are specific services with different services, different UX concerns, and a lot of tradeoffs.

We do not use Heroku exclusively by any means, but we have consistently made use of it for some of our core work due to developer experience provided by the platform.

First of all, what does Heroku do exactly?

Heroku is describes itself as a "platform as a service", which essentially means it's a more integrated experience than you might find with other cloud services. I've never been exactly sure where to draw the lines in articulating some of these things; but in principle, Heroku bundles a runtime environment, an ecosystem of plugins and a general focus on integrated developer experience.

What's the big benefit?

In a phrase, we've been using Heroku for years because it gives us our time back, and really doesn't need to be taught. That is, the onboarding process for Heroku can be largely stepped through intuitively rather than having to go through school just to use the service. They've done a great job of outlining pretty much every path we've ever needed to take with great guides.

The Heroku CLI and web interface each offer effective ways to interact with the service. I've found that different team members make different choices on this front without causing intra-team miscommunication.

Interacting with Heroku in different ways, like with the add-on ecosystem, would often be done via the command line like such:

heroku addons:create rediscloud:100
Enter fullscreen mode Exit fullscreen mode

But if I wanted to jump into the web interface I usually feel pretty comfortable with that, and jumping between the two environments. Some folks on our team might even use our app's console directly in the browser... if that's what fits their flow.

Interacting with the Herok

Integration without lock-in

Perhaps the biggest reason we've stuck with Heroku is that we've never found ourselves especially locked in to Heroku's ecosystem. The first version of things we've needed to build are almost always available in the Heroku add-ons ecosystem, but when we need to shift gears for any reason, it's always been easy to remove those tie-ins because the integrations are almost always definable by app config in a way that makes swapping services

Our Heroku config

We run on a single Performance L Dyno, with autoscale configured to parallelize to 2+ if there is any slow down in traffic. We fork our application using Puma to run concurrent instances on one Heroku machine (i.e. a dyno). Early on we used Standard 2x Dynos until we eventually saw greater efficiencies by running on one big one.

The use Heroku managed Postgres for our core database, and most of our other services are non-Heroku products, but typically still managed through the add-on system Heroku provides. We have been able to move off the add-on system, however, when it fit our needs in terms of simplest ways to access the dashboards, etc. The add-on system is a great default, but it's also important that we can shift our approach when we feel the need to.

For further reading, here is a post which takes a really great look at the Heroku service...

Happy coding!

Top comments (27)

Collapse
 
metacritical profile image
Pankaj Doharey

Though i totally get your point, my feelings in the past few months have changed and i think the best way is to run lambdas/functions on a Digital Ocean maintained Kubernetes cluster. It literally means no restarts. In your current setup you would have a small restart of services due to the fact how Heroku works.

Collapse
 
ben profile image
Ben Halpern

Yeah, this is understandable, but not a big concern based on what we need out of a service.

We do use AWS Lambda for some things. Ultimately our choices are a mix of what we care about and the natural evolution of our needs.

Collapse
 
metacritical profile image
Pankaj Doharey

Since u are here, I would digress a bit to ask for a feature request, is there a way to move existing posts to a series?

Thread Thread
 
jess profile image
Jess Lee

Yep, here's some more info in this post for v1 editor: dev.to/ben/changelog-create-series...

For v2 editor, you would click on the ellipses on the right hand side to create a series.

Thread Thread
 
metacritical profile image
Pankaj Doharey

Thankyou!

Collapse
 
rahulchowdhury profile image
Rahul Chowdhury 🕶

Hey Ben, what's your current monthly cost for running DEV on Heroku?

Collapse
 
ben profile image
Ben Halpern

Our base Heroku cost with direct Heroku stuff is about $1200/mo, plus we have many other costs that don't map directly to Heroku (other cloud services). We have some fat to cut in some places, but the relative cost of software developer salaries leaves the tech costs as having a pretty minimal footprint.

Collapse
 
rahulchowdhury profile image
Rahul Chowdhury 🕶

How's the breakdown? You said DEV uses a Performance-L dyno which is $500/month.

How much do you pay for the managed Postgres instance? Also, I know that DEV uses Fastly, what's your average bill over there?

I'm trying out Fastly for my upcoming service, trying to have a gauge on my monthly expenses. 😁

Collapse
 
sinni800 profile image
sinni800

At what kind of traffic? Daily impressions, etc?

Collapse
 
mscccc profile image
Mike Coutermarsh

Wow. Very impressed with the low spend.

Collapse
 
yaron profile image
Yaron Levi • Edited

Hi 🙂
Thanks for sharing.

Do you use Heroku Private Spaces? If not, it means your Heroku Postgres is publicly exposed to anyone how gets his hands on the credentials. Can you live with it?

How many requests per minute dose your dyno serve in the busy hours? Can you shed some light on this?

Collapse
 
highcenburg profile image
Vicente G. Reyes

What? How is it exposed?

Collapse
 
yaron profile image
Yaron Levi

If you send me your db's connection string, I can just open my sql client and read/update whatever I want.

If your db is in a Private Space it is accessible only via a specific IP. So in this case, even of your db's connection string falls into the hand of an attacker, he cannot access the db.

Thread Thread
 
highcenburg profile image
Vicente G. Reyes

Who would send one, one?

Thread Thread
 
highcenburg profile image
Vicente G. Reyes

A private space costs $1000/month. Even a CEO wouldn't pay for that much for his/her side project.

Thread Thread
 
yaron profile image
Yaron Levi

Ah ok (-:
If it's in the context of a side project it's not really an issue.
I was thinking more in the direction of a production app.

Collapse
 
nogtini profile image
Joey D. • Edited

If you're a student I encourage you to look into their educational discounts. They're quite generous.

heroku.com/github-students

Collapse
 
quinncuatro profile image
Henry Quinn

Love the transparency, my dude!

Collapse
 
andrewbrown profile image
Andrew Brown 🇨🇦

I always thought DEV.to was on Digital Ocean.

Collapse
 
ben profile image
Ben Halpern

Nope, they're another great sponsor and we use them in other ways here and there, but we've been on Heroku for the core app since day one.

Collapse
 
darksmile92 profile image
Robin Kretzschmar

Hey thanks for sharing the insight, was really interesting!
Especially pointing out the ease to switch add-ons, that was something I was afraid of: to depend on the add-ons once I start using Heroku.

Collapse
 
ben profile image
Ben Halpern

We've switched for as simple reasons as wanting to log in in a different way (e.g. keep the same service, but switch from "add-on" to just "regular use of service"). Add-ons are great because of how easy it is to upgrade, downgrade, add, remove, etc. but sometimes there's a reason to go with a different route and all approaches are effective.

Collapse
 
darksmile92 profile image
Robin Kretzschmar

You got a good point there. For my next project that needs to be hosted, I'll give Heroku a try. Thank you for revising my fears 👍

Collapse
 
avelino profile image
Thiago Avelino

When I do not want to worry about application infrastructures I go to the Heroku, the structy has taken great accounts for the Heroku, the focus of structy is to deliver quality solution and form development team, at that point Heroku has helped us a lot.
It is noteworthy that Heroku is not a cheap solution when the application grows, but is worth the investment

Collapse
 
seanmclem profile image
Seanmclem

Recently deployed my first node server to heroku. It was up and running in minutes with a couple CLI commands. I was amazed

Collapse
 
nikoheikkila profile image
Niko Heikkilä

How is the development pipeline with Heroku working? Do you automatically push to production when a commit is pushed or pull request is merged to master?

Collapse
 
ben profile image
Ben Halpern

Yes, this can be done in a few ways. But we don't really use the pipeline feature because we had already integrated something ourselves with Travis before that was stable release and we never switched. However, I want to consider migrating to the pipeline at some point because it does seem really simple and slick.