The scaling problems have little to do with rails. They admitted their problems were at the database level eons ago. I imagine "the switch" has more to do with the new chief architect switching to his favorite horse. Two whipping boys for the price of one: the old platform, and the old architect.
The new rewrite will give the new architect time to vest, until it fails, like big rewrites usually do. If you're not sure how to fix things, the big rewrite is a perfect solution, really.
The rails DB integration lets you use the database directly whenever it suits you. At that point it's more a matter of arranging your data so that it lets you work around the key pain points. Since you can access the data directly when needed in rails, how will a new framework help if your problem is in the database?
Comments
The scaling problems have little to do with rails. They admitted their problems were at the database level eons ago. I imagine "the switch" has more to do with the new chief architect switching to his favorite horse. Two whipping boys for the price of one: the old platform, and the old architect.
The new rewrite will give the new architect time to vest, until it fails, like big rewrites usually do. If you're not sure how to fix things, the big rewrite is a perfect solution, really.
I know rails itself is sound, my comments are directed more towards rails/DB integration. The database always seems to be the real bottleneck..
The rails DB integration lets you use the database directly whenever it suits you. At that point it's more a matter of arranging your data so that it lets you work around the key pain points. Since you can access the data directly when needed in rails, how will a new framework help if your problem is in the database?
Since Ruby gives you such great flexibility, it wouldn't be that hard to hack things around a bit to redirect data requests to some other source.
I don't see that as the problem.