BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rails

Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rails

Bookmarks

TekPub is a web site devoted to developers, giving them a source of focused on-line training in various topics from Microsoft Entity Framework to writing your own blog engine using Ruby on Rails.  The site was created by ex-Microsoft employee Rob Conery with The Lounge owner James Avery.

TekPub is an interesting study in a company who started on ASP.NET MVC and quickly moved to Ruby on Rails.  InfoQ had the opportunity to talk with Rob and James about TekPub and their journey from using ASP.NET MVC to Ruby on Rails.

Rob Bazinet (RB): For readers who are unfamiliar with your product, tell us about TekPub?

James Avery (JA): TekPub provides high-quality technical screencasts for programmers. Our goal is to help someone learn about a new technology in a couple of hours by watching someone who is very familiar with the technology not only cover the basics but also dive deep into using the technology in a real-world application. Instead of waiting months to get a book that is most likely already out of date, our subscribers can get the jump on a new technology right away. We have already finished our ASP.NET MVC 2 screencast series and there still isn't a book out on the subject.

RB: Who is James Avery and Rob Conery?

JA: I run a couple of technology startups in addition to TekPub. I run The Lounge and Ruby Row advertising networks, focused on .NET and Ruby developers respectively. I also help run DotNetKicks, a community site for .NET developers. My latest focus is Adzerk which is the web server I built to run The Lounge and Ruby Row available for others to use. I got started on the web in the mid 90s and moved to Microsoft technologies when .NET launched. Lately I have been using .NET, Ruby on Rails, MongoDB, and whatever else strikes my fancy.

Rob Conery (RC): I've been working in the software industry since 1991, doing the typical mundane database/CGI/HTML stuff. I crossed over to ASP in 1997 and have stuck with Microsoft stuff since. In 2006 I went to work for Microsoft and focused on helping people learn and use the new ASP.NET MVC framework. I left in 2009 to do some different things (more focused on Open Source platforms) and ended up founding Tekpub with James Avery.

RB: Would you explain the architecture of TekPub on launch day?

JA: The first version of TekPub was a Ruby on Rails application Rob threw together in a weekend. We talked it over and realized it needed to be scrapped and since we both knew ASP.NET MVC inside and out we decided to go with that. I am firm believer that starting a new business is not the time to also try and learn a new technology. Rob and I had both written and deployed Rails applications in the past, but when it came down to it we both knew ASP.NET MVC much better than Rails. So we scrapped that and put together an ASP.NET MVC site. We later scrapped that site and re-built it because it was getting too complicated. When we launched, it was that third version that went live. It was ASP.NET MVC, C#, and MS SQL Server. 

RB: What challenges did you see with people using the site and from the perspective of you managing the site?

RC: Initially, on the very first day, it was our bandwidth. We announced on Twitter and it buried our ISP due to the bandwidth demands. They literally had engineers "sitting on the switch" to keep it open and functional - but it stopped working. So I pushed all of our free content to Amazon S3 within 2 hours of our launch - which helped tremendously.

Also - a subset of people didn't like Silverlight and wouldn't install it. We took ads out on Reddit and people simply saw our site as something sponsored by Microsoft - which is the exact opposite of our goal. So that was a major issue for us. 

JA: ASP.NET MVC ran just fine, and the Windows stack was fine. We didn't have any challenges in that area. The main challenge actually came from the decision to use Silverlight for streaming. We had a lot of kickback from people who didn't want to install Silverlight and I convinced Rob we had to switch to Flash. We moved to Flash and haven't had a single person complain. We hope to have HTML5 available soon.

RB: How did the architecture handle the user demand?

RC: We never had an issue with the underlying framework - it handled it perfectly. It's not a terribly intense site (in terms of functionality) so we never really had an issue that way. 

RB: If the platform 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. We also figured that we'd probably need a separate server to run videos properly (for streaming) to Silverlight (using Streaming Media) which would be another license cost - and, in addition, we'd need to buy Media Encoder in order to encode the video for Smooth Streaming.

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.

Not only that, James and I both knew Rails pretty well. We realized we could push everything into the cloud with better streaming and throughput for a microscopic fraction of the price - so that's what we did.

JA: As Rob mentioned cost was one of the factors, BizSpark is great but it is basically a ticking time bomb. I think more than cost though the motivating factor was around what we both wanted to be using day to day. ASP.NET MVC and .NET are very lacking in some areas that are very important to us. The testing story on .NET is not the best, you have to jump through a lot of hoops to design your application in the right way to handle testing and then writing the tests themselves is not as clean or usable as some other languages. One of the other areas of high friction was deployment, there are ways to handle it in .NET but nothing as nice or clean as Capistrano. 

RB: So what does the TekPub platform look like today?

