Durable Execution in DevOps: How Uniphar Built Reliable Systems with Dapr Workflow

Company Background

Uniphar is a global pharmaceutical and medtech manufacturing partner with roots going back to 1967, when it began as a small co-operative of pharmacies in Ireland. Over the decades, Uniphar grew, largely through acquisition, to operate across 160+ countries with 200+ multinational partners. Its core mission is to ensure people receive critical, life-saving drugs when they need them, delivered in the most accessible and cost-effective way possible.

Growth through acquisition brought significant engineering challenges including the fact that newly acquired IT systems inherited varied widely in technology stack and maturity. As Uniphar embarked on a multi-year initiative to modernise and migrate workloads to the cloud, it needed a methodology to handle the complexity of distributed, fault-tolerant systems — without distracting engineering teams from their core focus of building business applications.

Why Dapr?

When Uniphar's engineering team was defining its technology stack for future workloads, durable execution and workflow orchestration were non-negotiable requirements. The team evaluated a range of third-party frameworks, including Microsoft Orleans and Temporal, as well as the option of building an in-house solution. Dapr emerged as the winner in this evaluation. Oisín Vaclav Haken, Cloud Engineer at Uniphar, explains:

Key factors in the decision included:

• Reliability: The Dapr workflow engine allowed Uniphar to build reliability into their applications from day one.
• Configurability: Dapr component configuration is environment-specific, requiring no code changes across local and cloud deployments.
• Language agnosticism: Dapr works across any language and framework, allowing Uniphar's primarily Dotnet stack to be integrated with other languages if required.
• Observability: Dapr integrates natively with Uniphar's existing telemetry stack (Azure App Insights and Log Analytics). This is further complemented by Diagrid Conductor which helps Uniphar manage the operational concerns of Dapr.

By offloading core infrastructure concerns to Dapr, Uniphar's engineers were free to focus on application development and adopt Dapr Building Block APIs as needed as new architecture scenarios came along.

Cost Visibility Across a Growing Cloud Estate

As Uniphar migrated workloads to Azure, cost accountability became a pressing concern. Cloud resources are easy to provision, but the bill at the end of the month was surprising. With infrastructure often shared across multiple projects and streams, Uniphar needed a way to accurately split and attribute costs to specific cost center budgets.

The existing Azure-native tooling didn't go deep enough for Uniphar's needs. A highly distributed solution was required, capable of calling multiple APIs, tolerating timeouts, rate limits, and transient failures, while remaining extensible as new resource types and projects came online.

Mammon: Azure Cost Attribution Workflow

To solve this, Uniphar built Mammon, an application that runs monthly using Dapr Workflow to automate Azure cost allocation and stakeholder attribution.

How It Works

Mammon is a series of 400+ Dapr workflows that mirrors the Azure resource hierarchy directly in its application structure: Tenant → Subscriptions → Resource groups → Individual resources. A parent tenant workflow fans out into multiple subscription child workflows, each of which in turn spawns specialised resource-level workflows. From the resource level, there are cases in which resource splitting is done even further, for AKS node pools or VDI session-to-cost-centre mapping.

With this workflow structure being entirely in code, it allows direct access to the Azure Cost Management APIs, and provides a solution intuitive to extend and straightforward to navigate as the estate grows. Today, the monthly billing cycle and report uses about 400 workflows, but this is entirely dynamic as it depends on the number of Azure resources deployed, which is ever evolving. Child workflows are used as the isolation layer allowing Mammon to grow organically with the infrastructure size.

Once each child workflow has crunched its numbers, the split cost data is sent to a specialised Dapr Actor representing each business cost centre. The actor pattern provides transactional isolation allowing all workflows to independently report into it, but the actor contract ensures cost data is properly appended to its maintained state. This also provides an audit trail allowing developer teams to answer questions about unexpected cost increases, using the actor state to identify exactly which resources drove the change.

The entire process concludes with a CSV report, a format deliberately chosen for its compatibility with accounting systems, delivered by email to the relevant stakeholders at the beginning of each month.

Durable Execution in Practice

A critical requirement for Mammon was resiliency in their workflows. The workflow makes numerous consecutive Azure API calls, each subject to transient failures, rate limits, or authentication timeouts. A naive implementation would need to restart from the beginning on any one failure, re-running long API calls unnecessarily.

With Dapr Workflow's durable execution model, state is checkpointed to an append-only database after every activity. If the process goes down, whether due to a pod restart, a rolling AKS upgrade, or a network failure, it resumes from exactly where it left off, not from the beginning.

Fan-out/fan-in Pattern

Uniphar's initial approach ran all workflows — including child processes — fully in parallel in a fan-out/fan-in architecture. As the number of Azure subscriptions, resource groups, and resources grew, this led to uncontrolled concurrency. The team adjusted this architecture due to hitting teething limits. Subscriptions now run in parallel, but within each subscription, resource workflows execute sequentially. This provides a sensible balance of throughput and control, given that performance is not a critical constraint for a monthly reporting job.

