Heroku is a PaaS platform – supporting a number of web application frameworks including the likes of Ruby on Rails, NodeJS and PHP’s Laravel.
The service was designed in 2007 as a way for Rails (and other web application) developers to deploy their applications without having to worry about underlying architecture & sever setup.
It’s been created to give people access to “single click deploy” functionality – allowing them to essentially provision and deploy server “instances” without the need of having to be concerned about how the infrastructure will work.
This tutorial explores how you’re able to use Heroku for Ruby on Rails application development.
The most important thing to understand is that it’s a “closed” platform.
In an attempt to be as easy-to-use as possible, the team decided to remove *any* sort of specification from the system. This means that it’s tied into Amazon’s EC2 platform, and basically prevents you from being able to deploy your software to any other platform through its interface.
Whilst “provider lock in” may not be a huge issue in itself, it does highlight the core problem with Heroku… it’s a platform not a service. Being a platform means that Heroku controls every aspect of the deployment process – from where you’re storing your data to how much resource usage you have.
This means that little problems – such as *always* having a “x.herokuapp.com” subdomain available for your app, paying PER APP (which can get very expensive), being unable to change your app’s location, are a massive issue.
Furthermore, Heroku’s deployment process is very rigid. This means that you cannot change things such as “location”, or even have multiple frameworks / platforms running under an application. Whilst it has “buildpacks” (which are very good) – they require you to hack together the various pipelines you may have into one central build process.
Because of these restrictions, many developers have cited the system as being effective as a “staging” environment… but in many cases bad for production. Production environments require scalability and extensibility on a core level (if you get traffic spikes, or are looking to launch in other countries – you need the ability to do it).
Whilst Heroku does have these to a degree, its lack of granular settings makes it very difficult to justify using as a production service. This is amplified with the system’s application-centric pricing structure.
The way around this is to ensure that you’re able to use a system which is as flexible as required. Heroku may suffice in this respect for many beginner developers (who just need their app to run no matter what), for some seasoned developers (who may require a more individual system), the likes of “cloud” VPS services tend to offer a more appealing ideal for production level web application provision.