Stateful Serverless with Durable Functions

In August I was lucky enough to be invited to speak at Serverless Days Melbourne on the topic of Durable Functions and handling state across functions.

If you want to check out the talk, the video is online.

Durable Functions docs

Comments

[Renato Byrro]

Hi, interesting topic.

Many would argue that wiring functions directly is an anti pattern. Makes it difficult to introduce changes down the road, for example.approach

Alternatives could be any indirect way of calling functions internally: a msg-driven approach, an API gateway or application balancer in front of functions...

What's your view on that architectural topic and how useful durable functions can be if in an indirect call approach?

[Aaron Powell]

It's true that Durable Functions, like AWS Step Functions, aren't going to be suitable for every scenario as they do create an explicit relationship between the functions used.

Some scenarios that they are valid for are things like sequential processing, waiting for human interaction or monitoring another system.

Behind the scenes Durable Functions is using the approach you describe, using messages to do communication between the functions (using a combination of queues and table storage (in v2 the storage model is abstracted so you can swap that out)).

Now, it may seem like we're doing explicit linking of functions in the way they are called:

[<FunctionName("StartWorkflow")>]
let startWorkflow
    ([<HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "start/{input}")>] req : HttpRequest)
    ([<OrchestrationClient>] starter : DurableOrchestrationClient)
    input
    (logger : ILogger) =
    task {
        logger.LogInformation(sprintf "Starting a new workflow for %s" input)

        let! _ = starter.StartNewAsync(eventName, input)

        return OkResult()
    }

(snippet from my sample on GitHub)

But when we do starter.StartNewAsync(eventName, input) we are essentially dropping a message into a queue to be picked up by whomever is meant to listen to eventName.

This becomes even more powerful when we start looking at Entity Functions and start taking a more Actor-model approach to our architecture.