Well written. I had never heard of the author or his company, yet unlike so many of the articles that come through here, it had enough context baked in that you could follow it without a Google search.
I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?
It doesn't need that level of hand-holding, really, these days. A few years back it was a bit more difficult. Today the options are well known and really usable by a beginner (eg: passenger).
EngineYard brings a premium service, but none of my customers have been interested to pay the premium. They all go on SliceHost, Joyent, or home-hosted machines.
Sidepoint: around me, most non-rubyists developers don't deploy their apps themselves, whereas all the people I know who work with Rails or Sinatra do deploy themselves. I believe this may be thanks to Capistrano et al, maybe.
The only issue so far ive seen is that there arent any rails/ruby sites that have complex interfaces. Twitter is barebones. ONce theres a site that has heavy traffic and a more complicated interface its possible the perspetion of the technology will change.
None of those have interfaces on par with say amazon or ebay or even facebook. ALthough i know facebook uses mostly ajax anyway. IN fact justin.tv and scribd really are just a cms that pushes the video rather then the site being based around the interface as it is with facebook.
Its not really that important just something that ive noticed. THen again there arent really any java sites that i can think of that are high load sites that have complex interfaces either. Meaning newer sites. MAybe they just arent in fashion anymore. Or everybody is just moving to ajax front ends.
"I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?"
That WAS my experience with Rails, but I'm pretty sure that the problem wasn't due to Rails, but rather the way that our system ended up being architected.
An intelligent setup would have been to have each child site a separate, service-backed (i.e. no ActiveRecord -- that scaled abysmally, and I don't know whether or not it's improved enough for more than prototypes since then, so that part might be outdated now) Rails application. The company common resources like custom Javascript, authentication (ours used a pretty hefty RSA server setup) and style sheets should be hosted in their own Rails app.
Do it that way, and ensure that your developers aren't idiots like the blithering idiot that thought he was an architect (without nepotism he'd have been fired instead of promoted to architect, as his only previous industry experience was as a gopher at accidenture), and you can make a Rails app that's not only robust, but also scales well.
It also avoids the tight coupling problem that the gen-y's and sweatshoppers all seem to love so much.
You decide to add a new feature? Spin up a new Rails app. You need to change the styling? No problem, update them in one place.
Not that any of that is specific to Rails, but even back in 2005, that approach worked well... and the company I was working for might have been successful if we'd stayed that course.
I'm not positive as to what you specifically are referring.
There are easy options for simple apps. As things get complicated, there are managed hosting options that are hyper-specialized to Rails, such as EngineYard.
There was a time when administering a Rails app was a much more hairy proposition than it is today, though.
Ive heard the complete opposite is true. That rails while improved is still a pain to deal with. THe benefit of tails is that theres more and more people using it so theres some expertise out there.
mod_rails/Passenger changed the game on deployment of Rails - Rails deployment is no harder than PHP if you use Passenger/Apache. Most of the 'Rails is hard to deploy' opinions are just relics from the bad old days.
high volume/high availability setups can be complicated, but that's the same all over...
I dont actively follow the rails communitee so maybe what i heard was a while back. I know rails and ruby in general are becoming probably the most actively developed communitee in relation to other languages frameworks. So as you say many of the issues are being resolved very quickly and effeciently.
Im not the biggest fan of rails, i kind of like padrino actually, however i do like ruby and have found some very cool people within the communitee.
Having worked full time in both .NET environments and now in Ruby/Rails, the toolkit in the ruby community is very robust and a far better experience. Any of our developers can do a production deployment with one command and do it with zero downtime. In .NET, it was never as elegant.
The problem is something gets started in the infancy of a framework or tooling and continues to get propagated. The "hearing" rather than "using".
Interesting. I'm a full-time Ruby and Rails developer, and I host/manage a few Rails sites personally. I'd beg to differ with whom you've been speaking. As betageek said, mod_rails makes it a breeze, plus it can be used with either Apache or Nginx.
Like any opinion, people are bound to have different ones. Using something like Passenger, you just put your app somewhere on your box, and add two lines to your httpd.conf, and you're done. I use nginx/unicorn, but it's still really easy.
I found it surprising that Rails needs this level of hand-holding to keep it running though. Rails devs, is this really the experience you have deploying your applications?