Feature Request: Enable Dapr Workflow in Azure Container Apps

[denniszielke]

Is your feature request related to a problem? Please describe.
I need to run reliable workflows using containers. Dapr Workflows seems like a very good fit: https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/ and I want to have available in ACA.

Describe the solution you'd like.
Support for Dapr Workflow.

Describe alternatives you've considered.
No alternatives.

Additional context.
Dapr Workflow is in alpha but already shows great value.

[itpropro]

It would be really great to have this available in Azure Container Apps, especially as an alternative to durable functions.

[nyemade-uversky]

@denniszielke Getting Dapr WF into ACA is something we're discussing! Would you be able to share more about the workflow scenarios you're seeing in the field?

[nyemade-uversky]

@itpropro I'd also be interested in hearing about you WF scenarios too!

[sparraguerra]

Hello, I have an usage scenario that I am currently implementing. I want to handle CosmosDb Change Feed for "referential integrity" of Azure CosmosDb documents and containers.

[Phiph]

Yeah bump for this too :D would love to see this in action!

[christophwille]

Will v1.12 https://github.com/dapr/dapr/issues/6508 with Workflows going Beta make this possible to be supported?

[sowsan]

Any update on this?

[itpropro]

@itpropro I'd also be interested in hearing about you WF scenarios too!

There are many scenarios, but mostly the same as the ones you would use durable functions for. If you want to discuss some, feel free to contact me. An update on this, especially as it has reached beta for a while would be appreciated :)

[WhitWaldo]

I'm eager to see this as well. Lack of workflow support, pre-stable as it might be, is a blocker to me using Azure Container Apps.

[itpropro]

I'm eager to see this as well. Lack of workflow support, pre-stable as it might be, is a blocker to me using Azure Container Apps.

At least according to the Docs, the container apps team is willing to support Dapr Beta states. It's also on the 1.13 Dapr roadmap to announce workflows as phase 1 stable, so I think there is no better time to start integrating it than now :) PS: Any updates @torosent ?

[greenie-msft]

Hi everyone,

Thank you for your patience as we work towards integrating workflow functionality into ACA.

As it stands, our goal is to release a public preview in January 2024.

I will keep everyone posted with updates as we approach the preview release.

[itpropro]

Hi everyone,

Thank you for your patience as we work towards integrating workflow functionality into ACA.

As it stands, our goal is to release a public preview in January 2024.

I will keep everyone posted with updates as we approach the preview release.

Sounds great, thanks for the update! Will there be a private preview?

[jaq316]

@greenie-msft ... Any news on the public preview release date yet?

[greenie-msft]

Hello everyone,

There has been a change in the timeline for releasing workflow support in ACA. Currently, Dapr WF has certain limitations, and we've received feedback that these limitations make it challenging to use the feature at scale in production. We want to ensure you have the best possible experience using our features, so we’ve decided to proactively address these limitations in our Azure distribution before making WF available in ACA.

I’ll be sure to provide regular updates on this thread as we approach a new release date for WF support in ACA. Thank you for your patience as we navigate through these improvements.

[samuelya]

Hello everyone,

There has been a change in the timeline for releasing workflow support in ACA. Currently, Dapr WF has certain limitations, and we've received feedback that these limitations make it challenging to use the feature at scale in production. We want to ensure you have the best possible experience using our features, so we’ve decided to proactively address these limitations in our Azure distribution before making WF available in ACA.

I’ll be sure to provide regular updates on this thread as we approach a new release date for WF support in ACA. Thank you for your patience as we navigate through these improvements.

Any updates on the release date, especially after the Dapr release 1.13? We are looking to use Dapr workflows in ACA for our Dev environment. Thanks.

[jaq316]

