is a blog written by Josh Carlisle based out of Raleigh North Carolina where I explore, Share, and sometimes abuse the modern software development landscape. 


Azure Functions & Office 365 - Match Made in Heaven

Azure Functions & Office 365 - Match Made in Heaven


Azure Functions seems to be taking the Azure community by storm in the last few months. Even prior to General Availability (GA) I saw the developer buzz quickly building during the public preview and for good reason!

What are Azure Functions?

Azure functions are small units of code that can be executed based on numerous types of events that arebuilt around a serverless architecture.  That's a bit of a mouthful so let's break that down a bit. 


The functions part should be pretty self-evident.  Functions should ideally be a discreet unit of work not an entire application.  This is not to say that entire application can't be built around groups of Azure Functions, typically referred to as a MicroService architecture. However, the take away is that it should ideally be a discrete unit of work. Let your function do one thing and one thing really well.


Azure functions can be executed based on Events from several different types of resources.  Some of the most popular include:

  • Listening to an Azure Storage Queue
  • Responding to an Http request (think REST service end point)
  • Executing on a predefined schedule.


You may be thinking to yourself "how can this not be running on a server!".  Well of course there are servers involved!   Serverless is a natural extension of the concept of PaaS (Platform as a Service). PaaS is intended to abstract away the complexities of managing the underlying OS and the hardware to allow a closer focus on the application.  However, in traditional Azure PaaS offerings, such as Azure Apps there remains a need to still consider server resources such as RAM and CPU. How an application scales in response to need requires additional considerations.  When it comes to Serverless architecture such as Azure Functions the entire server is abstracted away.  Applications simply need to define their performance requirements and the underlying infrastructure, referred generally as dynamic computing, ensures that your requirements are met.   This may sound like a very expensive proposition but Microsoft Azure has implemented this in such a way that in many common scenarios it turns out to be much cheaper than traditional Azure App offerings.

It is important to understand though that the underlying infrastructure of Azure Functions is Azure Apps.  You can choose to you a consumption mode where you only pay for resources that you consume or you can also have Azure Functions run under the resources of a standard Azure Apps.

There are scenarios where running Azure Functions within the context of a dedicated Azure App may make sense so it is fully supported but for the majority of scenarios the Consumption based plans can often be the better choice.

The development experience

It should be mentioned that Azure Functions only recently was released for GA and the development experience hasn't completely caught up.  Until recently all development code was implemented within an online editor within Azure using either C# or Javascript.  Alternatively,  a GIT repository could also be monitored for deployments.  Recently a preview of a Visual Studio project type was made available which provides development and deployment through Visual Studio and allows for a local instance of Azure Functions for debugging. Only c# is currently supported for debugging but the project type is in a pre-release still and additional support for other languages with debugging is promised.

The development experience for Azure Functions is quickly evolving and quickly improving.  Microsoft has the stated goal of supporting not only C# and Javascript but also Python, PHP, Bash, Batch, Powershell, and F#. The entire runtime has been open sourced so technically speaking the runtime for Azure Functions could be self hosted within any environment. 

So Azure Functions are awesome - where does Office 365 fit?

With the exceedingly low (and sometimes free) costs of entry associated with Azure Functions, there are many opportunities within Office 365 to very quickly get value.

Timer Job Replacement

Custom Timer Jobs were very common within Traditional SharePoint on-premise development. Needing "x" to occur within SharePoint every "x" days is an exceedingly common scenario.  For obvious reasons, custom Timer Jobs are not available to Office 365 which does not allow the deployment of any kind of custom server code. The security and stability requirements on a multi-tenant SharePoint solution such as Office 365 would not make it feasible.   Sometimes you could find workarounds in the form of SharePoint workflows.  Microsoft Flow may also be an option for re-occurring scheduled tasks.  Many times though you may have requirements that don't fit well within the feature set of either of those tools.  You may have very specific logic that is easier to implement in custom code. With the use of Azure Functions,  custom logic can be executed AND code can access Office 365 data directly through frameworks like SharePoint CSOM or Microsoft Graph.  Because you are only counted for actual executing code this is very economical for infrequently run jobs.


Webhooks are a standard concept used throughout the industry for HTTP based notifications.  Originally available in OneDrive and Outlook in Office 365, Webhooks are now available within SharePoint as well. Webhooks are often compared conceptually to event receivers. Custom code can be executed based on activity with a SharePoint list or library. There are some differences between Webhooks and traditional event receivers or Remote Event Receivers but generally speaking, if you do not need to respond to the "-ing" events such as ItemUpdating then Webhooks may be a good choice for you. They are simpler to implement than the legacy WCF requirements of Remote Event Receivers and also don't have the additional hosting requirements of WCF based web services.  Similar to Timer Jobs you only pay when something is actually executed so it is very economical.


RunWithElevatedPrivileges was a common tool for developers in traditional full trust environments to execute server side code that the current user may not normally have permissions to execute. Azure Functions can under the right authentication configuration (and of course the right safeguards in your code) execute logic under elevated permissions.  A common scenario may be something like a site provisioning request.  Azure function have the ability to be accessed through Http requests like any other REST based endpoint through Javascript. 


Azure Functions pricing can be found at . At the time of this blog post, January 2017,  the first million executions are FREE and additional executions are $.20 per million executions plus any associated storage costs.  The functions themselves are billed based on resource consumption largely based on duration of execution and memory consumption.  Like everything with Azure there is alot of cost formulas to work out so do your homework ahead of time!


Azure Functions make a lot of sense when it comes to Office 365. For those interested in seeing the development side of how Azure Functions are implemented I have some upcoming blog posts that cover a couple realistic real-world scenerios. 

Building a REST Service with Node.JS, DocumentDb, and TypeScript

Building a REST Service with Node.JS, DocumentDb, and TypeScript

Getting Started With Modern SharePoint Development

Getting Started With Modern SharePoint Development