Is one Web Application Architecture preferred over several Web Applications?

Question

In almost all of the SharePoint projects I’ve participated in, the general architecture is three different web applications for intranet, cooperation and mysite. This has been the standard setup in any project. So far I’ve never experienced any performance issues with the setup, and find it doing its job delivering intranet to our customers.

The three web applications are all using host-named site collections with http://intranet.company.com, http://cooperation.company.com and http://mysite.company.com on three different application pools.

Reading the article “Host-named site collection architecture and deployment (SharePoint 2013)” I learn that . . .

When you use host-named site collections, each site collection in a web application is assigned a unique DNS name. When you deploy many host-named site collections to a single web application, you increase scalability of the farm because resources are not used to support multiple application pools and web applications.

Does this mean that our previous architecture is not the best practice, and that we need to change toward the recommended architecture described in the article?

Answer 1

For what I have seen so far, the need for three different web applications generally comes from the authentication requirements more than scalability/performance requirements. Ofcourse there is a performance hit if we isolate the app pools for different web applications as they end up reserving more memory. However, you get the option of configuring different authentication mechanism for different web applications.

Intranet scenarios mostly goes with Integrated Windows authentication. Partner collabortation goes with either FBA or Claims depending on the security requirements. For public facing sites, mostly it goes with Anonymous access + Windows Auth.

Update: There are other factors that can constitute a decision for going with 3 web apps instead of 1 besides the most popular being the authentication mechanism.

Architecture best practice is slightly a subjective matter in this case. I'm sharing a few examples below that still shows why you may require to use 3 web apps instead of 1 even if "authentication" was not your primary requirement based on the comment you mentioned.

1. Throttling requirements and happy hours for large requires can sometimes dictate how many web applications you may need as these options are only configurable at a web application level and not on a single site collection.
2. Service Connections or "Service applications available" to different sites might need a call for different web applications. A service application cannot be designed in a way that its made available for some site collections and not available for other site collections in the same web app. I have seen this become a factor during a few multi-tenant scenarios.
3. Document upload size is only configurable at a web application level and not on a site collection level.

The above three are frequently encountered situations where despite using hostnamed site collections , it demanded different web applications as well. So the architecture you followed can be the right design decision depending on different factors like the above you may or may not have included. Compliance , Security , Monitoring , Performance are the major factors that I have always seen to determine the need of different web applications in SharePoint more than the mechanism behind how the urls of site collections are resolved. I hope this explains your question.

Answer 2

Well, previously I was thinking No, but the more I read, the more it points to Yes. Read this SharePoint 2013 Host-Named Portal article. These are recommended solutions for deploying SharePoint 2013. The SharePoint 2013 Host-Named site collections looks to be recommended with only one web-application.

Excerpt:

The recommended configuration for deploying sites is using host-named site collections with all sites located within a single web application. This configuration is recommended to deploy sites because it is the same architecture that the Office 365 environment uses. Consequently this is the most heavily tested configuration. New features, including the App model and Request Management, are optimized for this configuration, and it is the most reliable configuration going forward.

Answer 3

In my experience, the sites are separated for a variety of very good reasons.

The internal sites (intranet publishing site and the collaboration sites) are usually given different URLs more for a user experience perspective so that users immediately know that what they can do on the Intranet Portal is significantly different from what they can do on collaboration sites. Intranet sites also tend to have a radically different security model than collaboration sites since most Intranet sites are meant to be read by the entire organization whereas collaboration sites are private to the teams.

The Internet site is normally isolated on its own separate farm for security concerns. I.e. in the event that the site does get hacked, the attacker cannot get through the internal firewalls to access the private/secret content of collaboration sites - even if they hack the farm account.