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

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

Heroku vs self-hosted PaaS

Magnus Skog Jul 18 13 min read

#heroku #hosting #selfhosting

Happy coding!