One Web App or Many? Does 2010 change the equation?
Over a year ago I got into a discussion with some other Catapult people on the idea of should an Intranet have one web app, or be split into many web apps. Let us take as an example a hypothetical company with some basic requirements for an Intranet. They plan on having three main areas of the site. One is a publishing area, a second will be departmental collaboration sites, and the third will be project collaboration sites.
There are two basic options for this approach. The first (what we do at Catapult) is to have a different web app for each section. Thus:
One alternative would be to use a single web app and the URLs would look like
Content DBs can be dealt with easily in either model since the collaboration and project sites are site collections and we can split them into multiple DBs on an as needed basis.
Now the advantage to the first method is that each web app runs in its own app pool and can thus offer process isolation. The downside is that it is a more difficult user experience (especially when working from outside of the corporate firewall with multiple password challenges).
The second method provides for a cleaner user experience with a consolidated feel for the entire intranet, but has everything running in the same memory space.
Now with the advent of 2010 and the sandbox solution (not to mention improved thread management by SharePoint) does this change? Is there a reason not to have all of these running in the same web app? Memory is not really a constraint (64 bit app pools can be much larger, though I can’t find a hard number on how large they can get). It all boils down to process isolation versus user experience. I felt that the UX value was a reason to risk the process isolation even under 2007, but with 2010 I find even the process isolation argument hard to make anymore.
Which brings up the question of why I would even put my MySites into a separate web app…why not have them under http://home/personal/[userrname] or a similar style?