Serverless Orchestration with Azure Durable Functions

Editor's Notes

• #4: Overview – Serverless and what are Azure Functions Dev tooling – Tools along with deployment and monitoring capabilities
• #5: Serverless is the culmination of several iterations of cloud platforms. The evolution began with physical metal in the data center and progressed through Infrastructure as a Service (IaaS) and Platform as a Service (PaaS).
• #6: With serverless, infrastructure is abstracted. Serverless further abstracts servers by focusing on event-driven code. Another feature of serverless is micro-billing.
• #7: Dynamically and elastically scale to meet demand. Allows you as the developer get to focus on the fun stuff…your code and business logic. Everything else is taken cared for you. This drastically increases time to market.
• #8: At the center of serverless is FaaS. Break it up into single responsibility. No state…but when you require state it gets tricky.
• #10: Some sequencing that needs to happen and I have to chain them all together. If I want to parallel some work and then pull in the results into one function Waiting for external events Watcher pattern Long running http requests Human interaction and I don’t want to wait forever…I want a timeout. The answer to some of these is I don’t know. Let’s take a look at two patterns and how we can solve them
• #13: Durable Functions is an open source framework for Azure Functions. Allows you to coordinate long running stateful workflows in code. They define workflows in code. No JSON schemas or designers are needed. They can call other functions synchronously and asynchronously. Output from called functions can be saved to local variables. They automatically checkpoint their progress whenever the function awaits. Local state is never lost if the process recycles or the VM reboots. Similar to Logic Apps but without a workflow designer.
• #14: In Durable Functions we introduce the concept of an orchestrator function. The starter function triggers the orchestrator to start the execution. Often this starter function is an Http endpoint. Once the starter has called the orchestrator function, it goes to sleep for the rest of the day or until it’s triggered again. This reduces the cost significantly. The orchestrator function is responsible for calling and receiving the output of the activity functions (what you know as normal functions). The activity function output becomes part of the local state of the orchestrator function.
• #18: Using this client, you start a new Orchestration function with the StartNewAsync(string, object) where the 1st parameter is the name of the durable orchestrator function and the 2nd parameter is the JSON-serializable input value which you would use to provide input data to the orchestrator. The second key thing to notice is that the orchestration client returns a CheckStatusResponse which contains a set of URLs for inspecting the status of an orchestration execution. The default endpoints you get back are:
• #20: You will notice that the function is decorated with a OrchestrationTrigger attribute which exposes the DurableOrchestrationContext This context is what is used to invoke and interact with Activity functions. As mentioned above, orchestrator functions checkpoint their progress after each await. The above code therefore executes each Activity function in series, only progressing to the next function after the current invoked function returns. If you wanted to execute all of the above Activity functions in parallel, you would create a list of Task objects that represent the asynchronous operations and then call Task.WhenAll(List<Task<string>)
• #21: It performs some logic in a stateless way and returns a response to it’s parent orchestration function. You will notice that this function is decorated with an ActivityTrigger attribute.
• #22: We can easily test this out by pasting the starter function URL into the browser or via PostMan. We will then get back a list of URLs as mentioned earlier. If we navigate to the StatusQueryGerUri, we can observe the status of the durable function instance. In this example the orchestrator client is an HttpTrigger. It’s important to note that the OrchestratorClient can be triggered by any of the supported Azure Function triggers: TimerTrigger, QueueTrigger, CosmosDbTrigger, etc.
• #23: 22
• #27: Orchestrator code must be deterministic, as it will be replayed multiple times and must produce the same result each time.