| "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. |