Spent the better part of two decades building distributed systems, and the recurring theme never changes: everyone reinvents the same infrastructure plumbing. State management, pub/sub messaging, service discovery, secret stores — every team builds their own version, usually poorly, and then maintains it forever.

Dapr ranks as the most compelling attempt I’ve seen to fix that problem at the application layer.

What Dapr actually does #

For those unfamiliar: Dapr (Distributed Application Runtime) offers a set of building-block APIs that abstract away common distributed systems concerns. You get a consistent interface for state management, publish/subscribe, service-to-service invocation, input/output bindings, and more — all without coupling your code to specific infrastructure.

The trick lies in the sidecar architecture. Dapr runs as a sidecar process alongside your application, exposing its APIs over HTTP and gRPC. Your code calls localhost:3500/v1.0/state/mystore to save state. Dapr handles the rest — whether that state store is Redis, PostgreSQL, Azure Cosmos DB, or something else. Swap the component config; your application code doesn’t change.

This matters more than it sounds. I landed on teams where migrating from one message broker to another took months because the broker’s client SDK was embedded in every service. With Dapr, that migration becomes a config change — no service code to touch, no coordinated deploys.

The sidecar bet #

The sidecar pattern isn’t new — Istio and Envoy popularized it for service mesh use cases. But Dapr’s angle differs in a way that often gets overlooked.

Service meshes operate at the network layer. They handle mTLS, traffic routing, retries. They don’t know or care about your application’s semantics. Dapr operates at the application layer, aware that you’re saving state, publishing an event, invoking another service. That higher-level abstraction creates room for features a network proxy can’t offer: actor frameworks, workflow orchestration, distributed locking.

The two complement each other rather than compete. You can run Dapr with Istio; the mesh handles network-level concerns while Dapr handles application-level building blocks. In practice, some organizations run Dapr instead of a full service mesh for simpler deployments — a valid tradeoff, though not one I’d make without benchmarking the overhead.

Language-agnostic by default #

One of Dapr’s strongest selling points: genuine language agnosticism. Because everything runs through HTTP/gRPC to the sidecar, any language that makes HTTP calls works with Dapr. SDK wrappers exist for Go, Java, Python, .NET, JavaScript, and Rust — but they’re optional convenience layers, not requirements.

At DreamFlare we run a polyglot stack (TypeScript, Python, some Go), and consistent state management and messaging across all of them without per-language library choices sounds genuinely appealing. No Dapr in production yet, but it’s on our evaluation list for 2024.

CNCF incubation and the road to maturity #

Dapr joined the CNCF as an incubating project in November 2021. For those not familiar with the CNCF lifecycle: projects move through sandbox (early, experimental), incubating (growing adoption, active governance), and graduated (production-proven, audited, broadly adopted).

The incubating stage carries real meaning. It signals actual governance, multiple maintainers, growing adoption, and commitment to open-source best practices. Kubernetes, Prometheus, and Envoy all passed through this same pipeline before graduation.

Graduation requires demonstrating significant production adoption across multiple organizations, passing a third-party security audit, achieving a clean bill on open-source governance, and showing that the project would survive the departure of any single contributor or company. A high bar — and the bar should sit exactly there.

Dapr’s trajectory toward graduation looks encouraging, given what surrounds the project. Diagrid (founded by the original Dapr creators from Microsoft) builds commercial offerings on top of Dapr, which provides the kind of financial sustainability that CNCF looks for. Alibaba, Intel, and several other companies have contributed to the project. The community stays active, the release cadence holds steady, and the scope stays well-defined.

Why I’m watching this closely #

Three things make Dapr interesting to me as a CTO:

Reduced onboarding friction. When a new engineer joins and needs to understand our messaging patterns, I’d rather point them at Dapr’s pub/sub API documentation than our custom Kafka wrapper. Standardized building blocks mean standardized knowledge.

Infrastructure mobility. We’re a startup. Our infrastructure choices might change as we scale. Having an abstraction layer between application code and infrastructure services makes those transitions less painful. Not free — but less painful.

Workflow primitives. Dapr’s workflow API arrived relatively recently, but the idea of having durable workflow execution as a building block (rather than bolting on something like Temporal or Step Functions) attracts me for certain use cases. The workflow engine runs in the sidecar, which means no additional infrastructure to manage.

The honest caveats #

Dapr comes with real tradeoffs. The sidecar adds latency (small, but non-zero) and operational complexity (every pod now runs two containers). Debugging distributed transactions through a sidecar proxy adds a layer of indirection that frustrates even experienced operators. And the abstraction leaks; not every state store or message broker supports every feature in Dapr’s API surface.

There’s also the adoption chicken-and-egg problem. Dapr’s value grows with the breadth of components you use, but most teams start with one or two. With only the pub/sub API, you’ll question whether the sidecar overhead justifies skipping your broker’s client library entirely.

My take: Dapr’s value proposition works best for organizations running Kubernetes-native workloads, using multiple infrastructure backends, or building polyglot services. If you run a monolith on a single cloud provider with one language, the complexity probably doesn’t pay off.

What CNCF graduation would signal #

When Dapr graduates from CNCF, the milestone marks something larger than one project’s maturity. It validates the idea that application-level building blocks — not just network-level primitives — belong in the cloud-native stack. That the sidecar pattern extends beyond service mesh into genuine application runtime capabilities.

That validation seems inevitable. The project has the technical merit, the community, and the commercial backing. Whether graduation lands in 2024 or later, Dapr’s approach to distributed systems abstraction stays on my radar — and probably earns a bet.