SMA290110: Consider different implementation of TimerJob

Traditionally timer jobs have been written in managed code based upon Microsoft.SharePoint.Administration.SPJobDefinition. They can be controlled in central administration, and log to the Unified Logging Service/System Events tracker. They are used to perform repeated operations, that would either be too much to process in one go, or that the data provided may come in small chunks every now and then. They are used over event receivers, to create less strain on the server.

While there is no direct implementation of a timer job in the App Model, there are multiple ways creating a timed job using the App Model.

An Azure Web Job, for all intents and purposes is a timer job, that is not attached directly to the SharePoint farm. While authentication is required, it is actually processing and method of process is the same as the old style SharePoint Timer Jobs.

Recommended by many, and with samples in the Office PNP source codes samples, it is very easy to create an independent timer job in the App Model.

The SharePoint server can often have large amounts of data being processed by timer jobs at any one time. While the role of the SharePoint farm is to supply the data to users and to other applications, using the same resource to process the data can sometimes result in large performance deficits.

The App Model enforces seperation of roles to a higher level, ensuring that custom components are seperate and cannot interfere with the running of the farm.

With less components deployed on the farm, disaster recovery plans become much simpler, and the turn around of activating a DR plan, is significantly reduced as the processing components of the farm, are separate. The other benefit is having no deployed files to the server, which means that only the content database is backed up, ensuring a faster and more accurate disaster recovery process overall.