On Fri, 16 May 2008 13:34:13 -0700 [EMAIL PROTECTED] 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. 4) NOT ANYONE WITH AN 'A' IN THEIR ACRONYM ON THE PROJECT. No 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 participate. 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/ _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
