I’ve been using Heroku since I started as a developer. Heroku’s simplicity, ease of setup, and lack of complex configuration make it an amazing resource for beginners and experts alike. Like many others, I’ve had a lot of success taking apps to production with it. But the needs of a team and an organization are complex, there are a lot of reasons why one might want to move their application away from Heroku. For me, this process has been easy and I’d love to explain how Heroku apps are inherently portable from the start.
A persistent misperception about Heroku is that you are stuck with it for life if you choose to serve your app from Heroku initially. Heroku is massively simple to run at scale, meaning a lot of developers do go from hobbyist to high-volume all while using Heroku, but this is a choice. Heroku requires very little from developers in order to get up-and-running and this approach carries over to the process of migrating to another service as well.
- Getting Started With Heroku: Easy In, Easy Out
Before raising the question of how one might leave the Heroku platform, it’s helpful to look at what is required to start using it in the first place. If we have an app running locally, on our laptop, what do you need to add to the app to make it run on Heroku? Not much!
Take the deployment steps for a Node app to see this simplicity in action. A developer can run “npm init” on the app, proceed to add a dependency (or a number of dependencies), and deploy it. If Node isn’t your tool of choice, you could do the same thing for a Rails app or any other project that’s written in a language that Heroku supports. There are no platform-specific frameworks needed to use Heroku.
- Portability In (Best) Practice
A lot of the potential headaches involved in porting applications away from Heroku can be avoided with solid coding practices. Heroku’s system actually encourages you to create a more portable application: by favoring procfiles that control how your app runs, and databases for any and all data storage, your Heroku container (dyno) is already packaged and ready to travel. Similarly, it’s recommended to split up long-running tasks and have a background job handle them. Heroku is versatile enough to host applications without including these elements in all cases, but following guidelines like these will make it easier to move towards another service in the future. You can read more about best practices as they relate to Node here.
- Versatility In Usability
As you can see, a lot of Heroku’s versatility lies in the fact that it can do a lot with a little. Porting an app away from Heroku might seem like a daunting task when you consider all of the things that need to be involved in order to gain utility from other platforms. Conversely, this lack of necessary configuration is what makes Heroku so great. As long as good coding practices are considered as an application grows in size, portability and usability will remain easy and straightforward.
- Heroku’s containers mean maximum flexibility
When I hear about being locked into Heroku, it’s hard to resist the urge to chuckle. Moving from one platform to another is always a complex process, and no platform has any single feature that makes it superior to all others for your application. Platforms with great automatic scaling won’t have the most predictable billing, and platforms with dead simple permissions settings will need to have team practices to cover edge cases. Heroku is a flexible tool and you might be using it as a lone developer with a simple high-volume stack, or a large team with hundreds of different stacks in flight. Your specific profile may make another cloud service more appealing than others.
An article I’m working on for next month will look like a ‘choose your own adventure’ decision tree for selecting a platform. I’ll add a link here when it’s out :)
In the meantime, take some time to dispel some Heroku myths with a great video series covering the realities of using Heroku.
Full disclosure: Heroku paid me to write about this topic, this is a dream job for me because I’ve loved Heroku since I first started in web development. Since I have to use the tools I write about, no one can pay me to like something, and the views here are 100% my own.
