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 are built around a server-less 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! Server-less 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 Server-less 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
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.
Azure Functions pricing can be found at https://azure.microsoft.com/en-us/pricing/details/functions/ . 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 are a lot 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 scenarios.