04 April 2015
Everybody know when this “Rails doesn’t scale” has been begun:
Panic, we must not use Ruby on Rails because Twitter had scalability problems.
I’m a Java developer who love Ruby language, but don’t write anything in Rails. Despite this I’ve decided to look into this famous “Rails doesn’t scale” statement deeper to understand the root cause of this problem.
So, I collected public available Ruby on Rails architecture and scalability case studies (videos of conference talks, reports and blog posts) and tried to extract the general patterns of architecture and scalability issues.
There are two type of scalability issues:
Note: You are not another “twitter” to worry about scalability issues right from beginning of the project (there are fewer web apps on the Internet to get enough traffic to even care about scalability). Your goal is to push your product as quick as possible.
But, in the same time you’d like to use Rails (due to it’s productivity) and make you potentially application scalable (in all possible terms)
The most interesting that scalability is about architecture, databases, caching, event queues, disk IO and less about Rails framework.
Let’s review the common Rails deployment approaches (see Deployment with Ruby on Rails)
One Rails instance handles all requests. Rails is single-threaded: There is only one concurrent request.
Apache with mod_rails/Phusion Passenger
There might be the cases when it’s not enought and in this case we should start looking in “cashing” direction via involving Memcahed and/or Redis (based on Konstantin’s Gredeskoul slides)
(based on Konstantin’s Gredeskoul slides)
The shown above architectures are related to Monolith Architecture. This type of architecture has some problems:
The monolithic Rails app should evolve into ecosystems of connected services. It’s becoming quite common for Rails apps to be working mainly as clients to other services.
Now, we have more than one Rails application and many service which are communicating using messaging, distributed cashed, etc.
I’ve collect much more case studies, see here.
Moving Monolith Rails application to micro service architecture it’s not one shot action. It’s long run with lots of trade offs. And more over, micro service architecture is not silver bullet, it’s just one alternative way to scale your application (see [Recommended Rails Application Setups][#Recommended.Rails.Application.Setups]).
The key idea is to develop your application with SRP (Single responsibility principle) in mind. The more modular your application the more scalable it’s.
I’m planning to add more architecture case studies to my collection (not only Rails related). Stay tuned.
Collection of major technology components mentioned in case studies.