Azure Functions’ Durable Entities

Chris Gillum
4 min readMay 18, 2019

Hi! I’m Chris and I currently lead a small team of engineers working on Azure Functions. If you’re familiar with Durable Azure Functions, then you may have seen me on Twitter or GitHub. If you’ve never heard of Durable Functions, then I recommend you check out our patterns and concepts documentation that explains what it is and why you should care. I’m the original creator of Durable Functions so I thought it might be interesting to start writing about it.

Durable Functions 2.0

This year at Microsoft’s annual Build conference, we announced the alpha release of Durable Functions 2.0. The main new feature that we highlighted was Durable Entities. Durable Functions 1.x already allowed you to build stateful orchestrations using the Functions programming model, but in 2.0 we added the concept of entities to further expand on the types of stateful programming problems you can solve on the Azure Functions platform.

What are Entities?

If you’re familiar with the actor model, then you will immediately understand what entities are about. It’s important to note, however, that Durable Entities is not another actor framework, like Orleans, Akka, or Service Fabric Actors. Rather, it’s a complimentary development pattern that we’ve added to Durable Functions. But rather than going into details here, I suggest visiting our documentation page which explains everything further.

Why Durable Entities?

Durable Functions were designed to make certain coding patterns easier to implement in an event-driven, serverless environment. When we released the initial preview Durable Functions back in 2017, the concept of orchestrations went a long way to make several common stateful patterns trivially simple. However, there were a few stateful patterns that users cared about that were still difficult to build using orchestrations. Aggregation of events was one of them.

Illustration of the “aggregator” pattern in Durable Functions

Eventually we got in touch with some researchers from Microsoft Research who had a background in actor technology. After some discussion, we decided to work together to bring actor-like capabilities to Durable Functions to help us support more stateful scenarios. Our first goal was to specifically target the scenarios that orchestrations are not well suited for.

The programming model

The initial release of Durable Entities uses a functional programming model. An entity and its behaviors are defined as a single function, similar to the following:

Example of a Durable “counter” entity as a function

As you can hopefully see, an entity function is capable of loading and saving state and handling an arbitrary set of operations. Behind the scenes, the state is persisted to Azure Storage so that any process interruptions do not result in any data loss. Client APIs also exist which allow orchestrator functions as well as ordinary functions trigger entity functions. Entities can be triggered/queried via built-in REST APIs as well.

While the entity programming model is simple and straight forward, we recognized that some developers wanted to create Durable Entities which handle lots of different operations, but don’t want to write long switch statements in code. Other .NET-specific actor frameworks, for example, support object-oriented programming models where each operations are modeled as methods in a class. In the next release, we’re looking to add some syntactic sugar that allows you to write a Durable Entity as a class, like this:

Example of a Durable “counter” entity as a class

In this experience, we use reflection to map entity operations to methods on your class. The class itself represents the state. When it’s time to persist the entity, it gets serialized as JSON and stored in Azure Storage. It’s not complicated and hopefully behaves the way you would expect.

We will support both methods, so if you like classes, you can use classes. Otherwise you can use straight-functions.

Multi-Language Support

Durable Functions supports multiple programming languages today. At the time of writing, orchestrator and activity functions can be written in .NET (C# and F#) and JavaScript. Support for languages like Python, Java, and PowerShell are still under active consideration (use the embedded links to vote for which language support we should add!). Entity functions in the initial release, however, can only be written in .NET. Support for durable entities written in JavaScript is coming soon.

Performance Considerations

Because durable entities is in alpha, very little effort has been made to optimize for performance. Rather, the initial effort has been on identifying a useful programming model. Performance and scalability is something we plan on looking into in subsequent releases.

Providing Feedback

Durable Functions is developed as open source software on GitHub. You can find our main public repo here. We welcome users to open GitHub issues as a means of reporting bugs, making feature requests, or asking questions. We also encourage developers to submit PRs for features or bug fixes that that would like us to release.

The alpha release of durable entities is primarily intended to gather feedback. We plan on shipping it as a GA feature in the near future, so now is the time to provide feedback that will help influence the priorities and the direction it takes. We hope you’ll give it a try and let us know what you’d like to see in future updates!



Chris Gillum

Partner Software Architect at Microsoft working on serverless computing platforms and programming models.