SharePoint 2016 Architecture Changes: Benefits and Costs

UPDATE: At Ignite, Microsoft announced the contents of SharePoint 2016 Feature Pack 1 which is releasing this November. This includes updates to MinRole! Read our blog or watch our recap webinar to find out what’s changed and what else we learned about SharePoint 2016 at Ignite.

As we discussed in the earlier posts of this series, SharePoint 2016 was really “born in the cloud”. Microsoft has learned quite a bit from operating and supporting SharePoint at massive scale with Office 365 – SharePoint Online. In order to ensure that the SharePoint Online service maintains optimal performance for end users and also has the reliability and maintainability required by a global service provider, Microsoft has been innovating on the back-end architecture of SharePoint Online for the last few years.

Because SharePoint 2016 is derived from the same code base as SharePoint Online, on premises customers will soon have the benefits of increased supportability and performance for their own SharePoint farms through some key architectural changes. In this post, I’m going to focus on two major changes:

1. MinRole
2. Zero-downtime patching

As we will see, these changes will take the guesswork out of your SharePoint service architecture and reduce the pain and business-impact of patching and updating SharePoint. However, they come at a cost: You will most likely need to run more SharePoint servers than you do now. Is it worth it? Let’s dig in…

The Problem with “Flexibility”

In my years of training technical and non-technical folks on SharePoint, helping someone understand the concept of a “farm” was one of the biggest challenges. It almost always involved some whiteboard scribbling where I drew slightly askew rectangles with the word “server” written under them and lines connecting them. I explained that SharePoint had a flexible, role-based topology where parts of the SharePoint services could be run on different servers to maximize performance. I also would talk about the ability to “scale out” and have two or more servers running the same services for reliability and for even better performance and load balancing.

Inevitably, someone in the group – usually a more technical person actually considering how he or she would plan this mess out for a real deployment – would ask: “But how do you know where to run what and how many servers you need?”

Officially, I would point this conscientious student to some of the planning documentation provided by Microsoft on TechNet or encourage him or her to source the many excellent blogs posted by the SharePoint community and MVPs. But in my heart of hearts, I knew the proper answer:

It was alchemy, best guesses, and lots of hoping.

But why was this so hard? Surely, SharePoint is a well-established platform running in tens of thousands of organizations. Why would proper tweaking of the platform involve so much guesswork? The reason is actually pretty simple: flexibility.

From the early days of SharePoint right through SharePoint 2013, Microsoft did its best to make sure that SharePoint’s architecture was adaptable enough to service deployments ranging from a very small number of users, up to hundreds of thousands of users. Small, single server deployments are fairly easy to set up, but lack power and redundancy. When you are planning large deployments, the flexibility to scale out and distribute the load of SharePoint services is vital, but daunting. Up through SharePoint 2013, the “roles” that servers could play in a farm were pretty simple. Web servers were the servers that end-users would connect to (often referred to as Web Front Ends or WFEs). Database Servers were pretty simple to understand as they ran SQL Server and held the SharePoint Content Databases, Configuration Databases, and the databases required by specific SharePoint services, like the User Profile Service. Application Servers were where it got complex. These servers could run a combination of additional SharePoint services. Just taking a look at the TechNet guidance for “Service Deployment in SharePoint 2013” gives an indication of how easy it would be to get this wrong and end up with a sub-optimal architecture.

Introducing: MinRole

In SharePoint Online, Microsoft has to stand up farms quickly and efficiently. Servers with troubles need to be swapped out of farms and replaced rapidly and easily with no downtime. Complex “streamlined topologies,” where you have to install SharePoint to a server and then go in and turn some services on and other services off, needed to be simplified into neat, repeatable installations. To that end, Microsoft created a new concept for SharePoint Server roles in SharePoint Online, and that change is now seen in SharePoint 2016. “MinRole” is exactly what it sounds like. A server in a SharePoint farm now runs an explicit set of services based on its role, and no other services are turned on.

