Unlike AWS Step Functions Function Workflows are written as code in one of the supported programming languages. A domain specific language is not used. The workflow itself is written in a function too. As a result the function orchestration in itself is a function and it does not rely on an external scheduling solution like AWS Step Functions [BCF+17]. By default all child functions, called activities in Durable Functions, are called asynchronously. If you need to wait for them to complete before the workflow can proceed the await functionallity can be used [Mic18d].
This is the native approach of the programming language to asynchronous programming [Mic19g], creating a unified programming experience for writing workflows. To model the workflows C#, F# or JavaScript must be used for the implementation of the functions and the workflow definition [Mic18f]. an example of an orchestrating function is shown in Listing 5.5. The code you write is very similiar to normal programm code. The only main difference is the way activities are called. In comparison to just calling the function like you normally would. It is necessary to use the
DurableOrchestrationContext to call the function. Invoking the child activity is also not done by
the method name, but instead by the name set through the FunctionName attribute [Mic18e].
While Step Functions limits the size of the input payload for functions to approximately 32.000 characters, Azure does not come with such a limitation. Instead Azure automatically handles caching of larger payloads in a storage account. To reduce file size all files larger than 60KB get compressed [LSP+18]. As a result there was no need to implement the caching ourselves instead the caching mechanism provided by Azure was used.
Azure Durable Functions categorizes functions involved in a function workflow into three categorizes 1) client functions, i.e., functions that will create, launch and manage the workflow through an external trigger, 2) orchestrator functions, i.e., functions that define the workflow and 3) activity functions, i.e., the functions that perform the actions in the workflow. In our implementation the client function is triggered using a HTTP trigger, this function also checks the data sent to ensure the workflow can process it. To define a client function an external trigged, for example, a HTTP trigger must be bound to the function and the method header definiton must contain a
5 Implementation on Microsoft Azure
shown in Listing A.8. Unlike AWS such a client function is mandatory to launch a function, while it was possible to directly bind the AWS Step Functions workflow to an endpoint from the API Gateway. To define an orchestrator function the DurableOrchestrationContext must be passed to the method
implementing the workflow with the OrchestrationTrigger attribute attached to it, as shown in
Listing 5.5. Listing A.9, shows the definiton of the GenerateMatrix activity function as shown
there activity functions need the input object, in this case a string14, with the ActivityTrigger attribute attached to them [Mic18e].
Functions Size Repository Size Workflow definition size
Azure Durable Functions 69 60 44
AWS Step Functions 77 82 125
Table 5.3: Comparison of the code- and workflow definition sizes of matrix multiplication use case
on AWS and Azure
As illustrated in Table 5.315, the code size and the size of the workflow definition on Azure is smaller than on AWS. The main reason for this is the way simpler implementation of the caching interface. While it is just an in memory storage on Azure, requiring no configuration. The AWS implmentation has to read the environment variables to determine the name of the caching bucket and its region. Also the S3 client must be initialized, requring lines of code to do so. All of these steps are not necessary on Azure Functions reducing code size. The workflow definition is almost three times smaller because it is defined in code rather than using a verbose DSL to define the workflows. For example The parallel portion requires 13 lines per worker resulting in 65 lines to define all five workers. On Azure the definition of the complete parallel multiplication takes 16 lines of code. Testing a Durable Functions workflow is very easy because the Function Host, part of the Azure Functions Core Tools, can run Durable Functions on the developers machine. Speeding up the development process by a lot. However this feature comes with one downside: it requires a storage account to store the payloads, even when running locally. This feature might support the afforementioned Storage Emulator but this work did not investigate the support for it.
One issue with Azure Durable functions is the lack of tracablility in comparison to AWS Step Functions. On Azure Durable Functions the launch of a workflow using the client function returns a URL, with it one can retrieve the current state of the workflow however this feature is very limited. The current state does not inform the caller about the activites that currently get processed instead the current state just tells the caller whether the workflow is running, has failed, was terminated or did run successfully. Compared to the in depth tracablility available through the AWS web ui on Step Functions. It is important to note that MIcrosoft advertises better diagnosis when combining Durable Functions with Application Insights16. However this work does not investigate this further17.
14String was used to pass the size because an integer variable did not work.
15For this comparison imports, log outputs, empty lines and comments have been removed on both platforms. The size
of the workflow definiton on Azure is the length of the method defining the workflow. On Step Functions the length of the YAML file used to define the state machine was used. On Azure we have ommitted the client function to launch the workflow since it is not included in Step Functions too.
16https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
17https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-diagnostics 50