Multi-user app

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

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

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?

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

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