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?
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?
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.
Big, heavy traffic apps require special attention, but then that's the same for all big/heavy apps.
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.
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.
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.
high volume/high availability setups can be complicated, but that's the same all over...
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.
The problem is something gets started in the infancy of a framework or tooling and continues to get propagated. The "hearing" rather than "using".