Stateful Actor Applications

KeyRotationTool: Security Automation

Not all of Uniphar's workloads run under Azure managed identity. Some legacy systems or specific deployment models still rely on key-based access to cloud resources. To manage this securely, Uniphar built KeyRotationTool, an application that uses Dapr Actors with persisted reminders to automatically rotate access keys on a schedule.

New resources are registered for key rotation at deployment time, integrating the tool directly into Uniphar's DevOps pipeline. In addition to scheduled rotation, the tool supports on-demand rotation, useful when a suspected security incident occurs or a key has been shared inappropriately. Currently KeyRotationTool manages 150+ Microsoft Entra ID applications per environment and are looking at expanding the usage to register other resources such as Azure storage accounts and Service Bus instances.

Frontgate: Legacy File Integration with Dapr

Uniphar also uses Dapr in Frontgate, a mission-critical application that manages legacy file-based integrations using the Dapr Jobs API. Business users configure integrations through Frontgate, which handles SFTP uploads and moves files to locations where SAP processes can pick them up. Frontgate runs jobs that are triggered at various intervals, some running every 10 seconds, and can process over 400 jobs at a time. Given its high scale and critical nature, the app is configured for multi-regional replication, allowing it to run across multiple geographies while using Dapr actors to maintain the necessary transactional contracts per region.

Dapr Workflow, Actors, & the Durability Layer

Dapr's API building blocks form a natural infrastructure abstraction layer that are core components of Uniphar's application suite. Dapr Actors are individual units of logic with their own state and identity, capable of running at high scale and communicating with each other. Dapr Workflow sits as a higher-level abstraction on top of the actor pattern, managing the state and lifecycle of those actors automatically. Above that, Dapr Agents provides an orchestration layer for multi-agent workflows, allowing for a completely open-source, llm-agnostic agent framework.

This stack means Uniphar can select the right level of abstraction for each use case, with a clear upgrade path as requirements evolve. Uniphar is already exploring Dapr Agents for personnel onboarding and offboarding automation, having found the workflow tooling in other agent frameworks to be insufficiently mature for production use.

Alternative Resiliency and Security Frameworks Evaluated

Uniphar evaluated multiple other frameworks when deciding on what durable application framework to use including Microsoft Orleans and Temporal.

Orleans — Generationally Outdated

Orleans was decided to be generationally outdated when compared to Dapr. For example, Dapr supports multiple languages and customization by actual configuration as opposed to code representing major advantages over Orleans. The level of maintenance, including the number of active maintainers, feature and fix cadence was also a major concern. Uniphar concluded that for planned features, Orleans was not stable to the level that would allow teams to build on top of it. With Dapr, Uniphar was attracted by the real runway of features and fixes from a growing and vibrant community.

Temporal — High Latency, and Minimal Distributed Runtime Functionality

Uniphar's primary issue with Temporal was the level of overhead latency that was seen when running even basic workflows especially under load, high frequency or with a large workflow count. The team evaluated that under these conditions the latency between wrapped activity duration and end-to-end workflow duration was at the range of hundreds of percent. Additionally, Temporal is a durable workflow engine and as such covers only part of Dapr's surface area of functionality. For the use cases planned, Temporal was found lacking "plain" jobs with reminders and/or actors. For the planned multi-region feature, this would also require Temporal Nexus, which was at the time in its infancy and initial testing was not successful.

Key Takeaways

1. Durable execution removes the fear of failure. By checkpointing state after every activity, Dapr Workflow ensures long-running processes complete reliably, without expensive reruns of already-completed steps.
2. Use workflows to mirror your complex business processes. In this case, Mammon's Azure resource hierarchy workflows directly implements a solution to a custom problem entirely in code, making it extensible and easy for developers to debug.
3. Actors provide transactional isolation at scale. Using a Dapr Actor per cost centre gave Uniphar a clean, auditable way for parallel workflows to write to state while respecting turn-based concurrency.
4. Choose the right workflow pattern. Running all workflows fully in parallel can lead to loss of concurrency control as the estate grows. Uniphar found that parallel subscriptions with sequential child workflow execution struck the right balance.
5. Adopt incrementally. Uniphar started with a spike, shipped an application, and gradually expanded Dapr's footprint across their estate, using Dapr's opt-in Building Block APIs. Now they are evaluating Diagrid Catalyst for advanced workflow scenarios.

Key Resources

• This session was presented at KubeCon Europe in Amsterdam in March 2026: Durable Execution in DevOps: How Uniphar Built Reliable Systems with Dapr
• Diagrid Catalyst Enterprise — AI agent and workflow orchestration platform
• Manage Dapr on Kubernetes with Diagrid Conductor
• Dapr Workflow overview
• Dapr Workflow Patterns
• Dapr Actors overview
• Mammon is open-source and available on GitHub