[Mongrel] Some architecture questions for my mongrelian friends

Geoffrey Clements baldmountain at gmail.com
Fri May 16 22:48:52 EDT 2008

There are some interesting issues beyond just the engineering here.
The main ones have to do with how happy the company is with their site
and the technology it uses. If they are happy then maybe they will be
completely satisfied with moving to a .NET type site.

But then you need to look at Microsoft and what their priorities are,
Let's face it, Vista hasn't been particularly successful. You almost
get the feeling that Windows is a cash cow that M$ will milk for as
long as they can, but they are going to move onto other things...

You also need to talk to the engineering staff and see how they feel.
Maybe give a presentation on Rails and see how it goes over. If the
team is intrigued, or better yet, excited, then A Rails application
may be in their future. If it is met with cold stares then it would be
best to move on.

On Fri, May 16, 2008 at 4:34 PM,  <public at misuse.org> wrote:
> Hey,
> I'm working on a project, and mongrel may be part of the stack, but I've got
> some more general questions and ideas I'm hoping to run by this list. The
> people on this list have a broader knowledgebase and more experience than
> any place else I know - plus a general friendliness and willingness to help!
> I'm working with a company who has a really antique application stack.
> Literally from 1998. IIS + ASP + MS SQL server. They want me to help
> "modernize" things. In the abstract I'd say, "get a really good .NET team
> and go that route." But they want me to help. All I work in these days is
> Ruby. And that's all I want to work in. :)
> So my questions are like this:
> 1) Can I in good conscience start migrating this company from IIS/ASP to
> Mongrel/Ruby/Merb/ORM (or something like that)? They have roughly 2-3M page
> views per month.

I would consider a nginx/Mongrel/Rails app. The learning curve is a
bit lower and Rails will handle a lot of extras that Merb will not.

Also consider using Rubber and hosting on Amazon EC2. Rubber makes
using EC2 a piece of cake and it is easy to add instances when your
traffic increases. Plus it pushes the responsibility of managing
server farms and the connection to the internet to Amazon.

> 1.a) No matter how good they think I am, wouldn't it be smarter to move
> forward with M$ since that's what they've got already? I don't want to be
> the guy who screws them deeper into the hole by really confusing their
> stack.
> I hate it when new dudes come in with their "stack" and bias development
> based on their preferences withou considering what's already there. I'd
> rather walk away from this if Microsoft is really their odds-on smart choice
> (i.e. I don't need the money - I have some personal relations that led me
> here). All I want is the company to be successful.

See above...

> 2) Their MS SQL setup is relatively fine. Lots of wacky stored procs which
> bug me but mostly it's fine. Am I crazy to try to run MS SQL against
> Ruby/ORM? Seems like there are some people doing it?

They may need "wacky" stored procs because IIS and ASP was not up to
the task. You need to evaluate what they were trying to accomplish
with those "wacky" stored procs and see if they aren't standard
features in Rails.

> 3) If I do this, I'd plan to segment this site into two separate boxes and
> run the Ruby on a Linux box (and maybe outsource that management to a group
> like EngineYard). Then have the LB's split traffic between the boxes based
> on url patterns. Again: crazy? unwise? Currently they're at rackspace which
> knows poodle about Ruby/Mongrel afaict.

No idea.

> Context: The front-end site is not impossibly complex. But there is "deep"
> integration with some backend admin processes which run a large part of the
> business: some crm, PPC, finance/accounting, email and billing: all
> partially implemented and built in hand coded ASP. It's a real tangle and it
> breaks all the time right now. I want to get most of these processes out
> into third party systems with much narrower points of contact between the
> production DB's and the specific admin services. This can only happen
> incrementally over time. This is in addition to the front-end websystem
> migration.
> Budgets for this work are not tiny but not enormous. Ditto timeframe. Maybe
> $250k over 6-8 months.

Rails, especially if you drink the Koolaid and follow the patterns, is
a RAPID web development platform. Since we don't know what you are
trying to accomplish we can't judge whether you'll be able to meet
this budget and time frame. But with Rails you are more likely to
succeed than with any other platform.

> Any tips or advice on taking on large migration projects such as this would
> be appreciated. Advice such as "run!" is welcome also. I realize there are
> no definite answers - I'm just looking for experience or advice on how to
> reach conclusions here.

Sorry. I've been lucky to start new projects so I have no idea about
migrating an old app to Rails.

> I realize this is horribly off-topic and impossibly vague. And I wouldn't
> ask for this input, except that I highly admire and regard the capabilities
> and experience of many people who are on this list. I can't think of a
> smarter mail list who could help advise on this. Any assistance at all will
> be greatly appreciated.
> Thanks!
> Steve
> p.s. Anyone who has possible interest in this project professionally can
> also contact me directly off-list.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


More information about the Mongrel-users mailing list