I am being reading the Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rail. There are number of interesting things in there that I would like to quote.
First most notable is COST. ASP.NET MVC and thus Microsoft stack is pretty expensive and you cannot always justify the cost:
RB: If the platform [ASP.NET MVC] was holding up fine, what prompted the change of architecture?
RC: Money. We were enrolled in Microsoft BizSpark Program and it was great for getting off the ground, but projecting into the future we realized that everything - from our database down to our development environment would have to be paid for after 3 years. This might not be an issue for a large company, but when we sat down to assess what the bills would be - well let’s just say that it was about 5 figures. We put our business hats on and tried to justify that cost - and we couldn’t.
Additionally the tooling around Ruby On Rails is just great:
RB: Why did you choose Ruby on Rails?
RC: It’s what James and I both knew, and the plug-in story is very compelling. For instance - New Relic is a god-send. I don’t worry about the server freaking out, and I can see the "choke points" of all the code. They also track the highest-occurring queries and will even suggest improvements.
MongoMapper is an incredible data tool and MongoDB itself is faster than lightning. The Rails platform has matured to the point where it’s almost difficult to justify *not* using it.
JA: All the problems we had (licensing, testing, deployments) could have been overcome. We could have used workarounds, written our own deployment framework, etc. What is comes down to is that we both really enjoy working with Rails and we enjoy the Rails community and the tools and libraries available. One of the best parts about running the show is that we get to do what makes us happy.
And the benefits seem to be huge. I am looking at that from the perspective of a TDD developer:
RB: What immediate benefits have you seen from the rewrite and the new design?
RC: Immediate - the first thing people notice is the speed of it all. They also notice a bit of a "tighter" design which we were allowed to focus on a bit more as the server-side stuff is really trivial, to be honest.
Not only that - but we’ve had some issues that we were able to iron out within seconds as the deployment story is so very, very simple with Capistrano. Issue a fix and push - takes seconds.
Our testing suite grew tremendously as well - Cucumber is a joy to use and lets you do some things that are a bit hard with ASP.NET MVC. For instance - testing PayPal’s IPN posts are pretty tough with ASP. It’s possible to do - if you create a FormCollection and push it through - but couple that with the anti-forgery protection and the story gets a bit more difficult.
With Rails/Cucumber/Webrat, it’s a matter of filling out a hash and posting it….
JA: The most immediate benefit has been the speed at which we are making changes and pushing them up to production. On the ASP.NET MVC site I would often write SQL scripts to handle complicated support requests, like changing someone’s OpenID or combining accounts, but now I just spend the 30-60 minutes to write a couple of lines of Ruby and push it up.
And of course I could not miss quoting the comparison of Microsoft-based technologies with Ruby-based:
RB: How does your current testing methods compare to what you had on Microsoft?
RC: 100% difference. It was a pain to test with the Microsoft stuff and when you’re poor and have 3 months until the money runs out, testing is something that you have a hard time justifying… [Then talking about ASP.NET MVC testing]… So I had some tests, but nothing to gives me the comfort I wanted. We did wrap the PayPal stuff in a ton of tests, you have to. When it comes to their API and I torched their sandbox environment for 3 straight days and STILL had issues rolling live.
JA: Microsoft testing is always a fight, mainly because C# and static languages don’t lend themselves well to testing. It always feels like you are jumping through hoops when testing on .NET. That being said the SpecFlow framework on .NET does look very promising, but I doubt it can overcome all of the drawbacks of testing in .NET.
And this is probably really what it means to be Agile:
RB: What lessons or takeaways have you gotten from a total redesign?
RC: None really - I think both James and I knew that we’d hit a point where we would need to adjust and rewrite…
We were lucky in that the idea took hold - we then moved into "OK let’s plan for the next 3-5 years and go into controlled-growth mode" - which is where we are now. We don’t want to be huge, we don’t want IT people or a group of developers who work on stuff. We want to do it ourselves and stay small - focusing on the idea that got us here.
And the lessons learned are just a ton of satisfaction:
RB: Do you see any weaknesses to the current architecture? What would you change if you were starting over again today?
RC: Nothing on my end - I love it all. It’s weird for me - I’ve been a Microsoft person for a long time but putting on my business hat… well it just doesn’t make any sense at all for us. I like the idea that scaling comes at the cost of hardware - and it will be a really long time that we’ll need any. Our servers are essentially "liquid" and we can buff as needed. Can’t do that with the Microsoft boxes (from what I know) and if you try to latch on separate machines, you end up with a big bill.
JA: The only change I would like to the current architecture is to break out MongoDB from our single server, it makes sense to run MongoDB in a pair whenever possible but with replica pairs being depreciated it makes sense for us to wait on the MongoDB team to develop their new pairing strategy and start with that. The cost of an addition two VMs and the fact that everything is running fine on our single server also deters us from doing this right now.