As I write about Heroku every week, I’ve come to build up a substantial following on dev.to, Twitter, and Reddit. These communities my work is immersed in are shaped by reciprocity: we learn from one another. Often, people offer helpful insights in the comments and raise points I hadn’t thought of previously or in the same way. Recently, I have learned three main things:
- My view of the development ‘scene’ is incredibly U.S. centered. I wrote how everyone uses a MacBook, while developers in other countries (and that’s most developers) have rarely seen them in use.
- People on r/programming can be jerks!
- There are a lot of misconceptions around Heroku!
I know I already wrote a whole article tackling common misconceptions about Heroku, but 6 months later it’s time to revisit the topic once more, and this time one that comes up the _most _often.
“If you deploy your app on Heroku you’re stuck with Heroku forever”
The concern here, even if it doesn’t mention the term, is the dreaded “vendor lock-in.” While I will argue that lock-in isn’t a concern with Heroku, I’ll allow that lock-in is a scary thing! Since the days of room-sized mainframes, there have been companies who found themselves inextricably linked to the computing services of a single vendor. If businesses in the 1960’s chose IBM, they commonly found their bills increasing every year. If they chose someone other than IBM, their vendor often folded suddenly, leaving no plan to service their vast computers, and a remaining stack of programs that couldn’t run on anyone else’s machines.
Vendor lock-in is very scary, and that is exactly why you should use Heroku.
Applications on Heroku are more portable than apps you run anywhere else, even your own server
Not only does Heroku _not _use any ‘secret sauce’ —no proprietary SDK’s, no obscure storage systems with no ability to export— but Heroku also forces you to create an app that’s ready to go anywhere.
A common presumption by developers is that the most portable format is self-hosted apps. Even if you’re using a hosting service for your machine, you can easily move to another host, right? Here, the concern arises when we delve into the poor design of most operational structures.
Let’s talk about 12-factor apps
The 12-factor app is a design for applications that scale easily and are easy to move. The design document was authored within Heroku and has seen broad uptake in the rest of the industry. Looking through the factors you can also see how things can go wrong.
A significant cause of friction when trying to move apps is de-facto dependencies or config:
- “Oh yeah you have to copy over the New Relic config.yml”
- “One of the processes requires imagemagick so install it after you re-image”
- “We set up a server with an older version of [X dependency] because if you download the latest version there are compatibility issues”
These issues are all examples where poor design puts pressure on the humans in operations to remember special settings, implement workarounds, and generally do manually what our tools should do automatically.
What if good design was implicit?
While I feel that all the 12 factors are a great design goal, thinking about Heroku in relation to these goals brings a pleasant surprise: you meet many of these requirements automatically when you use Heroku.
Explicitly state your dependencies? Because Heroku Dynos require a list of dependencies (e.g. a package.json for your Node app) and don’t allow you to sneak into the machine and install components de facto, there’s no way to have a working Heroku app that doesn’t have explicitly stated dependencies.
The same goes for the requirement that all your code be version-controlled. Heroku updates happen via version control implicitly.
A lot of Heroku’s magic comes from good design
Why is it so easy to scale your services with Heroku? The enforced 12-factor thinking really helps. Without any fiddly requirements for human tweaking, it’s less painful to spin up a large number of dynos to take additional requests.
Heroku is a great platform, one with a multitude of neat tools not available in a self-hosted platform, and if you ever need to leave, your app is already set to travel—it’s all ready to travel, it just needs you to customize one procfile to adapt to its new home.
Top comments (0)