views:

43

answers:

1

Dear all!

We are currently finishing a web-based time-tracking software built on ASP.NET and WCF (for different desktop-clients). Our customers can register an account and add an unlimited number of users to their account. Pricing is tied to the number of active users in the companys account.

To keep things simple and easily scalable we thought it would be a good architectural decision if we design each account to run as a single IIS-website with it's own application-pool, SQL-Server database and subdomain.

Unfortunately we rapidly run into memory-shortage, due to the fact that a single worker-process will consume at least 150mb, which means that for every single trial-account we need approx. 200mb more of memory...

Beside the heavy costs of such an architecture (trial-accounts!), we are not sure if it was a good decision for scaling, to design the architecture that way.

  1. How would you design such SAAS-applications?
  2. Single app-pool for many sites?
  3. Single website for many accounts with shared database?
  4. Scaling vertically (more power) over scaling horizontically (more servers)?
  5. Any good books or blogs on this topic?

Thank you!

A: 

What are the reasons for creating a new site and application pool for each account?

A single site with a shared database (number 3 in your list) is a much easier solution that can scale much better. You can then scale up the number of web or database servers when needed. This architecture is used in e.g. Sharepoint and most public web sites.

Andreas Paulsson
I thought having a seperate website for each account would be the only way to do things like seperate subdomains for each account (with IIS-host-headers) and will also scale more easy because I could put new customers simply on a new webserver while I only need to change the DNS-settings for their subdomains...Can I do subdomain-seperation even with one IIS-website and app-pool?
dlang
Absolutely. I have developed a few different public web sites where we show different markets (country and language combination) depending on hostname. It is also common when building multi-language umbraco sites. And as I said earlier; Sharepoint (which scales quite nicely) also does this.
Andreas Paulsson
@dlang - A single database horizontally segmented by tenant/client is not without its issues. E.g., versioning is problematic. You must update everyone all at once. What do you do if you have new features that you do not want to roll out to everyone or if you want to only update a few customers and not others. Also, scaling out is significantly more difficult. If you want to move some clients to a different db server, you have to manually carve out their data. Lastly, you must be extra careful to ensure that every table segments by tenant or you risk showing the wrong client's data to someone.
Thomas
Many thanks for your statements! I will take a look into Umbracos implementation of how to enable a single website to work with different content depending on the hostname and will also try to find a solution how to keep databases seperated while using only one IIS-website...
dlang
@Thomas - I do not see the problem with a shared database as long as we are talking about a single web application. When you update the database, you usually also update the application.But I agree that You make sure that you do not "leak" information between customers, that happened in Sweden for an online ERP company and the badwill in the press in enormous.
Andreas Paulsson
@Andreas Paulsson - Suppose you need to update just one client to a newer version of the app which includes a database schema change. Can't do it with a single database. Suppose one client wants to host the application on their internal servers. Ripping their data out of the db is a pain. Suppose a client needs to get some data deleted a month ago from backup. You have to restore a entire copy of the db just to get one client's data. Don't get me wrong, a single db has its advantages but it has problems as well.
Thomas
@Thomas - You are right in those cases. There is no solution that fits perfectly for all possible cases. If you have those kind of requirements (that I have never had), you are better off with a single application that uses different databases for different customers.
Andreas Paulsson