I'm considering moving some projects to Ruby on Rails, just to get more Rails experience. However, I'm concerned about eventually out-growing Rails. The way the Rails MVC framework is designed, it seems like the only way to abandon a Monorail is with a complete rewrite of your entire codebase.<p>Twitter had scaling issues with Rails:
http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html<p>Airbnb also outgrew Rails:
http://nerds.airbnb.com/how-we-built-airbnb-holiday-cards-in-less-tha<p>Here's a couple links I found that addressed moving from a Monorail:
http://david.heinemeierhansson.com/posts/33-myth-4-rails-is-a-monolith<p>http://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm<p>Does anybody here have any experience with migrating away from Rails? If so, please share any links and experiences.
Reality Check: The chance that one of your "learn more ROR" projects endures and becomes so popular that you outgrow the environment is slim indeed.<p>If you are very lucky and it happens (and I hope it will) then you will be too busy running the company to worry about the detail of the migration project - you will have a lot of very experienced programmers and network guys working for the company to take care of that.
Do you have 200+ million monthly active users (Twitter)? Are you making hundreds of million in revenue every year (Airbnb)?<p>No? Then you don't need to worry about scaling your side projects.<p>Also, Twitter still uses some Rails (<a href="http://www.quora.com/Does-Twitter-still-use-Ruby-on-Rails" rel="nofollow">http://www.quora.com/Does-Twitter-still-use-Ruby-on-Rails</a>). Airbnb is still a Rails application, if you read that post.
I currently work at a company with a monolithic Rails app that we are looking to break into a SOA and port parts of it to other, more efficient stacks.<p>Part of the problem with Ruby is that you really need to throw massive hardware at it to get it to scale in the 2-3K requests/sec range that other stacks can reach with more commodity hardware. Depending on your situation, this may be something you're ready and able to do and may solve your scaling problems better than switching stacks. But if you're really trying to scale on low end hardware or virtual servers to minimize complexity/cost, Rails can be a challenge. At Twitter/AirBnB scale it just becomes ridiculous.
try making it as 2 apps, one for API only and one for UI, that way you can make changes independently and replace them with other technologies when needed. We have build a few large applications this way.<p>for api use rails-api and for web use any framework, you can use rails or if it is based on backbone.js or simple bootstrap, you can use sinatra for it.<p>for scaling, identify the bottleneck and solve it. first bottleneck would be database, there are known solutions for it, cluster, sharding, read write seperations etc.<p>do less per request, bring in a messaging queue to handle the parts. e.g.. incoming and outgoing email processing
Moving away from Rails need not be the solution. You can build a service based architecture purely in Rails if you want just as long as you have clear contracts between components (have a bunch of services still built using Rails). Many times your "monorail" app has a bunch of tools and other components glommed together all sharing the same ActiveRecord models. Find those split points and put proper data layers around the various points and build clean contracts.
The Songkick devblog goes into some SOA decisions they took when their Rails app got a little too big:
see <a href="http://www.songkick.com/devblog/2012/09/06/the-path-to-soa/" rel="nofollow">http://www.songkick.com/devblog/2012/09/06/the-path-to-soa/</a> (and related posts)