Haven’t made the jump to SharePoint yet? Our free Office 365 and SharePoint Migration Checklist tells you everything you need to know. Download here!
Since we’ve gone over what SharePoint is, the next step is figuring out how it’s architecturally built. People will mention farms, site collections, and active directory, but how do all these elements integrate and come together?
In layman’s terms, SharePoint farms are a collection of servers that work together to deliver a service to support a site. There are three types of servers: web front ends (WFEs), application servers, and database (SQL) servers.
Web Front End Servers
Web Front End Servers (WFEs) handle web page requests from users. This means that each time a user opens a SharePoint page in a browser, it’s processed by a WFE server. If there are multiple WFE servers, a Network Load Balancer is put in place to distribute requests between them. This enables organizations to scale their SharePoint environments as needed; the more users you have, the more WFE servers you will need to handle the workloads as the environment and user needs grow.
An Application Server is a computer that provides key infrastructure and services for applications that are hosted in an organization’s SharePoint farm(s). This usually means that the server has been assigned to run applications such as Excel, PowerPoint, Visio, Access services, or Index/Search services.
Database Servers (SQL)
SQL Server is a database server that implements Structured Query Language (SQL). This language is specifically designed to handle data in a relational database management system—in this case, a SharePoint farm.
Now that you know how SharePoint collections work together, it’s time to dive into the difference between single farms and multiple farms!
Single Farm vs. Multiple Farms
A single farm is made up of a group of servers that come together using a tiered model to provide services and content. In SharePoint’s case, this single farm environment is made of WFEs, Application Servers, and SQL Database servers. With a single farm you will have a strong foundation of services and as many databases, web applications, and site collections as needed for your organization!
On the other hand, multiple farms are made of services farms, My Site farms, and content farms that only perform certain functions or services. This architecture enables organizations to have specific services to provide for business needs based on scalability, function, and policy requirements.
For an organization that is using a multi-farm architecture, the expectation would be to have multiple administrators handle those different farms. This is necessary if you’re in an organization that has multiple county departments or regions with their own unique policies that need to be adhered to. As such, a multi-farm architecture approach should be used when necessary despite its added complexity. The environment requires more mindful administration and control of multiple environments, after all!
For example, if the ACME corporation has regional offices in different countries, they may need to adhere to any country-specific data sovereignty laws if it’s collecting, managing, or generating data.
In response to this, the ACME corporation could create multiple farms that are geo-specific and built to technically comply with the regulations placed in each country while still providing the entire corporation with a unified approach to managing their SharePoint environment for end-users. This will facilitate ACME’s adherence to region-specific policy and regulations–including any data sovereignty requirements–while maintaining a unified “singular” SharePoint user experience for ACME employees.
And that’s a basic overview of on-prem SharePoint architecture! Have any questions? Feel free to leave them in the comment section below. And if you want to learn more about SharePoint, check out the following resources:
- Blog Post: SharePoint Online vs. SharePoint On-Premises
- Webinar: All You Need to Know About SharePoint 2019!
- eBook: Office 365 and SharePoint Migration Checklist