PaaS isn't the end-all-to-be-all.

Posted by Matt Farmer on November 19, 2012 · 4 mins read

I ran across this article while browsing on Hacker News that’s suggests the following idea for webapp development: “If you’re not building a PaaS, you should deploy on a PaaS.”

I feel the need to point out (because I’m an incredibly opinionated person) that I strongly disagree.

So, first, for my readers with a less technical background it’s helpful for you to understand that PaaS stands for “Platform as a Service.” It’s essentially providing all of the various things you need to run an application in a production setting (web server, database, etc) as a service. So you pay a service like Heroku a monthly fee, give ’em your app, they hook you up with everything you need.

Now, for the record,  I think services like this are great where engineering time is scarce, flexibility isn’t required (read – most Ruby on Rails and Node.js development), and you can swallow the price tag. I even use the free tier of Heroku for my Hubots. But there are a good number of situations where it doesn’t make quite as much sense.

  1. You’re on a budget. I’m technical lead for Anchor Tab, and while I think our product is going to be successful, I can’t neglect the fact we’re on a budget. I can run a production server with Anchor Tab, with everything it needs, for the ballpark of $30/mo – including all the goodies. (Either on a Linode in the minimal situation or using some combination of AWS reserved instances and my existing infrastructure.) The minimal setup for Anchor Tab on Heroku would be at least $50/mo, assuming we only need two web dynos and a 2GB MongoDB database. (You can do it a bit cheaper if you can skate by with 16MB of database, but I’m skeptical we could pull that off.)
  2. You’re hacking on your own tools. Our Director of Engineering for OpenStudy, Antonio, is a Lift committer. For that reason, and many others, it’s not entirely uncommon for us to run OpenStudy on an experimental version of Lift that may or may not already be on Maven Central. We’ve also had situations in the past where we’ve had to do our own hacking before the changes were pushed up to any repository. Using PaaS, we wouldn’t have had this freedom. Additionally, if I need to hack on a gem on a rails production server where I have full access, I can. Granted, it’s bad practice to do so – but sometimes you need to.
  3. You can’t live within the parameters. When Heroku asks your app to shut down by sending it a TERM signal, you have ten seconds to do what you need to do and spin down before Heroku forcefully shuts you down. There are also maximum memory requirements (512MB per Dyno on Heroku). Sometimes, requirements like that just don’t work for the application you’re building. All of the PaaS companies have rules like this you’ve got to follow. Requirements like this wouldn’t work for OpenStudy without scaling over a lot of dynos (thus costing us a lot more money than we’re paying to AWS).

These are just a few situations that come to mind. As I said, PaaS is great. You don’t have to worry about server maintenance and other things of that nature that distract you from your actual work. However, it’s not the end-all-to-be-all and it never will be because to truly provide a platform as a service in a consistant, performant manner there are always going to be artificial restrictions added on top and a fee for the additional automation. Therefore, some business and use cases will always be excluded.