Moving from Amazon EC2 to Heroku

Recently I’ve been making the transition from my own Amazon EC2 server to Heroku. I’ve had some experience in the past with managing servers, but ultimately, I’m a developer, not a sysadmin. This meant that I was constantly hacking together a server that worked, but it never ran particularly well.

1&1

I started off on 1&1 a couple of years ago with their largest Linux VPS for my WebOS (remember that?) application, Weatherman. Because of the sheer number of users of the app and the fact that I was generating images on the fly, obviously, shared hosting was not going to be adequate. The problem was, the particular server I bought was severe overkill in the long run. During the launch of the app, the server was worthwhile and I needed the power. But over time as the WebOS platform faltered and the number of users of Weatherman decreased, I was stuck with an overpowered server that essentially broke even.

Amazon Elastic Compute Cloud

Eventually, I switched to Amazon EC2’s Micro instance, which was more than enough to serve the remaining users of the app. As a bonus, being a new Amazon customer, the entire first year was free. Going from $720 a year to absolutely nothing in server costs (save for a few bucks in bandwidth) was certainly a worthwhile investment of my time. But like the 1&1 instance, the Amazon server was hacked together to work. There were only tens of remaining users at the time, so running efficiently wasn’t necessarily a top priority.

Heroku

With a few projects in the pipeline that require reliability, I’ve decided to switch the majority of my stuff to Heroku, including TI Wizard, which has been running on 1&1’s shared hosting since 2008. In fact, the only remaining reason I have an account with 1&1 is because of the domains I’ve purchased over the years. Even then, I absolutely hate 1&1’s domain management– it literally will take the entire 48 hours they estimate for DNS to propagate or several hours for a subdomain to register. I also have a few domains with Namecheap and they’ve been fantastic. It took literally 2 minutes for a new domain to be registered and under my control, and mere minutes for DNS to change to Cloudflare, on which changes are virtually instant.

Anyways, it’s Heroku’s simplicity that I love. I can go into the terminal, type heroku apps:create [appname], and I have a new dyno (essentially, a virtual server) ready and provisioned for my new application. If I need to show progress of a website to a client, I can create a new app and shut it down hours later for no cost at all.

Heroku allows for Node.JS, Python, Clojure, Scala, Ruby, Java, and PHP, along with custom build packs that let you use even more languages. Plus, they provide a free PGSQL database with up to 10,000 rows (or 10 million rows for $9 a month). Really, it’s everything you could need to run the majority of applications with the flexibility to upgrade capacity and add additional dynos with a single command in the Terminal.

The Downsides

There are a few annoyances with Heroku. Primarily, you have to design your application with a read-only ephemeral filesystem in mind. In other words, any files you store on your server will disappear after the server is shut down, and it is not guaranteed to be on other servers your application is running on. For most applications, you should probably treat the file system as read-only or for temporary storage only. This is good practice anyways because it allows for scalability, but applications like WordPress (there is a Heroku-specific configuration available maintained by the community and myself) that use a directory within the installation to save images, even temporarily, need reconfiguration. In this instance, a plugin to automatically move images to Amazon’s cloud storage service is used to ensure the images’ availability across all application instances.

Overall, moving to Heroku has been a great cost saving measure. I can essentially run the majority of my applications for free (minus Amazon CloudFront fees for hosting images) and have them managed by a team of experienced system administrators. It’s a win for my websites’ reliability and I’m definitely looking forward to launching some bigger, multi-dyno projects on Heroku’s platform in the future.

Updated to reflect Heroku’s ephemeral file system– not read-only

Subscribe to my mailing list

Get my latest posts delivered directly to your inbox