Architecture for RoR SaaS application

Question

I have done a decent amount of base RoR work, but haven't really faced much concerning scaling and running multiple applications.

I am in the process of building an application for a client that I hope to market to other users in similar industries, but I am struggling with the high level architecture. It seems unnecessary to run a completely separate instance of the application for each client, but I don't know how to load different configurations/layouts/features for the various users. I don't expect each individual application to have extremely high traffic so it seems like a waste for each to have unique a instance/database. Yet, each instance will probably require its own CSS as well as potentially a different configuration of the available functionality.

Is this something that can be done easily using subdomains? Can I load different configurations based on this? Does anyone have insight into how the 37 signals applications manage different configurations based on account?

Answer 1

When we were making the same decision for our application, we considered several things...

First and foremost, we considered complexity. When you start adding multiple customers into the same database, you need to consider how you are going to segment their data. If you've written the app for one customer, you likely haven't had to worry about this too much. In many cases, these issues are rooted in the core data model, which will lead to a lot of refactoring (if not a total rewrite).

Additionally, you never escape this complexity. Especially in a business facing application, exposing one customer's data to another customer can be deadly. You'll always need to add extra code and a lot of extra testing to protect yourself from this.

Second, we considered cost. When we considered that we could run multiple customers in their own Rails instances on the same Amazon EC2 instance with their own Amazon RDS databases within the same RDS instance, the cost became very attractive. Since we have a business facing app and won't have more than 200 customers anytime soon, we're probably talking about a few thousand dollars in extra hosting costs over a 3-5 year period.

When we compared the cost vs. the complexity, we concluded that keeping everyone in their own instances was well worth the theoretical scaling issues.

The downside to this approach is that you have to make sure that you are able to keep up with maintaining, monitoring, and upgrading multiple instances. Some simple scripts and tools like Chef can go a long way here.