Multi-tier application

[jleach]

Great post DocMan. It hits on a few of the many reasons we've decided not to go this route in the past.

Security aside, the maintenance window thing is a big one as well. Then we often have customer "weight" comparisons: does one large customers hog resources for 90% of the system while five small companies suffer the consequences? What if you want to roll out a feature for testing to a particular company prior to rolling out to all? Much more difficult with a shared database. What if one particular client has more stringent protection (or auditing) needs imposed by some regulatory entity that others customers don't need to adhere to?

While all of these scenarios come with some troubles in terms of developing and maintaining a shared codebase, having them all running in the same instances makes the job so much harder.

While it might seem like a bit more work initially to run different instances of your system components (e.g., databases) for each tenant, the long term payoffs are immense. Think of it as "normalizing your architecture" in the same way as how not bothering to normalize a database will put you dead in a corner later. We're not so much different in this either, but on a different scale.

Cheers,

 

[Mark_]

Regarding separate back ends for separate companies, If you are HOSTING or providing services to multiple companies, you may think “Toss everything together so we can understand OUR business”. If you are in a call center environment, this often happens.

Having worked with a couple call centers, the best advice I can give is “Each client gets their own”. One of the companies I was working with had a very straight forward way of dealing with multiple clients when it came time to do the reporting and data analysis required to run the call center; they would have “Call center” software go through their clients data, database by database, to accumulate the information THEY needed. Often this was date/time of call, call duration, who took the call, and call resolution. If you have 20 clients and your reps are not dedicated to A client, this is vital for tracking rep performance.

They were geared so each rep could see which ever back end they were assigned to at that time. I don’t remember their network topology, but I do remember they had one subnet all clients were on that was used for backup as well as their internal reporting. This subnet had no outside access and was ONLY used for internal purposes.

In the end, it allowed them to do a lot of projections and forecasts without having to have just a single database. I’d bet it was a pain to get the reporting set up but it allowed them to avoid soo many headaches it was definitely worth it.

 

[The_Doc_Man]

In our environment, the call center was treated as an in-house client (as opposed to those less friendly out-house clients?). The call center was a single database because it was a single call center. Tier II responders had access to the common call center database, which DID include entries for each project. (Because they were billed according to need and recent usage.)

The backup system was also joined to a single server that could touch all of the NAS as needed, but more often, the client software just relayed what needed to be stored. The backup client ran on each machine but the tapes were spun by a backup server.

The actual production, development, and test systems were separate for each project. In fact, the production systems had different security than the other two systems because the clients didn't want their employees to see the dev/test environments.