Chris Gillum, principal engineering manager at Microsoft, presented a session at QCon San Francisco titled "Serverless Programming Models in Azure Functions". He discussed two stateful programming models -- workflow and actors -- using Azure Functions, which is Microsoft’s implementation of serverless computing.
Gillum started by talking about Azure Functions, which are "serverless" by nature; the hosting environment supports autoscaling, and running functions are pay per use. Azure Functions are like AWS Lambda, Google Cloud Functions, or other Function as a Service (FaaS) platforms. However, the difference is the "bindings" abstraction, which decouples the code from the data source or destination. It is the central part of the programming model, and the concept allows for building more advanced programming models.
Next, Gillum pointed out the principles and best practices that apply for running functions like Lambda and Azure Functions:
- Functions must be stateless
- Functions must not call other functions
- Functions should do only one thing
In regard to the first principle -- being stateless -- Gillum stated that Microsoft actually does support state with functions via Durable Functions, an extension of Azure Functions that is based on the open-source Durable Task Framework. With durable functions, Gillum explained, developers can write long-running, reliable serverless workflows as code.
As an example, Gillum showed how Functions could be chained together by using a so-called "orchestration" function. Within this function, developers can code the desired workflow steps, for example, calling out to other functions to do work. The functions performing the actual work are called "activity" functions.
An orchestration function is triggered via a message arriving on an Azure Storage queue. The orchestrator function picks up the message, executes the appropriate orchestration code, and sends out a new message to another controlled queue. An activity function picks up the message, and the orchestrator function unloads from memory – thus not consuming any resources. The state is handled via event sourcing; the await statement in the Function's code leads to writing an event in an Azure Storage table. Once an activity function has executed, another message is sent to another controlled queue, and another event is written to the table. The orchestration function then picks up the message, and the next cycle starts until all activity functions have executed.
Gillum stated that the event sourcing allows Microsoft to support multiple languages, such as the combination of .NET and JavaScript. Furthermore, he provided some rules for the orchestrator code, which must be deterministic:
- Rule #1: Never write logic that depends on random numbers, the current date/time, etc.
- Rule #2: Never do I/O or custom thread scheduling directly in the orchestrator function.
- Rule #3: Do not write infinite loops
- Rule #4: Use the built-in workarounds for rules #1, #2, and #3
Next, Gillum went through another stateful pattern called "fan-out and fan-in", where multiple functions are executed in parallel, and then the orchestrator waits for all functions to finish. The final aggregation step is triggered immediately after all parallel tasks are completed. He provided a customer use case for this pattern. Gillum also presented two more workflow patterns for Durable Functions: Human Interaction and Aggregator.
Besides workflows, developers can also leverage the actor programming model in Durable Functions. Gillum said:
Actors will be a first-class concept in Durable Functions, alongside orchestrations. Customers will be able to use one or both of our stateful programming models in the same application, depending on their needs.
The actors are represented by so-called entity functions, and like orchestration, this function type can be triggered. These entity functions can be written in C#, or other languages like JavaScript Gillum stated. He went through the entity concept and sample code. Furthermore, Gillum laid out the similarities with virtual actors:
- Entities are addressable via an entity ID
- Entity operations execute serially, one at a time
- Entities are created implicitly when called or signalled
- When not executing operations, entities are silently unloaded from memory
However, Gillum stated the entity function in Durable Functions is not another 'actor' framework like Akka.Net or Orleans. The difference between these frameworks are:
- Serverless nature
- Durability over latency
- Reliable, in-order messaging
- No message timeout
- One-way messaging
- No deadlocks
- Integration with orchestrations
This talk, and most other presentations at the conference, were recorded and will be made available on InfoQ over the coming months. The next QCon London 2020 is scheduled for March 2 - 6, 2020.