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 (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.
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.
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â€.
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.
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: