[Mongrel] Some architecture questions for my mongrelian friends

Zed A. Shaw zedshaw at zedshaw.com
Fri May 16 17:12:42 EDT 2008

On Fri, 16 May 2008 13:34:13 -0700
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 glad I don't post here that often.  I'd ruin the friendliness. :-)

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

Ultimately it'd depend on what the application does and what they need
from a rewrite.  If they need maintainability, then I'd say no, you
should work to move them on to .NET so they don't have to retool
everyone.  From my experience, you'll run into insane amounts of
politics unless all the developers from inside the company are the ones
coming forward asking for a transition to Ruby.

If they just want to modernize and are willing to relearn how
deployment works, management, and coding practices, then I'd say it's
worth a shot.  Any language will be better than what they have, but
honesly they should evaluate all the potential options using a rubric
to make sure they cover everything.

Now, if your question is, "Can Ruby handle this kind of load?" then you
didn't ask the question right.  Let's break down your 3M pv/month
metric into requests/second (the actual measurement you need).  That
comes to effectively 34 requests/second on average.  Now, I'm betting
you have a peak time like everyone else, so if your peak is about 4x
this mean then that's 120 request/second, which a decent Rails
application can handle.

Still, you should go look at your web server logs and get a better
understanding of the traffic patterns.

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

Yes, that's what I recommend.  Switching to Rails for them would be a
nightmare.  They'd have to ditch all of their existing knowledge,
technology, and platforms to go with the new stuff.  It'd be a whole
rewrite with no prior knowledge.  And I know the existing devs will
revolt, system admins as well.  Actually, the system administrators
will just have to be replaced.  It's rare that an MCSE windows admin
has the chops to change over to unix system admin.

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

That's why I recommend the rubric with a shoot out.  Get the devs
involved in coming up with what's important and finding it.  It's a
pretty simple process and should only take a week.  You might be
surprised to find that there's a tech out there that makes the business
just melt.

> 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?

Yeah, you're screwed.  The dual problem of logic in the DB (which Rails
HATES) combined with the fact that this means the DBAs control the show
and they're always morons.  Sorry to say it that way, but I have yet to
meet a DBA who is worth two shits and can't be replaced by a good
script or two.

Hell, I've replaced entire departments with a good script or two.

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

Yep, that's possible but probably not the smartest way to do it.  In
fact, if you have to do this splitting of requests then it's a bad
decision.  Be honest with yourself and ask if this is the simplest
thing they could do.  It's not, so go find a simpler migration path for
them and help them deal with that.

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

I'd say run but help them realize why you're not the right guy and who
to get with for the next steps.  Honestly if you can help them spend a
week or two picking the right technology that fits their business and
existing setup then you'd be saving them so much money and could at
least make a bit of extra.

As for actually doing migration projects, I'd say my experience is they
do NOT work unless you have the following:

1) A project champion who fires half the staff as an example of what
will happen if anyone fucks up his project.
2) A project lead who focuses on the quality of the code and can have
anyone above or below him fired by #1 for fucking with his project.
3) Developers who have knowledge of the past, and another bunch who
don't and aren't afraid to call bullshit on the first batch.  If you
don't have people going around saying "WTF!" every two minutes for at
least a month then you have the wrong team entirely.  If you don't have
existing people going "WTF!" at the new guy's dumbfuck ideas as well
then you don't have the right team.
Database Admins, System Admins, Software Architects, Business Analysts,
Or MBAs should be near the fucker until it is ready to deploy.
5) Embed the champion from #1 or someone with just as much on the line
into the team every day for the whole work day and make them
6) Don't move until you've done a full UI design on paper and had a
grahpic artist work it all out.  If #1 doesn't have this before even
talking to you he's fucked.  If this requirement is satisfied by the
existing site then that rocks.

Other than that, these projects always suck, are always full of
politics, are always budget sucks, and you don't really make as much
money as you think you do.

Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

More information about the Mongrel-users mailing list