Kubernetes Isn’t Enough with Mark Fussell from Diagrid & Dapr |🎙️#62
Kubernetes alone isn’t enough! This is what we discuss with Mark Fussell, co-creator of Dapr and Diagrid co-founder. How Dapr’s sidecar gives developers clean APIs (pub/sub, service invocation, secrets, state) with tiny overhead? And how durable workflows and “agentic” apps with Dapr Agents actually function? Also in this epsiode:
- A short history of architecture models;
- Differences between service meshes and Dapr;
- Agentic systems and conductors: what is what?
- The future of agentic applications;
- Will the sidecar model go away?
You can listen to episode 62 of DevOps Accents on Spotify, or right now:
Mark Fussell has spent decades building distributed systems. From early client-server architectures to modern agentic workflows, his journey through Microsoft and his current work with Dapr and Diagrid highlights just how far infrastructure, tooling, and architectural thinking have evolved—and what challenges still remain.
From Middleware to Dapr: A History in Patterns
Reflecting on his time at Microsoft, Mark shared how the evolution from client-server to service-oriented architectures pushed companies to look for new ways to scale and adapt faster. In the 2000s, technologies like XML and message buses helped connect applications across machines. Yet as demand for agility grew, businesses moved toward breaking up applications into smaller, independently deployable services.
This shift laid the foundation for Service Fabric, which Mark helped build as a core platform within Azure. But as Kubernetes and containers took off, developers needed a runtime layer that simplified communication, state handling, retries, and observability across these microservices. Enter Dapr: an open-source project designed to bring proven distributed systems patterns to developers in a practical way.
Why Dapr Is Not Just Another Service Mesh
One common misconception is that Dapr overlaps with service meshes. Leo asked Mark to unpack the distinction, especially given that both can use a sidecar pattern. Mark explained:
“Service meshes operate at the networking level. They see only packets. Dapr, on the other hand, is focused on application-level patterns—things like service invocation, state management, pub/sub messaging, and workflows.”
Rather than focusing on network plumbing, Dapr offers APIs and SDKs that help developers abstract away infrastructure concerns. For instance, instead of directly integrating with Kafka or Redis, a service can call a local Dapr sidecar using HTTP or gRPC. That sidecar handles retries, TLS, secret management, and more, regardless of what backend is being used.
The sidecar pattern also plays a key role here. As Mark put it:
“It creates a clean separation between your business logic and infrastructure concerns. And latency-wise, a call through the Dapr sidecar adds under a millisecond—negligible for 99% of use cases.”
Dapr for Agentic Systems and Durable Workflows
As agent-based systems become more popular—whether for reviewing code, processing logistics data, or automating business decisions—Dapr has quietly been laying the groundwork for reliable execution.
“Agentic systems are distributed systems with smarts,” Mark said. “They still need coordination, state management, service invocation, and observability.”
That’s where Dapr’s built-in workflow engine shines. Unlike simple orchestration tools, it provides durable execution across multiple steps and services, recovering gracefully from failures. Dapr Agents, a framework introduced in the Python SDK, builds on this concept by enabling “durable agents” that can track what they’ve done, retry intelligently, and interface with external systems or LLMs.
Mark emphasized that these capabilities aren’t speculative. In fact, Diagrid—the company he co-founded—is already seeing adoption in production environments where reliability and auditability are critical.
Measuring Dapr’s Impact on Teams
Leo asked the practical question: where’s the proof that Dapr actually speeds up development?
Mark answered with numbers. In early experiments, companies building side-by-side projects—with and without Dapr—saw up to a 50% reduction in time-to-production and a 70% drop in bugs. A more recent survey reported by Diagrid showed 30–50% productivity improvements.
“You don’t want to rewrite common distributed systems patterns over and over. It’s like trying to implement your own linked list class—Dapr handles those patterns for you.”
Dapr also helps platform engineering teams by abstracting infrastructure choices. Developers can build against a consistent set of APIs, while platform teams can switch out components like message brokers without touching application code.
Looking Ahead: Will the Sidecar Survive?
With lightweight runtimes like WebAssembly and edge computing gaining traction, Leo challenged the longevity of the sidecar model. Mark was clear:
“Dapr’s sidecar is under 80 MB, adds virtually no latency, and runs on everything from Kubernetes to Raspberry Pis. For most applications, it’s perfectly reasonable—and it’s not going away.”
That includes disconnected edge environments. Mark gave examples of energy companies running Dapr in isolated Kubernetes clusters, collecting and transmitting data via satellite. Whether in the cloud or on the edge, the sidecar model holds up.
Even as agentic architectures rise and AI workflows become the norm, Mark believes the core patterns of distributed systems will remain the same. Dapr isn’t chasing trends—it’s codifying what developers already do into a set of stable, reusable building blocks.
Show Notes
- Follow Mark on X.
- Follow Mark on Linkedin.
- Regular posts and insights on Dapr and Diagrid.
- State of Dapr Report by CNCF that we discussed during the episode.
Podcast editing: Mila Jones, milajonesproduction@gmail.com