We recently migrated our corporate website from ASP.NET 2.0 to Rails. I am putting together a multipart series on migrating from ASP.NET to Rails, but in the meantime I thought I’d share some tidbits that I’ve come across that hopefully can help people who are otherwise scouring Google and the interwebs for information on how to fix arcane problems.

I have made a decision to deploy all of my Rails apps on a combination platter of the following delicious ingredients:

• Debian Etch – because I like the way it works with my homeboy, Apache 2
• Apache 2 – because its safe, it makes me feel good, and I really like the enormous amount of documentation available for it
• mod_proxy and its sibling, mod_proxy_balancer, because they aren’t afraid to work with the workhorse (I should say, work-dog), mongrel
• mongrel, via mongrel_cluster – because its fast, it always works, and it is becoming the de facto Rails server.

So this is my “platter” (stack is so overused). I like it. I can understand it. It makes sense to me. In .NET/Microsoft/IIS parlance, I think of it this way:

• Apache 2 is like IIS — duh
• Mongrel is like aspnet_wp.exe – aspnet_wp.exe is the ASP.NET worker process that executes ASP.NET code. Kind of like mongrel executes Ruby on Rails code
• mod_proxy_balancer is conceptually similar to the ASP.NET worker process pool (as configured in the MMC under Application Pools), in that it handles the distribution of requests from the container server (IIS or Apache2) to the worker process (aspnet_wp.exe or mongrel). I know in reality it works nothing like this, but if you think of it this way its less scary and shows how much more control you have when working with this stack vs. ASP.NET.

I was first perplexed by the single-threaded Rails model, then I realized that with the power of proxying processes, you can determine exactly how and where your application scales.

With IIS and ASP.NET, you have a black box around the how you scale your processes within your application. Sure, you can set the maximum number of threads and some limits — but you essentially have very little control of how your distribute load. With mod_proxy_balancer, you can determine not only how you are going to proxy (for example, in my platter of services I choose to let Apache2 serve up html, php, images, etc) – but also where your application serves from. Try doing this in IIS / ASP.NET – you’d need to whip up some fancy distributed / remoted .NET architecture to even think about it.

So I can scale within my server by adding more mongrels with mongrel_cluster, and I can scale outside of my server by spinning up more mongrels on another server, without having to deal with anything fancier than IP addresses and ports. Neat.

PS – Before you think I drank the Kool Aid too quickly, I realize that IIS / ASP.NET is a hardened stack and works really well and can scale, and is great for lots of things. But the more I learn about this open-source stuff, the more I think you can achieve the same ends for lower cost, lower frustration, and higher level of satisfaction in your workaday development and prototyping activities.