Heroku platform for scalable web applications

I’m so locked up in my own java world that I didn’t realize something as cool as this existed in the ruby world.

Heroku is the instant ruby platform. Deploy any ruby app instantly with a simple and familiar git push. Take advantage of advanced features like HTTP caching, memcached, rack middleware, and instant scaling built into every app. Never think about hosting or servers again.

From a layman’s point of view, Heroku looks like a ruby version of GAE image(Google app engine). It has some of the same features as GAE.  But unlike GAE, Heroku actually talks about their architecture in great detail.

They use Nginx as the front-end HTTP reverse proxy server and Varnish for the caching right behind Nginx. They wrote their own custom software to “route” requests between the web frontend and the backend services. The actual user code runs on the “Dyno Grid” where each dyno looks like a self contained ruby instance with user code (compiled slugs).

There could be multiple “dynos” on the same server, and a user application could use up multiple “dynos” on same or different servers. Since each“dyno” comes preconfigured with information about user’s database and cache connection information there is absolutely nothing else (configuration wise) “compiled slugs” need to do its job.

image

The “routing mesh” tracks detailed performance data for each of the apps and load balances as required. An unresponsive “dyno” is marked and replaced automatically. Based on the documentation they can initialize new dynos in about 2 seconds.

image

A dyno, incase you are curious is a single process running your code, somewhat like a jre container. And it looks like they put about 4 dynos for each core (CPU) they have on a server. The POSIX view of the system available to the ruby vm is read-only, and though they don’t use OS virtualization to separate each dyno, they do seperate them using “unix permissions”. I guess that means each dyno has its own unique userid/groupid pair. I don’t have much experience with ruby, but for those who care, they use “plain-vanilla MRI ruby”. image

Just like how GAE/Pyhon uses a stripped down version of Django and GAE/Java uses stripped down version of Jetty as their app server, Dyno uses a thin version of Mongrel. It also uses “Rack”/ “Rack Middleware” for apps interaction with Mongreal/webserver.

Now here is another interesting implementation choice they went with. To update your apps all you have to do is check in your changes using “Git”, and the Heroku will take care of compiling your slugs and deploy it for you. I wish GAE was like this.

The pricing looks slightly higher than raw EC2 cost, but you need to understand that Heroku is Platform (PAAS) and not Infrastructure (IAAS). They take care of the stuff you would otherwise have to struggle with if you were on AWS.

They also have some pretty interesting “Add-ons”. The one I liked was “Websolr” is a custom implementation of “solr” full-text search engine which is in turn based on lucene.

I’m curious if any of you have used Heroku and comment on what you feel about it. The devil is in the details.

Related interesting Links:

  1. http://highscalability.com/heroku-simultaneously-develop-and-deploy-automatically-scalable-rails-applications-cloud
  2. http://sazbean.com/2008/05/29/interview-with-james-lindenbaum-ceo-of-heroku/
  3. http://ec2onrails.rubyforge.org/

Comments

Popular posts from this blog

Chrome Frame - How to add command line parameters

Creating your first chrome app on a Chromebook

Brewers CAP Theorem on distributed systems