Heroku Reviews

You wanna be in the cloud? You have plenty of options. I’ve evaluated or used many of them, so here are a few words about each. (I will include some Java-related comments, as I’m using Java, but most of the things apply to all (supported) languages). But before I go into a bit more details for each service, let me summarize what “the cloud” actually means when it comes to hosting your applications:

• auto-scaling – if there is an increased demand, you automatically get more resources (more virtual machines in most cases) to handle the requests. For the regular application this is rarely useful, but it’s nice to have it and be sure that your service never dies because the load is too high


• pay what you use – simply put, this is in fact the option to choose small servers when you are small, and bigger servers when you are big. The “cloudy” thing here is that you can do that easily, rather than reconfiguring some remote machines


• cloud infrastructure – this is fancy talk for “we deploy these services and take care that they are working”. So instead of installing and configuring a message queue on your machines, you hook up to an already installed and managed message queue. Or database, email service, or cache.


• management tools – you get consoles, command-line tools and web UIs for handling your installations. This is both a plus (the tools are higher level than working with native commands), and a minus (there’s a learning curve)


• load balancers – all services offer these, and you rarely care what’s the software and hardware of the load balancer

The overall plus is the ease of use – you need way less system administration knowledge, and even if you have it, you need to do much less in order to have a real-world-ready application. It is not necessarily cheaper than regular servers (actually, it might be more expensive). But let’s see what each service does:

Amazon Web Services (AWS). This is the most popular option.

• General flow: you create an EC2 instance, which is a virtual machines, ssh to it and have full control. You can bring up and kill copies of your instance whenever there’s higher load.


• Flexibility: since you have root control over your machine, it is very flexible.


• Usability: the AWS console and the Elastic Beanstalk give you very nice UI for managing applications. With Beanstalk you can deploy applications without even opening a console, just drop a war file. In reality you will at least need to provide some configuration though. The best thing is having predefined instance images, so you can have “Tomcat with MySQL” up and running within a minute. There are already nice solutions built ontop of the Amazon API, like RightScale.


• Features: in addition to the basic instance functionality, you have a lot of extras – managed database, elastic IPs, DNS, cloud storage, CDN, mail service, message queue, cache (this one is not that good, btw), etc. So instead of installing and managing these services on your instances, you can use the Amazon versions.


• Pricing – you are charged for the number of hours your instances are running


• Trial: yes, 1 year (a micro instance).

Google App Engine (GAE). This is a PaaS (Platform as a Service), so you don’t get your own virtual machines and are limited in the use of some standard APIs (for example, you can’t spawn threads), and you can’t use a file system (you need the Blobstore API instead)

• General flow: you create an application and deploy it (through command line or IDE plugin). You don’t manage servers and you don’t have ssh – you have just the app. The app runs in a sandbox, and you may need to use some proprietary APIs in order to store to a NoSQL store, use MapReduce, etc. You have less control. You can browse the datastore, view log files and performance metrics via the admin UI, as you don’t have regular access to the target “machine”


• Flexibility: low – you deploy to a sandbox. You are limited to the configurations the admin UI offers you


• Usability: the admin UI is OK (not perfect, but I can’t say something bad)


• Features: fewer extras, but still good ones – email, datastore, task queue, memcached, etc.


• Pricing – generally, you are charged for the amount of resources you are consuming


• Trial: yes, its is free as long as you use small amount of resources

Windows Azure. You get virtual machines, you can use remote desktop / ssh to administer them.

• General flow: you create a virtual machine and that’s it (similar to AWS). You can also deploy simple web sites using php, asp or node.js (which is PaaS, similar to GAE)


• Flexibility: high for the VM, low for the PaaS


• Usability: the admin UI is OK


• Features: caching, database, service bus


• Pricing – fine-grained, pay-as-you-go or prepaid plans


• Trial: yes, 2 months (the smallest virtual machine)

Heroku. Platform as a Service – you deploy an app in a sandbox and have a lot of useful add-ons for other services. You have two types of “dyno” – one that services web requests, and one that services background requests.

• General flow: you download the heroku toolbelt, run it (the latest version fails on Windows though – it installs ruby 1.9.2 and requires 1.9.3, so you have to edit the bat file) and then use it to create and deploy applications


• Flexibility: low, because you run in a sandbox, but each add-on is configurable and there are a lot of add-ons, so it’s better than other PaaS options. The bad news for Java developers is that it only supports deployment by checking out from git, and building with maven. No other version control system or build tool. (there is hg-git adapter, which you can try if using mercurial, but it starts getting hacky)


• Usability: there is a need for command-line work, which is not that usable. The web UI is OK.


• Features: most of the things you can imagine are available as add-ons


• Pricing – you pay per dyno, per database and per add-on (if paid)


• Trial: yes, you get 750 hours monthly for free – this means you get it for free if you have low usage

Jelastic. Platform as a Service for Java only – you deploy an app in a sandbox. You can configure the architecture and use various 3rd party services. It’s not as popular as the other services, but I got an app running quickly (with some useful input from their support)

• General flow: you create an application, choose an architecture via a nice UI (it’s reconfigurable later), and then deploy your war file. You configure the maximum number of servers that you want your application to use. Everything is configured with the web UI


• Flexibility: low, because you can’t ssh to the machine. However, you are free to edit some application server configurations and have a limited, but sufficient access to the file system, you also can configure each of the additional services you use (databases, for example)


• Usability: the interface is pretty good (I’d say better than the rest)


• Features: you can use additional services – MySQL, MongoDB, CouchDB, memcached, building with maven. (The list is way smaller than what Heroku offers)


• Pricing – you pay per application server instance and per additional service (MySQL, SSL, load balancer, etc.)


• Trial: yes but just 2 weeks

There are many other options, notable RackSpace, which is a traditional hosting company, and the cloud options are simply virtual machines with some “cloudy” features, like auto-scaling. I listed only the popular options that I’ve actually tried (I’ve used AWS, GAE extensively, and deployed sample applications on the other three). The evaluation above does not aim to be complete, and I’ve certainly missed some points here and there.

There’s no “winner” – use different options for different scenarios. But it’s good to know what limitations are imposed by each service, and what’s the approach and general mindset. Because, especially with platforms like Heroku and GAE, you need to change the way you think about deployment.

Depending on your needs heroku might get you very far, very fast. I like to use it for clients whose biggest hurdle is not the technology, but in rapidly building a product and iterating quickly. If you already know your customer base, your eventual architecture, and how big your app is going to get, you might prefer to jump ahead to engine yard or amazon, but if you are launching a new app and are still in the process of discovery and exploration, you may find heroku is a good place to start. I work with a lot of small startups and prototype apps, and I think heroku is great for that. Its easy to launch an app quickly, engage users, add new features, scale it up and down as needed, lots of plugins to help you along, while keeping your IT costs reasonable.
Now if the app really takes off, in a sustained way (not just a press-release spike), you will have to decide what changes you want to make to the architecture, and if you have outgrown heroku. I think its great to have Heroku, EngineYard, and Amazon as deployment options. They all have great free options, and each of them has their sweet spot.