Multi-user app

rubyonrails-talk
1

Hi All,

Which is the best way to handle multi-user applications in Rails (think backpack)?

Let me try to explain what I am trying to do:

I wrote an application and sold it to different companies. For every company I sold the app to, I deployed a fresh Rails app to a fresh 256MB VPS and provided a superuser account (to the app, not the server).

Customers handle their own users from there as they see fit. User administration is handled by a combination of acts_as_authenticated, a recipe from Chad Fowler's Rails Recipes and a handful of rather ugly hacks. All in all, user administration is very complex since a superuser has very fine-grained control over which parts of the application and database operations and records a regular user can have access to.

I want to rewrite the whole thing from the ground up and one of the most significant changes will be to have only one code base shared by all users. (Maybe this is the way it should have been deployed in the first place but given my lack of experience and the fact that my customer base is very very small -think dozens, at most- multiple deployments were a good idea at the time).

Problem is, I am not exactly sure how to go about that:

First, it will add another layer of complexity to the user administration system and I still have to figure out how to handle it.

And what about the database?, should all companies and thus, users, share the same one? That worries me a bit considering:

  a) Users of my system are direct competitors and the information contained in the database     is critical.   b) Although traffic is not a concern at all, the database can grow considerably large in a short     period of time.   c) If the database crashes ALL my customers will be affected, not just one. Granted, I really     should backup regularly but still...

Is there a way to have multiple connections to different databases and decide which database to query given the user that has just accessed the app? If so, is that a good idea?

Thanks Juan

2

Hi Juan,

What in particular don't you like about each company having their own server? Is it the increased effort to deploy software updates?

Wyatt Greene

3

Hi Wyatt,

That bugs me a bit, yes. Although the whole process is pretty much automated (installing all software in a new server, deploying the app and pushing updates), I think it would be easier for me to maintain just one server.

What really bothers me though is monitoring all the servers (I am obsessive about that) and cost.

Right now I host each client on a 256MB VPS and costs are soaring quickly. I could host 2 apps per server, probably 3 but no more than that since I like to have at least 2 mongrels running per app.

The funny thing is, the apps have negligible traffic and a 1G VPS would probably be enough to give service to all my clients wit just one app and bigger cluster of mongrels.

Furthermore, unless I am missing something, all my clients can keep using the same url's to access the service. (I could just create a new virtual host for each one and point it to the one app). I could even have the application query the proper database given the host.

Does that make any sense?

4

Hi Juan,

If I understand correctly, switching from multiple VPSs to one server for all companies would:

* decrease cost * decrease effort (to monitor the systems) * potentially increase risk

You mentioned some risks about the database, such as competitors' data being in the same database, and if the database goes down, all customers will be affected. I think that pretty much summarizes the types of risks you have to think about:

* risk that information will bleed over into an area where it shouldn't be accessed * risk that system failure means failure for all clients

I don't think there's anything wrong with putting all your eggs into one basket, just make sure you have a really good basket. :slight_smile: Watch out for subtle things like using class variables. These will stick around in Mongrel between requests, so if you have data in class variables that are different depending on the company, that's one way for one company's information to get sent to another company.

As far as having multiple databases with one Rails project: I think you can do that, although I don't know whether it would be good or bad. I believe the book "Rails Recipes" by Chad Fowler has a recipe on having multiple databases in one Rails project.

The part about your clients keeping the same URLs makes sense to me. You should be able to make this type of change without impacting your users.

Good luck!

Wyatt Greene

5

If I understand correctly, switching from multiple VPSs to one server

for all companies would:

  • decrease cost
  • decrease effort (to monitor the systems)
  • potentially increase risk

Rimuhosting offers the option of installing multiple VPSs on one server. That’s what we use and it’s the best of both worlds (we have a few customers that want a VPS so they don’t have to have us manage it and that’s fine by us, they are responsible for keeping it up), our other customers are on the same server in a different VPS with Plesk. They are limited to creating e-mail addresses and some FTP space.

Backups: such a setup provides an excellent environment: the RAID installation on the server keeps the data mirrored on a second disk and all VPSs are backed up twice a week in a rotation scheme (meaning two vps backups are always present on the disk). That’s quite a few backups already (considering they are mirrored on the RAID disk) and with the extra remote FTP backup space you get from Rimuhosting we can still do a daily dump of all our databases and put those on that extra FTP space.

You mentioned some risks about the database, such as competitors’ data

being in the same database, and if the database goes down, all

customers will be affected. I think that pretty much summarizes the

types of risks you have to think about:

  • risk that information will bleed over into an area where it

shouldn’t be accessed

  • risk that system failure means failure for all clients

That’s true, but with a multiple VPS on one server solution that risk is minimized to hardware failures, and keeping my fingers crossed, it hasn’t happened to us yet.

Best regards

Peter De Berdt