Azure Logic Apps: stateful and stateless workflows overview and performance comparison.

Azure Logic Apps Standard is a new deployment option for creating and running automated workflows in a single-tenant environment. This option provides several benefits over the traditional (and probably most known) Consumption plan, including more built-in connectors, higher throughput and lower costs at scale. This new plan also offers more control and fine-tuning capabilities around runtime and performance settings, as well as integrated support for virtual networks and private endpoints.

In the Standard plan, you can create one or multiple workflows that run in single-tenant Azure Logic Apps or an App Service Environment v3 (ASE v3). This plan supports local development on Windows, Linux, and Mac, and enables custom connector extensions. Additionally, it allows you to leverage the containerized runtime to run Logic Apps locally, in the cloud, or on-premises with virtual network capabilities.

In Azure Logic Apps Standard, you can create two types of workflows: stateful and stateless.

Stateful Workflows

Stateful workflows in Azure Logic Apps are designed to maintain state information between runs. This means that they can store input, output, and workflow states in external storage, allowing for detailed run history and the ability to resume from a specific point in case of failures. Stateful workflows are ideal for long-running processes and scenarios where reliability and durability are crucial.

Stateful is the standard workflow’s type for Azure Logic Apps Consumption and for Power Automate.

Stateless Workflows

Stateless workflows, on the other hand, do not maintain any state information between runs and they run entirely in memory. Each execution is independent, and the workflow does not rely on any previous executions. This makes stateless workflows faster and more efficient, as they do not have the overhead of managing state in storage.

When to use stateful or stateless workflows?

When creating Azure Logic Apps workflows with the new Logic Apps Standard platform, you need to select the type of workflow you want.

Stateful workflows is usually the default choice, suitable when you need to have long-running and reliable workflows and when you need to preserve the workflow’s state (every action execution is logged).

Stateless workflows are probably less known but they are a great choice when you have short-lived workflows (execurtion must complete in maximum 5 minutes) and when you need low latency and high throughput. In Stateless workflows, the history is not saved.

What about performance?

Stateless workflows are much more performant than stateful workflows, but they have a maximum timeout of 5 minutes (this is due to the fact that they run entirely in memory).

If this time limit is not a problem for your process, using a stateless workflows helps a lot on increasing the performance of your tasks.

Just to give you an example, in a recent conference I’ve done a demo creating the same business process with Azure Logic Apps Standard using first a stateful workflow and then a stateless workflow.

The business process was the following:

Here we have an HTTP-triggered flow that retrieves data from Dataverse, performs some calculations (plius other operations) and then returns the result of the calculation to the caller.

What happens if I trigger the two instances of the same workflow (stateful instance and stateless instance)?

Here is the response from the stateful instance:

and here is the response from the stateless instance:

As you can see from the response time, the stateless is a lot faster! Here is a chart taken from different executions, that clearly show the big difference:

What about moving a workflow from stateful to stateless?

This is a question I’ve received after my recent session at the WPC conference in Milan.

If I have a workflow created in the traditional stateful model, can I move it to be stateless by changing a property?

When you have designed a worklow in the Azure Logic Apps Standard designer, you can easily switch to the code view and here you have a property called kind. This property contains the type of the workflow:

Question was if it’s possible to change the workflow type by changing the value of this property (from Stateful to Stateless).

If you try to do that, this is what happens:

You have an error:

Workflow validation failed for the workflow 'YourWorkflowName'. {"error":{"code":"InvalidFlowKind","message":"The existing workflow 'YourWorkflowName' cannot be changed from 'Stateful' to 'Stateless' kind."}}

You cannot change a workflow type just by changing the kind property in the workflow’s code. This is by design (at least now) and its due to the complexity of what happens under the hoods when you design and save a stateful workflow. To make a workflow stateful, the platform needs to create a set of resources on storage (to preserve the state and more) and this aspect blocks the change of the workflow’s type.

If you’re in this situation, what you can do is to copy the workflow’s code from your stateful workflow instance, then create a new stateless workflow and paste the previously copied code (here by changing the kind property to Stateless after pasting).

Migration done!

Conclusion

Azure Logic Apps Standard stateless workflows are often forgotten, but they are extremely useful when you need to create high-performance flows.

Remember that from a main workflow (maybe a stateful one) you can call a child workflow to perform some operations and this child workflow can often be a stateless one (to increase the speed of the particular operation):

Keep this in mind and your low-code integrations will fly…

Original Post https://demiliani.com/2024/12/18/azure-logic-apps-stateful-and-stateless-workflows-overview-and-performance-comparison/