I saw Brett Hazen speak on Azure Durable Functions on Thursday night.

This was a meeting of the Twin Cities .NET User Group, but it was not at the usual locale. The Software Guild in downtown Minneapolis instead served as the venue for the talk and they are a coding academy. Azure Durable Functions extend Azure Functions and make them less likely to fail. Brett gave the example of the validation of a multiline report with Azure Functions, how it could be painful, and how the pain could be alleviated with Azure Durable Functions. Imagine if the report is broken into individual lines by one function, a function is called for each line for validation, and then the lines are then aggregated back into a report. (This is the Fan-in, Fan-out pattern.) The last step is tricky if the individual line validations are happening asynchronously instead of sequentially, right? How do you keep track of what is done and undone? Azure Durable Functions allow you to use state without a database to solve this problem. Azure Functions let you use C#, F#, JavaScript, Java, and Python and Azure Durable Functions let you use the first three of these. With the first two you may use precompiled libraries. A "trigger" entry point kicks off a Durable Function, typically an HTTP call. The trigger points to a "client" which is in C# a method which may take a few things at its signature, but amongst them always is an "orchestrator" which is deterministic, giving consistent results every time for given inputs unpolluted by any wildcard that could corrupt that such as temporary data or the time of day. DurableOrchestrationContext is the C# type for the orchestrator and the prose going forward will assume C#. It was, after all, a .NET talk. One thing to say about JavaScript is that you cannot use the async and await keywords in a client, but C# in contrast invites a pattern wherein you will hit checkpoints in a client whilst awaiting at the await keyword and these write a bunch of events to an event store. Event Sourcing is a pattern for such a store with its own history of what happened and where you are at and this allows a client to fail midstream and be recovered in such a manner that it can pick back up where it left off. Such explains the use of the word "durable" in the moniker Azure Durable Functions. Brett projected some of the tables used in Azure Storage Explorer which looked a lot like SSMS to me. In think HubInstances and HubHistory are the tables to really care about herein with HubHistory holding the event records. If you want to store your own data in some cloud tables too you should really provision your own account. It will cost you pennies to host the data as long as you aren't doing something really crazy and nothing to split off a second account. Orchestrations should be nonblocking. The Durable Functions Framework is built on top the Durable Thread Framework which is single-threaded. Control queues help you scale things out but you'll likely never use these directly. 64K is the limit for the average message size in Azure's messaging queue. Use try/catches to do error handling. Newtonsoft's Json.NET does serialization. Be wary of attempting to serialize the unserializable which in C# kinda means objects which have more than zero constructors yet zero constructors which take zero variables at their signatures. If the constructor expects something the object it is going to blow up when you serialize it. Microsoft.Azure.Functions.Extensions when looped in as a NuGet package allows for inversion of control. You may use singletons and transients (not singleton, created anew when called every time). Some things like Thread.Sleep can really throw a wrench in the works (avoid!) and, as I've mentioned in the name of being deterministic, you really can't use the clock. Off of your instance of DurableOrchestrationContext, probably called context, is a .CurrentUtcDateTime and a .CreateTimer for this sort of stuff to be used instead. The context also has some convenience URLs that may be exposed and called for other manipulations. For scenarios in which you wait for a day for an approver to maybe approve something, by way of a convenience URL, and then fall over to plan B when a day has elapsed, you will need to call a cancellation token on the timer when the approver does approve to clean it up. When you change your client how will you alleviate the pain of the rollout side-by-side with previous running versions? You could do nothing, stop everything in-flight, or roll out a brand new application. Brett prefers a watered-down version of the third way to go wherein you just have a new method with the version number directly in its name in the same application. External Orchestrations allow for infinite loops which should be avoided in regular orchestrations. You may have suborchestrations to break up what could become a big procedural mess in a client. There is the concept of Concurrency Throttling to manage how many instances of a client may run at once. You may mock a DurableOrchestrationContext with MOQ to unit test a client. Other things mentioned at this talk included Windows CE (which is Windows Embedded Compact or WinCE), an operating system for embedded devices, and the fact that Robert Martin (Uncle Bob) was the founder of Agile which I had not heard before. Shadow IT is any sort of app spun up at work outside of the permissions of the higher-ups and the blessing of the corporate entity via the proxy of higher-ups. IT here is for information technology just as you'd expect. Other things mentioned at this talk by Brett Hazen himself include Insomnia which is something like Postman, Azure Service Bus for SOA, and CsvHelper for CSV stuff. Polly lets you retry/rerun HTTP calls.