Hello everyone, There has been a change in the timeline for releasing workflow support in ACA. Currently, Dapr WF has certain limitations, and we've received feedback that these limitations make it challenging to use the feature at scale in production. We want to ensure you have the best possible experience using our features, so we’ve decided to proactively address these limitations in our Azure distribution before making WF available in ACA. I’ll be sure to provide regular updates on this thread as we approach a new release date for WF support in ACA. Thank you for your patience as we navigate through these improvements.

Any updates on the release date, especially after the Dapr release 1.13? We are looking to use Dapr workflows in ACA for our Dev environment. Thanks.

@greenie-msft ... Does the Dapr 1.13 release mitigate the issues mentioned?

[WhitWaldo]

@jaq316 Dapr 1.13 did not change much about the mentioned issues. From a brief chat I had with someone in the Discord channel, I think, a week after the release, it was shared that the NoSQL issue is scheduled to be tackled in the next release (1.14) alongside the initial release of the distributed scheduler, which will solve the horizontal scaling issue (though maybe not for Workflows immediately - more on this in a bit).

I would like to reiterate to @greenie-msft that I would appreciate it if ACA simply ran whatever is available in the latest public/stable release of Dapr and instead highlight that only stable components receive support - use of any other functionality is done at the developer's own risk, and then link to the current Dapr known limitations for Workflows and other blocks. Having ACA support a different build of Dapr than what is available publicly seems like it'd lead to more developer frustration than not and repeatedly eliminate ACA from consideration as a deployment destination because of the unknown lag time between new Dapr functionality and the support timetable from Microsoft (as here).

The documentation indicates that Azure Container Apps only offers fully managed versions of the stable Dapr APIs. By this reasoning, it's unlikely that Workflow will be supported before mid-2025, well after the rest of the Dapr developers will have been using it. Why? (Take all the below with a grain of salt because while I contribute to the Dapr project, I am not privy to any release schedules or priorities listed outside of those shared in public channels on Discord and via the issues and milestones in the various Github projects).

• The horizontal scaling issue will be remedied by the release of the Distributed Scheduler which is anticipated to be released in 1.14 (say, early summer 2024), but that will show up in an Alpha release first, meaning that ACA won't host it either.
• Actors will need to be updated to realize all the benefits of the new scheduler. While this might be done alongside the 1.14 release, I suspect they'll want to take the time to get it right since Actors are currently marked as a stable component, so they can't be breaking anything, so assume that instead is released with the 1.15 release (fall 2024).
• Workflows will likely get the scaling benefits from the Actors without a ton of extra work, so they might be released alongside the 1.15 release in the fall, but they'll likely continue to be in the beta state as they're evaluated for stability. One can hope that the Distributed Scheduler would similarly be promoted to beta here, but that would be a surprisingly fast turnaround in my experience.
• This means it's not until perhaps the next release that the Workflow is released as stable in the 1.16 release (winter 2024). But given the ACA policy of only hosting stable APIs, they'll have to decide whether they bend the rule to support the Distributed Scheduler dependency which will almost certainly not be marked stable yet or wait until it is, so that might not be until the 1.17 release (spring 2025).
• Assume everything is marked as stable now - the ACA team will still presumably need a quarter to then add Dapr to the product. This is no longer reliant on the Dapr release schedules, but as this would be something the Dapr team is heavily promoting, my guess is support arrives just in time for Build 2025, so the end of May.

@jaq316 So that really leaves three choices: 1) Don't use Workflows at all and wait for it to be supported (hopefully) just over a year from now in ACA, but otherwise enjoy this managed deployment environment for all other stable APIs. 2) Use Workflows, but find somewhere else to host your project and Dapr. 3) Run arbitrary sidecar containers alongside your application in ACA (e.g. opt-out of the Microsoft-provided Dapr implementation and host your own). I have no examples of doing this, but as was pointed out in the ACA Discord channel, it's just a matter of modifying the Bicep template to add your own sidecars per the documentation.

[itpropro]

