One way would be to have separate app instances for each of the tenants. I
know I know! This sounds like terrible advice. Let me enumerate pros and
cons of this idea

Pros

   1. Every tenant has it's own DB. Security, data dump, master lists (per
   tenant) become painless
   2. If you have subdomain based tenant (a.example.com, b.example.com,
   c.example.com etc) then scaling to multiple machines is a DNS entry
   away.
   3. If any client requires specific application changes, then it becomes
   easy to do as each tenant has it's own instance and code. It can actually
   be a money spinner.
   4. If one server goes down it only affects part of your business
   5. You can roll out new code per tenant and achieve better reliability
   for fat tenants

Cons

   1. Every tenant has it's own DB! Any roll out requires updates to every
   machine. Scaling large tenants can still be pain
   2. Git branching per client is painful
   3. Mutliple servers/ app instances to manage. Memory usage could be much
   higher compared to running a few instance.
   4. Rolling out code is non trivial as every app instance can have custom
   changes

In the end I guess it is upto the use case of your app. I did this sometime
back for a financial application and it was more important to have uptime
than release fast.

My 2 cents

Piyush

On Wed, Jun 13, 2012 at 7:16 AM, Yacc <yac...@gmail.com> wrote:

> Let's assume that:
> * you want the same app to serve multiple vendors 
> (multitenancy<http://en.wikipedia.org/wiki/Multitenancy>
> ).
> * you want to achieve data separation by having dedicated databases for
> each tenant.
> * you have a Tenant.current class method that reliably gives you the
> current tenant in a thread safe way (using Thread.current).
> * you have a small number of tenants (~10 to ~50), and the same schema on
> all dbs
>
> Would you:
> * wrap finders or persistence methods in repository() blocks ? (not very
> dry in my opinion)
> * set DataMapper.repository(@name) for the current request (thread) ?  (like
> for the dm-rails 
> identity_map<https://github.com/datamapper/dm-rails/blob/master/lib/dm-rails/middleware/identity_map.rb>
> )
>
> Is there another approach you would take ?
> Thx
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "DataMapper" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/datamapper/-/sXriCV-1dcUJ.
> To post to this group, send email to datamapper@googlegroups.com.
> To unsubscribe from this group, send email to
> datamapper+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/datamapper?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"DataMapper" group.
To post to this group, send email to datamapper@googlegroups.com.
To unsubscribe from this group, send email to 
datamapper+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/datamapper?hl=en.

Reply via email to