Ambassador post originally published on Medium by Dotan Horovits
Microservices have been with us for nearly two decades, but it’s still far from easy to develop at scale, in a polyglot environment. The Dapr project, the Distributed Application Runtime, is an open source graduated project under the Cloud Native Computing Foundation (CNCF), which comes to address this pain.
In my latest OpenObservability Talks episode I hosted Yaron Schneider, co-creator of Dapr (as well as of KEDA that will be covered in the next blog post), and co-founder and CTO of Diagrid, a lead backer company to Dapr, to hear all about the project.
The need that sparked Dapr
Building microservices is hard. Anyone who has worked with distributed systems knows the challenges: connecting services, tracing asynchronous events, handling failures, scaling dynamically, accessing caching and messaging and more. Before Dapr, developers had to implement these patterns manually . Take the example of tracing, pulling SDKs for OpenTelemetry, wiring trace propagation through Kafka headers, and coordinating requests across multiple services.
Even at Microsoft, where Yaron worked on Azure Container Apps, these issues were apparent at scale. Teams spent months and significant resources simply maintaining consistency across distributed workloads. Dapr was designed to address these inefficiencies — reducing what once took months to five minutes with a single developer.
Dapr provides an application runtime for building microservices on Kubernetes. An intelligent sidecar alongside your application takes care of the messaging, pub-sub, service-to-service communications, storage, caching, secrets mgmt and more, so your application doesn’t need to be bothered with anything other than the local sidecar.
The journey to open source
Dapr was open source from day one. This was not an afterthought; it was part of the design philosophy. Yaron emphasized how the company was very much DevOps focused, and Yaron’s team advocated for addressing the developer persona as well. This still served the DevOps goal:
“The biggest win wasn’t just that developers could write code faster — it was that a single DevOps engineer could standardize an entire workflow in minutes instead of months. That’s the power that drove us to make Dapr open source from day one.”
I saw a similar process within the CNCF itself. Initially the foundation was very much focused on DevOps. The Dapr project was one of the early signs of expanding to address developers as well, a trend that continued and went on to platform engineering, FinOps and other areas in today’s 10-year-old CNCF.
The decision to join the CNCF proved well, with big names such Alibaba and hashicorp joining Dapr early on. Dapr was established enough to skip the CNCF sandbox and was the first project to join the CNCF as an incubating project back in 2021. Seeing Dapr reaching graduation during the last KubeCon NA (October 2024), was a significant milestone for the project. The projects today has thousands of individual contributors from hundreds of organizations.
Observability built-in
One of Dapr’s most compelling features is built-in observability. Developers no longer need to instrument services manually to collect metrics or traces. Dapr automatically propagates context across asynchronous systems like Kafka or SQS and synchronous systems like HTTP.
“The trace is the only thing you need to know. You won’t even need SDKs in your code… Dapr will just show you the entire call graph.”
Developers can provision a single YAML file to send all traces to their backend of choice — OpenTelemetry-compatible systems like Jaeger, Zipkin, or AWS X-Ray. Metrics are similarly baked in. Connect Dapr to a database, and Prometheus can scrape the golden metrics (request rate, error rate, latency) without touching your code. This sidecar pattern, reminiscent of service meshes like Istio, is elegant and scalable.
Latest capabilities and roadmap
Dapr has continued evolving, and the latest innovations focus on workflows and AI/LLM integration. Workflows allow orchestrating distributed processes as if they were a single transaction, fully observable with OpenTelemetry. Dapr’s Conversation API abstracts multiple LLM providers — OpenAI, Anthropic, AWS Bedrock — while adding enterprise features like PII obfuscation.
Yaron also highlighted the recently-announced Dapr Agents, an agentic framework contributed by NVIDIA and maintained jointly with Diagrid, which adds durability and failure recovery to multi-step autonomous workflows. This ensures costly LLM calls are not wasted in case of failures, saving both money and infrastructure (because, let’s face it, the most precious resource these days are the LLM tokens).
A perfect companion to KEDA
Dapr frees developers from boilerplate complexity and makes building distributed applications feel almost magical. But Dapr alone is only part of the picture. Enter KEDA, the natural complement. Once Dapr enables event-driven workloads, KEDA handles dynamic autoscaling.
Importantly, Dapr and KEDA share the same ecosystem of integrations, making the combination seamless:
“When I basically designed both KEDA and Dapr, I wanted them to make sure that they overlap so that… you can immediately autoscale it with KEDA. You only need two YAML files.” — Yaron Schneider
For more on KEDA from Yaron, who co-created that project as well, check out my next post.