RC: We moved to Rails 2.3.5 using MongoMapper against MongoDB. We have a reporting setup that uses MySQL to track stuff we need to report on which uses DataMapper. We also plugged in New Relic RPM to keep track of our site and it's health - all of this is less than 1% of what it would have cost us, on average, with BizSpark. 

JA: This solved all of our issues around licensing, we pay about $80/month for a large Ubuntu instance on Amazon EC2, after the reserved instance fee. It’s a technology that both Rob and I really enjoy working with, we have great testing with Cucumber, and deployments with Capistrano are simple and easy. 

RB: Can you give us a bit more detail on your technology stack?

RC: Using Rails 2.3.5 against MongoMapper/MongoDB and DataMapper with MySQL 5.2. We are also using New Relic RPM which is just great. 

JA: We are using Rails 2.3.5 running on Ruby 1.8.7 running through Passenger. On the DB side we talk to MongoDB version 1.3.4 using the excellent MongoMapper gem. We also use MySQL 5.1 through DataMapper. We don't make use of too many other gems, we use Pony for sending email and rpx_now to talk to RPX for our authentication. We are both big fans of HAML and use that for all of our views.

RB: What does your EC2 configuration look like?

JA: Because all of the content is served from CloudFront we can afford to use a fairly small server. We are on a single large EC2 instance (2 virtual cores, 2 compute units each and ~7G of ram). It's running Ubuntu 9.1 (karmic) and Apache. I wish there was more here, but it is very simple to get this up and running on EC2.

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.

RB: Why did you choose MongoDB versus a more conventional database such as MySQL or PostgreSQL?

RC: Speed and extensibility. It's so very simple to work with MongoDB - there are no migrations to worry about and you can have a ton of flexibility with it. It's also ridiculously fast - and the speed perception is huge for users. 

JA: We are using both actually, we use MongoDB for what it does well (flexibly store information about the productions, users, orders, etc) and we rely on MySQL for what it does best, providing a durable transactional log of what is happening. 

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 - then making sure everything happened to plan. I think our users are seeing a bit more functionality that works as intended - which is great.

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.

One of the biggest changes in the rewrite is actually how we are serving files to our users. In the past we would stream files from either our server or from a Wowza media server running on EC2. Both of these solutions were adequate but expensive and didn't work as well for people in other countries. Around the time we started our re-design Amazon announced the ability to serve private content through CloudFront and CloudFront Streaming. All of our content is now served from CloudFront using securely signed URLs which means users anywhere in the world are getting great download speed. It also saves us money since we are only paying for the bandwidth we use and don't have additional machine or licensing costs.

RB: What does your TDD testing methodology consist of in your current implementation?  Any mocking involved?

JA: We use Cucumber and Pickle and that's about it. Rob can probably detail this better than I could.

RC: No mocking - pure BDD. I hate the drag of feeling like I need to have "code coverage" - I have a business to run and I'd rather make sure that the user experience is solid and to me that means BDD. Cucumber played a really big role - as did Pickle and Factory Girl - all of it went together amazingly well with MongoMapper and it made me actually laugh a few times and what I was doing on the Microsoft stack versus what I could do now. I was almost completely thinking business-first and didn't even really notice the mechanics of the testing. 

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. I'm not afraid to say it - I wrote a ton of crap for our first revision. It doesn't matter how good your application is if you don't have customers and all I really needed to be sure of was that it didn't fail when it wasn't supposed to. 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.  

That aside - it's night and day. We're covered with all kinds of behavior now and I think James even got around to writing some.

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.

RB: How hard is it to do testing on a Microsoft stack and why?

RC: The language and the tools. If Microsoft thought more about it, it would be a bit easier to test the stuff. You can't do RSpec with any language other than Ruby really - it just makes it easy. Microsoft could capitalize on that with the DLR... but they don't. It's not in their ".NET Story" and that's OK - it's their business decision. It was ours to move away from that. 

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. This is my 3rd startup and I think it's the 5th for James and we had a long discussion about what to use in the beginning. We both agreed that we'd need to "go with what you know and get it out" - so we did. 

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.

Rails is super easy for two guys like us to work on and maintain. We have the most scalable backend in the world (Amazon EC2 with auto-scale) and we're having fun doing what we're doing.

JA: I think most people would look at this story and think that we should have gone with Rails to begin with, but I am actually very glad we didn't. I think our instinct to stick with what we knew the best made sense while launching our business and let us worry about all of the business issues without worrying about our tools. Now that the business is launched and on firm ground it is the perfect time to let our inner geeks run a little wild and move to a platform we both enjoy more.

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.

RB: Thank you Rob and James for taking the time to talk with me today.

Additional information about TekPub can be found on the company web site.

Rate this Article

Adoption
Style

BT