Note: If you prefer to listen rather than watch, you will find the DevOps Accents podcast here.
Dapr Is Changing the Way We Build Distributed Applications
Kubernetes has revolutionized how we deploy and scale applications—but it doesn’t answer a deeper question: how should applications actually work once they’re running? Most development teams still end up writing the same boilerplate code for retries, messaging, state management, and secrets, often repeating the same mistakes along the way.
That’s where Dapr comes in. In the latest episode of DevOps Accents, Leo Sushif (co-founder of MKDev) sits down with Mark Fussell, co-creator of Dapr and former Microsoft architect behind Azure Service Fabric, to discuss why developer-first runtimes matter, the hidden gaps in today’s platforms, and how the technology behind Dapr is already powering a new wave of AI agents.
From Azure to Dapr: Mark’s Journey
Mark shares his three-decade journey in distributed systems, from working on early .NET technologies to leading the creation of Azure Service Fabric, the foundation for services like Cosmos DB and Azure SQL. His experience building platforms at Microsoft revealed a recurring challenge: developers were reinventing the wheel every time they needed resilient communication, workflow orchestration, or stateful services. That insight eventually led to the birth of Dapr, now a CNCF-graduated project and the foundation of his company, Diagrid.
Kubernetes Isn’t Enough
While Kubernetes is an excellent orchestration platform, it doesn’t solve the complexity of application logic. Developers still need to stitch together retries, secure service calls, and distributed state management on their own. Dapr addresses this gap by providing APIs for common distributed patterns—like service invocation, pub/sub messaging, workflows, and state storage—through a lightweight sidecar model.
This means instead of binding code directly to a specific library or broker, developers can call a local Dapr endpoint, while platform teams retain flexibility to change the underlying infrastructure without rewriting application code.
Productivity, Reliability, and Real-World Gains
Organizations using Dapr have reported:
- 30–50% faster time to production,
- up to 70% fewer bugs,
- and far easier infrastructure swaps (e.g., moving from Kafka to RabbitMQ in hours rather than months).
[Read about this, and more, in the 2025 State of Dapr report]
Instead of each team coding their own “mini-Dapr” for messaging or retries, they can lean on well-tested APIs built for scale.
From Distributed Systems to AI Agents
One of the most exciting parts of the conversation is how the same patterns behind Dapr are now enabling agentic AI systems. With Dapr’s durable workflow engine, developers can build AI agents that remember past steps, recover from failures, and coordinate multiple services reliably—something essential when moving beyond toy demos to enterprise-grade AI.
Diagrid has even released Dapr Agents, a framework built on top of Dapr’s workflow engine, making it one of the few production-ready solutions for building AI agents today.
Looking Ahead: Observability and Edge
Mark also shares insights into Diagrid Conductor, a management and observability tool for running Dapr in Kubernetes environments, as well as Diagrid Catalyst, a platform for enterprise-scale workflows and agentic systems.
The discussion closes with a forward-looking take on sidecars, edge deployments, and even running Dapr on Raspberry Pis. Despite new runtimes like WebAssembly gaining traction, Mark is confident that the sidecar pattern will remain a cornerstone for distributed applications thanks to its flexibility and lightweight footprint.
Watch the Full Episode
If you’re curious about the future of developer-first runtimes, distributed systems, and how AI agents fit into the picture, this is a conversation you won’t want to miss.