Thanks for the interesting insights @WhitWaldo! It's good to see the timeline so clearly lined out, which also shows the issue with the current release strategy in my opinion. I also think that ACA should not use a different versions of Dapr than the rest of the world, but I definitely think there should be a opt-in to beta (and maybe even alpha) APIs. This would at least take away the initial implementation delay for stable APIs, as they are already tested and received feedback in ACA and there are a lot of metrics already available for the product team. That is in my opinion what previews in Azure are for, which offer no SLAs and users can accept the risk, but at least test it. From my experience, a lot of the features in beta are totally usable and behave like the beta things in K8s (that are basically stable), I know a lot of customers who willingly use beta APIs for Dapr and other cloud native services in production. For alpha APIs I can somewhat understand that they are not available in a managed service like ACA, as the underlying architecture can still change completely, but for Beta versions that are already in that stage for some time, I would really like to have them available in ACA.

[humandigital-ruud]

Thanks for the insights @WhitWaldo !

Run arbitrary sidecar containers alongside your application in ACA (e.g. opt-out of the Microsoft-provided Dapr implementation and host your own). I have no examples of doing this, but as was pointed out in the ACA Discord channel, it's just a matter of modifying the Bicep template to add your own sidecars per the documentation.

I wonder if that is possible and would love to see an example of it. How would you get the custom sidecar to communicate with the other (standard) sidecars? I think this may be locked down in ACA, but I could be mistaken.

We are currently running a small part of our orchestration layer on AKS only to support Dapr Workflow and the rest on ACA, but it is obviously not very cost effective nor an efficient system architecture (we found out too late that WF was not supported, once we already rolled out everything on ACA). I hoped for WF preview support in ACA in Q2 of this year but looking at your breakdown @WhitWaldo, it seems like we may have to wait much longer for that.

[greenie-msft]

Hi everyone,

I appreciate your continued patience as we’ve been at work developing workflow support in ACA. The good news is we are nearing a preview. I will have more exciting updates to share over the next few weeks so please stay tuned!

[jaq316]

@greenie-msft ... Any news yet?

[greenie-msft]

Hello everyone,

I want to apologize for not being active in this discussion recently. As many of you may be aware, Microsoft is currently prioritizing enhancements of our security measures. This has impacted the timeline of our feature development work.

Despite our focus on security, we remain dedicated to providing support for durable workflow/orchestration and are looking forward to rolling out these capabilities soon.

To stay up to date with our progress and availability of the workflow preview, I encourage you to sign up via this link: https://aka.ms/managedworkflow/signup.

I will keep you updated with the latest information as soon as it becomes available.

Thank you, Nick

[jpiquot]

@greenie-msft hello. any updates on the roadmap of this feature?

[hanno2003]

@greenie-msft is there any update on upgrading Dapr to v1.13? we're facing more and more issues on Dapr sidecar crashing on restarting the container and thus, missing subscription to events bus. Restarting each container after each update is quite annoying. AFAIK Dapr fixed this issue - for us in relation with gRPC - within 1.13.

[jpiquot]

From Microsoft:

The Workflow features of Dapr cannot be used in Azure Container apps at this time. Dapr has a policy where features are enabled in ACA only when they are considered "stable". As an "alpha" feature, Workflow hasn't yet met that bar. There is no specific ETA at this time. Discussion

I find this policy concerning. While I understand the intent to only enable stable features, this approach seems overly restrictive given DAPR's current maturity state. A majority of DAPR features remain in alpha or beta status, for example only about 30% of bindings are marked as stable (even features that have been present since DAPR 1.0 still carry an "Alpha" label.). Following this policy strictly means ACA users are cut off from a large portion of DAPR's capabilities.

This creates a significant gap between what's available in standalone DAPR versus ACA. The lack of feature parity has persisted for over a year, which puts ACA developers at a considerable disadvantage.

Perhaps Microsoft could consider a more nuanced approach? Rather than a binary stable/unstable classification, you could allow users to opt-in to beta features with appropriate disclaimers. This would better serve developers who have invested in ACA while still maintaining transparency about feature stability.