[noxee]

Yeah I agree with what you're saying, as I said I was looking at the problem somewhat naively.

When you talk about having each tenant's host do you mean a dedicated application server for each host? The current setup we have is that we have multiple tenant databases but only two application servers providing functionality to them, so there's a switching cost on the application servers because they can't maintain a connection pool to the databases (they also have to know the credentials for the databases.

It seems excessive if you have a 100 tenants to have your infrastructure for serving the application replicated 100 times but maybe we're just haven't quite built our system correctly yet.

[xemdetia]

In the model I am describing every tenant component would have an agent that was reporting the state of that tenant. If there was a shared component/pool that wouldn't be reporting separately, I'm really only describing the tenant databases/tenant-specific files. So if you had a tenant database, there should be an agent that just is reporting on that tenant database.

As for separation of the application frontend it really is a risk assessment and culture thing. If the team understands that making sure you never cross streams of customer data is a critical requirement which is one of the first viability questions in the design then sharing really isn't too bad. If your team struggles with this or has recurring issues to this end separate application servers make more sense. Generally if you have tenants with data exposing another customer's data is a quick way to have trust in a product evaporate, I know I have had this happen as a customer where I was able to show a bug where I was getting another customer's accounting information in a cloud app which caused me to terminate the contract.

If you guys are minding the soup of the application servers well enough there's nothing say you can't, there are many people that do it.