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...
Happy coding!
Top comments (27)
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.
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.
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?
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.
Thankyou!
Hey Ben, what's your current monthly cost for running DEV on Heroku?
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.
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. 😁
At what kind of traffic? Daily impressions, etc?
Wow. Very impressed with the low spend.
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?
What? How is it exposed?
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.
Who would send one, one?
A private space costs $1000/month. Even a CEO wouldn't pay for that much for his/her side project.
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.
If you're a student I encourage you to look into their educational discounts. They're quite generous.
heroku.com/github-students
Love the transparency, my dude!
I always thought DEV.to was on Digital Ocean.
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.
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.
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.
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 👍
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
Recently deployed my first node server to heroku. It was up and running in minutes with a couple CLI commands. I was amazed
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?
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.