Weaning Off Heroku (Part 1)
There comes a stage in every application or a point in every developer’s career where one starts considering alternatives to the hugely popular cloud service, Heroku. At my company, we currently have a number of modularized applications running on many Heroku dynos (their name for an instance of a server) — we’re now looking to move these applications on Digital Ocean’s servers running Docker for a number of reasons.
As I looked into how to make this switch, I found that there are a number of resources that touch upon this topics; however, there doesn’t seem one good, solid resource out there that covers how to migrate an application end-to-end. In this mini blog series, I will:
- Discuss what Heroku is and the main reasons for moving off it
- Provide an overview of Digital Ocean and Docker and how they are different from Heroku
- Provide and overview on how to set up a Docker environment on a Mac
- Go into step-by-step detail on how to containerize an existing application in a way that is just as easy or easier than Heroku to use
What is Heroku?
Heroku is a “full service” Platform-as-a-Service or PaaS cloud platform that enables developers to skip the headache and annoyances of provisioning (i.e., getting it up and running) a server and launching an application right away. It is by far, the quickest way to get a piece of code up and running on the web.
The way that Heroku makes this so easy is by having a number of specific system build packs for the most common types of applications. For example, when it detects that you’re pushing a Ruby on Rails application to one of its dynos, it makes sure that the dyno (a.k.a server) is set up with a standard set of tools and system dependencies (as well as the gems listed in your Gemfile). So, it basically does what you initially did with your computer (using Homebrew ) when you first started coding— it provisions the server with a standard set of tools such as Ruby Version Manager, a version of Ruby, etc.
I won’t go into too much more detail here because I’m assuming that if you’re reading this, you’ve worked with Heroku and are now looking to get off. The main point is that Heroku simplifies application deployment because they take away the tedious process of provisioning a server and getting it ready for your application (remember, a server instance without Heroku is just a blank slate with nothing at all on it other than some underlying Linux operating system).
Why move off Heroku?
There are probably a large number of reasons to get off Heroku; however, the two biggest reasons that I’ve found are: 1) the price and 2) the inflexibility of the build packs that are provided.
The Price
Heroku charges quite a significant premium for the ease and speed to deployment that it provides. Take a look at this quick and dirty comparison I put together:
As you can see, Heroku is significantly more expensive than Amazon EC2 and Digital Ocean for the same or lower quality/speed servers. Once you start to grow your application, paying the sometimes 600% markup on Heroku just isn’t sustainable or scalable.
Once you start to scale, Digital Ocean is not only the cheapest solution but also the most effective since it provides large amounts of SSD storage with each of its “droplets” (it’s equivalent of a Heroku dyno).
The Flexibility
Like I mentioned before, what makes Heroku so simple is that its prepares your server for your application so that you, as a developer, don’t have to get into the weeds of sysadmin work. This is great — it allows for very fast deployments and a greater focus on building great apps rather than provisioning a Linux environment. However, it also has its limitations.
Heroku has a number of standard build packs (and users can also somehow build their own as well) that cover the majority of needs. However, if you have an application with a number of system dependencies (i.e., things you have to Homebrew onto your Mac), then the build packs may become a pain to deal with. Sometimes, you just need to get in there add your own system dependencies for your project; however, the downside of Heroku is that you cannot do this.
A Final Word
To close off this first part of this mini-series on weaning of Heroku, I just want to add that all of the above does not mean you shouldn’t ever use Heroku. Heroku is great for new developers as it lets you avoid the headache and frustration that comes with server provisioning and just focus on the important parts of coding. Additionally, it is also very helpful in the development process of an application as it allows you to 1) scale up and down as you determine what your exact needs will be and 2) continuously deploy your application into staging or production environments.
