We are going to be using DNN for a large project, including 20-40 in-house built modules, and a large # of Web sites (in the hundreds).  So, we have some serious questions about scalability, the possibility of continuous integration (Cruise Control) in production, and alternate ways to install DNN for easier management.

We'd like to install a single copy of DNN and potentially use it for hundreds of Web sites for easier management of releases.  However, I have heard that using portals to accomplish this has its own set of problems stemming from the possibility of changes in one portal affecting other portals, which is unacceptable.  Is this true?  If so, this leads to some questions.

1. Is it possible to override core or create a provider that changes how DNN knows what DNN database to connect to?  Like I said, we'd like to have a single copy of code installed and possibly multiple sites in IIS and based on the domain name, DNN knows what DNN database to connect to (rather than using portals in the same database).

2. Why are physical files created when portals are created in the /Portals/ folder?  It seems that they are just placeholders, but would cause serious problems if we configured DNN like stated in #1 with one copy of the code and multiple IIS sites.

3. Are there any other file system modifications in the course of an install, upgrade, or running the application that would hamper the single code-base, multiple IIS site configuration?

4. Is load balancing at the OS level or with a LB appliance possible?

In the case of how we'd like to configure DNN, we would not be installing modules through the module interface.  We'd like to make them part of our continuous integration script so that modules are "already installed" when an update occurs rather than needing to log into DNN, upload the ZIP, and wait.  Is this even possible?

Michael

Actually, no, we want to upgrade all clients at the same time as our model is more like SaaS.  Our other applications that we have built have one code base for many clients to make management of deployments easier.  It does make management of enhancements/feature requests/bug fixes more difficult up-front, since we need to take into consideration all clients, but this is the dilemma with the SaaS model that we have accepted.

This issue I was unaware of.  Thanks!

One code-base would make scalability easier as you only have to make a copy of the code-base once to the other load-balanced Web servers, rather than a copy for each client multiplied by the # of servers being load balanced.  For us, this will pose a problem as there will be hundreds of Web sites that need to be load balanced within a few months of implementation.  It's easier when using CruiseControl, even in this scenario, but I wanted to avoid it if possible.  The more clients, the longer it takes to perform a deployment of new code.

I guess it wouldn't be so bad if we were assured that portals will work for handling multiple clients rather than needing to perform a new DNN installation for every one just to make sure their settings do not affect other portals.

To John's point the other item to consider is the fact that usernames must be unique over ALL portals!