S204 - Azure Durable Functions for serverless .NET orchestration - Jeff Hollan

[@sureshsambana5219]

Crystal clear presentation. Learnt a lot from this video. Thank you so much Jeff Hollan.

[@kirankkadam]

Very well presented. Would love to see more video's from Jeff.

[@archie1804]

Thank you very much. All of that I needed was here.

[@anthony.7777]

Brillant talk, thanks Jeff !

[@pequod4557]

Thank you so much for this well-made presentation!

[@atifzafarkhan6703]

Awesome video !! Great contents to start with :)

[@ashutoshtriptiSharma]

I like the examples. Thanks Jeff. Well explained

[@jamesmorey1561]

Love it! I can create single-responsibility Functions and glue them together with Orchestrators to form flexible 'workflows'.

[@vivekvardhan2812]

Hey James.. Do you have any such example on github or some material about any good design patterns to follow? it would make complete sense to create a whole bunch of single-responsibility functions and just string them and reuse them in multiple orchestrators to create diff workflows :-)

[@annablendermann]

Great video. Thank you Jeff!

[@RtoipKa]

When it comes to cost what you are describing is consumption plan I think. But you can't use it with ManagedIdentity. You need to pay for app service plan.

[@leroylimll]

Hi Great Session!! Really learnt a lot here. Just a quick question.... is there a sample for the Human Interaction use case as shown at around the 14min mark?

[@nagrotte]

Is a durable function have the same limitation as an azure function; for example The time limit to complete and the maximum number of instances that it can spawn? if a durable function calls 2 functions F1, F2 and F3; if the execution of these 3 things put together is greater than 10 minutes, will Durable function quit?

[@yetanotherchannelyac1434]

This is great. SDK-focused Durable Functions seem really good for certain use cases! How do you price Durable Functions?

[@NonnoSgrenf]

Every time an orchestrator is started it generates a new workerID right?

[@BloodyCallus]

I am geeking out hard on the durable functions and parallelism. Amazing stuff, are there any limitations to I/O ? We're trying to orchestrate the backup/restore of large Azure MySql DBs.

[@coderider3022]

I think the azure automation service might be a better fit here ?

[@sipwhitemocha]

This video is excellent

[@amandeepsinghpathania2482]

Great video

[@sravankumar9462]

I have a azure pipeline at one point I am using azure function to refresh tables in azure analysis service but it is taking long time .so I want to use durable function but I am unable to connect to azure analysis service from activity function .can anyone help ??

[@mptjeNL]

just wondering ? the durable function template when you add a new function, where is this availble. i have all the latest bits but not this template :)

[@JeffHollan]

Make sure you are using the v2 .NET Standard version when adding a new project. The v1 .NET Framework templates don't show it currently. Should be there for latest bits in VS 2017 though

[@ProGaming-kb9io]

good intro. but it is start in14:13

[@2005Azm]

Wonderful !

[@imsandeepsharma]

how to pass multiple input to DurableFunctionsOrchestrator from DurableFunctionsHttpStart function in powershell

[@coderider3022]

Docs confirm 1 object so you need to use a class of some type or a tuple etc to have multiple bit of data. Same flaw in activities, can use the get input method or via bindings

[@codewithparveenyadav]

this is wonderful

[@andersnielsen6319]

First, we are told that the orchestrator must only call deterministic APIs. Next, Jeff proceeds to call a function from the orchestrator that returns "the last set of transactions". My head is exploding. Why not gather the transactions (i.e. determine the workload) in the starter function and pass them as a parameter to the orchestrator?

[@stuartlynch1191]

The activity functions do not need to be deterministic, just the orchestrator function. So the non-deterministic call to get the last set of transactions is done in an activity function. The first time the orchestrator function awaits the activity call to get the transactions, the work (calling the api) is scheduled and the orchestrator shuts down. On all subsequent replays of the orchestrator, it uses the list of transactions that has been written to the orchestration history as the result of the activity function. The orchestrator function is still deterministic because the list never changes, it is only retrieved once then that result is stored for each subsequent replay. Hope that helps :)