How to plan Service Applications in SharePoint 2013

This is the 3^rd post of the article series regarding service applications

• Part 1 : Service application architecture – Basic Concepts
• Part 2 : How logical components of service applications map to physical components
• Part 3 : How to plan Service Applications in SharePoint 2013
• Part 4 : Change application pool of an existing service application

When we setup a new SharePoint environment, we should plan service applications properly. There are certain factors and best practices to consider before we configure any service application. In this article I will provide few points which will be important to consider when we do service application provisioning.

1. What are the service applications I need?

If we use configuration wizard to setup the SharePoint farm, it’ll setup all selected service applications with default settings. By default all service applications except “Lotus Notes Connector” are selected.

Although this will setup almost all service applications, we may not need most of them. On the other hand we may need to specify different settings when configuring (e.g.: different managed accounts).

To overcome above limitations, the best practice is to use a scripted installation which will setup and configure service applications those are required.

Let’s assume that we need only Search, Managed metadata and User profile service applications for an environment. In that scenario we may not configure other service applications like Excel services, Access services, PerformancePoint services, etc..

By provisioning only relevant service applications, we can reserve resources like processing power, memory etc.. as well as we can focus on maintenance and administrative activities of those applications only

2. What is the service application topology which suits the business requirement?

There are two main types of topologies to consider

1. Single farm service application topologies
   • Single farm with single application proxy group

   This is the most basic topology where all web applications use the same service applications 

   • Single farm with multiple application proxy groups

   In this topology we do have unique service application requirement for certain web applications (e.g.: departments). In that case we will create new proxy groups probably with new service applications

   • Single farm with multiple application proxy groups and multiple application pools

   In this topology we are focusing on isolating certain service applications from others. As we mentioned in an earlier post that when we create a new service application, an application in IIS also created. So we can specify different application pools with probably different identities as execution accounts,

2. Cross farm service application topologies
   • We can share following service applications across farms
     • Business data connectivity
     • Managed metadata
     • User profile
     • Search
     • Machine translation
     • Secure store

3. What are the resources I need?

When provision a service application we need to allocate resources for that application in forms of processing power, memory, disk space as well as separate servers. There are some resource-intensive service applications like Search service, Excel services, Visio services, etc..

Some service applications require databases to store its data. For an example user profile service require 3 databases to store it’s content. Namely Profile, Social and Sync databases. Apart from that, creation of My Sites will also create content databases. This will definitely increase the storage requirement. Following are the types and storage requirement for service application databases

On the other hand Search service require storage space to physically store it’s index files. This can be very large depending on the searchable content. Roughly it’s between 5% to 20% of the searchable content that is being crawled. If the percentage of text is larger on those searchable content, the index space will also be increased.

It’s generally a best practice to utilize separate servers to resource-intensive applications like Search index. This is because Search service constantly crawl the content which require high amount of memory and processing power.

4. Do we need to consider high availability?

If we have multiple servers in the farm, we can start multiple instances of same service application on those servers. We don’t need to worry about load balancing as it’s handled by SharePoint itself.

In order to implement high availability on Search service, we need to modify the search topology to include search index replica and partitions. We need to increase partitions and replicas based on items that are being indexed by the search service.