With SharePoint 2016’s general release on the horizon, many companies are contemplating what the path to migration will look like. But before making the switch, organisations should take into account what’s unique to SharePoint 2016 and how new features will affect business functions.
The most notable difference in SharePoint 2016 is that this release has been derived from SharePoint Online’s source code. While previous releases looked first to on-premises solutions to define what SharePoint’s cloud offerings looked like, SharePoint 2016 was built out of the cloud. In the years since launching SharePoint Online, Microsoft has learned quite a bit about operating and supporting SharePoint at a massive scale. Those learnings are reflected in the enhancements and architectural changes of the upcoming release. New updates have taken the guesswork out of SharePoint’s service architecture, and make software patching and updating significantly easier. But to see these benefits, customers will likely need to run more SharePoint servers. So are the costs associated with migrating worth it?
Server farms: What they are and why they’re important
Understanding the concept of a server 'farm' has always been a challenge. Throughout its existence, SharePoint has had flexible topology, allowing services to run on different servers and be 'scaled out' so that two or more servers run different functions for better reliability, load balancing, and performance. While that concept might be easy enough to understand, determining exactly where to run certain services and how many servers your business requires has been much more complicated.
While the planning documents provided by Microsoft can help enterprises determine how many servers they will need in a SharePoint implementation, it’s still a bit of a guessing game. Since the early days of SharePoint, Microsoft has done its best to ensure that the platform’s architecture was flexible enough to service deployments ranging from a small number of users to hundreds of thousands. While small, single-server deployments are relatively easy to set up, these deployments lack power and redundancy. On the other hand, planning large deployments with the flexibility to scale and distribute loads is – for lack of a better term – daunting.
The influence of SharePoint Online and the introduction of MinRole
In recent years, the growth of SharePoint Online has presented Microsoft with new challenges for managing the traditional server farm. For one, SharePoint Online requires that farms be built quickly and efficiently. Troubled servers must be swapped out with no downtime. The task of 'streamlining topologies' (where IT administrators install SharePoint to a server and then go in and turn some services on and others off) has become too complex, requiring simplification.
To better address these challenges in both SharePoint Online and now SharePoint 2016, Microsoft has introduced the concept of 'MinRole', where a server in a SharePoint farm can run a specific set of services (front-end, application, distributed cache, and search) without any other services turned on. When setting up a MinRole farm, SharePoint administrators must define the role of the server when installing SharePoint 2016 and running the initial Products Configuration Wizard. Since each of the MinRole servers are optimised for the work that they’re designed to perform, the initial problems around turning services on or off (and dealing with potential downtime) is eliminated.
It’s important to note, however, that organisations looking to take advantage of MinRole for SharePoint 2016 might be forced to deploy more servers than they had previously run. For organisations that might not benefit from more servers, or simply can’t afford to maintain more, a custom role is still an option. This works best for organisations looking to run a legacy-like installation of their SharePoint server and manually determine what services are turned on or off.
If you choose the custom route, your company should not need any additional servers; provided your environments are the same size and level of complexity as before. But this route is not without downsides, like many legacy options. Unlike MinRole, the custom role does not assure that you’re running the optimised set of services to ensure best possible performance. In addition, custom deployments don’t support compliance checker, meaning organisations will lose the ability to monitor and ensure your services architecture is compliant through the new tool.
Zero downtime patching
Currently, installing monthly bug-fixes and security patches for SharePoint 2013 and previous versions is a major pain point for organisations, as it requires the SharePoint server farm to be down while updates are applied. For some larger organisations I’ve worked with, monthly updates can actually take as long as 40 hours. To work around this known issue, some organisations maintain a redundant, active farm that they can redirect users to while the primary farm is updating. While necessary in certain environments, this solution is very expensive and complex.
To address this problem, Microsoft made several adjustments in SharePoint 2016. For starters, update packages are now smaller and more streamlined. Additionally, all update packages are designed to be 'backward compatible', which allows a server that has been updated to coexist in a farm with servers that have not been updated yet. Lastly, the process of upgrading can now occur without taking the entire farm offline – resulting in nearly zero downtime while patching if you’re using a redundant MinRole service architecture. Eventually all the servers in the farm are updated one at a time. For larger enterprises already running redundant server roles, the zero downtime patching is a no brainer solution.
The architectural changes that have been passed down from SharePoint Online mean an organisation’s SharePoint 2016 farm will run faster, more reliably, and with far less downtime upon upgrading. In most cases, these benefits outweigh the costs, but organisations should still consider them as they prepare to migrate to SharePoint 2016.
John Peluso, Senior Vice President of Product Strategy, AvePoint
Image Credit: Asif Islam / Shutterstock