Defining the role of a server in SharePoint 2016 happens when you first install SharePoint on it and run the initial Products Configuration Wizard.

Each of the MinRole server roles are optimized for the work that they are designed to perform, so any guesswork about what needs to be turned on or off is eliminated. In addition, because each server in the farm has a stated role, we can detect when an overzealous admin tries to start running services that are outside the scope of the role the server is intended to perform. The Compliance Check will show when servers are running these rogue services. If MinRole servers are out of compliance, they can be easily brought back to their compliant state.

If you are doing the math here, you are noticing that there are four defined MinRole server roles other than the single-server farm which is not recommended for production use. This means that if you are running a production farm, the smallest farm you can utilize to run the full SharePoint platform is four servers. For very small organizations, this may be larger than what they are running today. In addition, the four-server deployment does not ensure any redundancy in the event that a server in the farm goes down. As described in this TechNet article, an eight server deployment is the smallest, fully redundant MinRole deployment. Bottom line: If you want to fully embrace MinRole and its benefits, you will likely be running more servers than you did for previous SharePoint versions.

Note that the “Custom” role is also an option. This role is essentially the same as the legacy installation of a SharePoint server in previous versions – a basic SharePoint set of services are turned on by default, and the farm admins get to decide what services they want to turn on and off. Using the Custom role allows you to run the same services architecture you did under your previous version. Therefore, you should not need more servers, provided your environments are the same size and level of complexity. There is a big downside with the Custom role, however. You lose the assurance that you are running the optimized set of services to ensure best-possible performance. You also lose the ability for ongoing monitoring through the compliance checker to ensure that your services architecture stays compliant with the stated design.

Tipping the Scales toward MinRole: Zero Downtime Patching

A common pain point for many of our customers – especially the larger ones – is that keeping SharePoint 2013 and earlier versions up to date with the monthly bug-fix and security patches requires the SharePoint farm be down while the updates are applied. Monthly cumulative updates (CUs) at some of our larger clients can actually take up to 40 hours (!) to complete, meaning that their SharePoint production farms would be offline for an entire work week. Clearly, this is not acceptable, so the strategy used by these organizations involves a complex and expensive process of maintaining two redundant, active farms, which allows them to direct users to an alternate farm while the primary farm is updated.

Again, Microsoft themselves faced this problem in SharePoint Online and had to solve it. There is no way that Microsoft could meet its financially-backed, 99.9% uptime SLA with the legacy patching process, so it made some very cool changes in SharePoint 2016. First, the update packages themselves are smaller and more streamlined. Second, all update packages are designed to be “backward-compatible”, meaning that a server that has had these updates applied can co-exist in a farm with servers that have not yet had the update. Finally, building on the backward compatibility, the upgrade process itself now can be carried out without taking the farm offline. The process is essentially this:

1. A server in the farm has the update process started
2. That server is temporarily unavailable to the rest of the farm
3. The update is completed
4. The server once more becomes available in the farm

Note that in this process, it’s the server that is unavailable during the update, not the entire farm. What this means is that if you are using redundant, highly available MinRole service architecture deployments as described above, then you now effectively have “zero downtime patching”. That makes the cost of a (minimum) eight server deployment a little more attractive. As larger organizations are likely already running redundant server roles, the zero-downtime patching will likely be a no brainer.

Conclusion

In this post we have seen the real value of Microsoft’s cloud investments realized in SharePoint 2016. The enhancements we discussed above may not be the flashiest or the ones that non-technical people would appreciate, but the architecture investments that have come down from SharePoint Online should mean your SharePoint 2016 farm runs faster, more reliably, and with less downtime. Find me a SharePoint user who is not interested in that!

What’s Next?

For more information about what’s new in SharePoint 2016 and how to prepare your business ahead of the release, check out the SharePoint 2016 Readiness Guide by AvePoint. You can also learn more about migrating to and designing your SharePoint 2016 environment by registering for my upcoming webinar, How to Prepare Your SharePoint 2016 Migration Today, airing at 11:00AM ET on Wednesday, March 2.