Dapr Graduates CNCF and What It Means for Distributed Application Building Blocks

In this article

• What Dapr Is
• The Architectural Premise
• Where Dapr Earns Its Place
• Where Dapr Does Not Pay Off
• Dapr on Azure
• The Honest Trade-off
• Where This Leaves Architects

In short: Dapr graduated from CNCF in November 2024 after five years in incubation. The building-block model (state, pub/sub, service invocation, secrets, bindings, actors, workflow) is now a credible, low-risk choice for distributed applications. The architectural question for Azure-first teams has shifted from “should we use Dapr” to which workloads benefit from the sidecar abstraction, which Azure runtime hosts it best, and where direct SDK calls are still the better answer.

The Cloud Native Computing Foundation graduated Dapr (Distributed Application Runtime) in November 2024, the final tier in the CNCF maturity model. Graduation requires production adoption at scale, a multi-vendor maintainer base, a passed security audit, and a stable governance model. Reaching the bar matters because architects can now treat Dapr the way they treat Kubernetes, Prometheus, or Envoy: a graduated CNCF project with a credible long-term trajectory and a defensible position at a board-level architecture review.

Microsoft open-sourced Dapr in October 2019. Version 1.0 went GA in February 2021. CNCF incubation followed in November 2021. The five-year arc from sandbox to graduation tracks roughly with Helm, Envoy, and Linkerd, which is the company Dapr now keeps in the CNCF catalogue.

What Dapr Is

Dapr provides a set of building-block APIs for distributed applications. The current set covers state management, publish/subscribe messaging, service invocation, secrets, bindings, actors, workflow, configuration, distributed lock, cryptography, and a conversation API for LLM access added during 2024. Each building block has a portable API your application calls and a pluggable component implementation behind it that talks to the actual backing service: Redis or Cosmos DB for state, Service Bus or Kafka for pub/sub, Key Vault or HashiCorp Vault for secrets, and so on.

The architecture is sidecar-based. Each application instance runs alongside a Dapr sidecar (a small Go binary called daprd) that exposes HTTP and gRPC interfaces on localhost. The application talks to the sidecar; the sidecar talks to the backing service using the component configuration provided by the platform operator. The control plane (placement service, operator, sentry for mTLS) runs once per cluster or environment and manages identity, certificates, and actor placement.

The Architectural Premise

The Dapr premise is that distributed-systems concerns should be abstracted at the capability level. Most cloud SDKs abstract the wire protocol: the Azure SDK gives you an idiomatic interface to Cosmos DB, but the application code is bound to Cosmos. Dapr abstracts one layer up.

Consider state management. With a cloud SDK, switching from Cosmos to Redis means rewriting the data-access layer. With Dapr, the application calls state.save("orders", key, value) against the local sidecar. A YAML component file tells the sidecar to back that API with Cosmos in production, Redis in development, or any of the thirty-plus supported state stores. The application code stays unchanged.

The same pattern repeats for pub/sub (Service Bus, Event Hubs, Kafka, RabbitMQ, Redis Streams, SNS/SQS), secrets (Key Vault, Vault, AWS Secrets Manager, GCP Secret Manager), bindings (Storage, Cosmos, HTTP, MQTT, IoT Hub), and the rest of the building blocks.

The cost is real. Every call from your application to a backing service hops through localhost to the sidecar and out again, adding a few milliseconds of latency and a sidecar container per pod or app. Configuration moves from application code into component files that the platform operator manages. Debugging gains an additional layer: a failed state write could be an issue in the application, the sidecar, the component, the backing service, or the network between any of them.

Where Dapr Earns Its Place

Dapr pays off when the application benefits from the building-block abstraction and the team has the operational appetite to run another component in production.

Teams running thirty microservices that all do some combination of state, pub/sub, and service invocation are a natural fit. Standardising on the Dapr APIs stops every team from reinventing its own wrapper layer. New services start from the same shape, new engineers learn one set of patterns, and the abstraction surface stays small enough to reason about.

Multi-environment consistency is another. Development on a laptop using Redis for state and RabbitMQ for pub/sub, staging on Container Apps with Cosmos DB and Service Bus, production on AKS with the same backing services: application code does not change between any of those environments because all three resolve the same Dapr API calls to the appropriate components.

Dapr Workflow is the building block most architects underrate. It provides durable execution semantics (write a workflow once, get retries, replay, and state persistence) without committing to a separate workflow engine. For long-running orchestrations that previously required Temporal, Azure Durable Functions, or a hand-rolled state machine, Dapr Workflow is a cleaner option once Dapr is already deployed.

Multi-cloud portability is the marketing pitch and rarely the decisive reason a team adopts Dapr. Components abstract the wire interface, but operational concerns (provisioning, networking, IAM, observability) remain cloud-specific. Treat portability as a useful by-product. The headline argument for adopting Dapr is the building-block consistency and the workflow primitives.

Where Dapr Does Not Pay Off

Single-cloud teams already committed to provider-native SDKs gain little. If the application calls Cosmos DB and Service Bus directly through Azure SDKs and the team is comfortable with that model, adding Dapr means a new abstraction layer, additional configuration, and a sidecar container per workload, for a portability story the team has no plan to exercise.

Latency-critical paths suffer from the sidecar hop. A request that needs sub-millisecond access to a local cache should call the cache directly. The hop itself is typically under a millisecond, but at high request volumes the cumulative cost is measurable, and the hop introduces a failure mode the application would otherwise avoid.

Teams without the appetite to operate one more component will find Dapr more friction than benefit. Production Dapr means running the control plane, monitoring sidecar health per pod, configuring components correctly across environments, and debugging the additional layer when something breaks. Container Apps absorbs most of that operational weight for you. On AKS, the team owns it.

Dapr on Azure

Azure offers two integration points and they differ significantly in operational weight.

Container Apps integrates Dapr at the environment level. The platform runs the Dapr control plane, injects sidecars when an app declares dapr.enabled: true, and exposes components as Azure resources operators can author through Bicep, Terraform, or the portal. The result is a managed Dapr experience: deploy an app with one configuration flag, attach a component, and the building-block API is available. No Helm chart to maintain, no control-plane operations, no sidecar lifecycle to manage. For most Azure-first teams, this is the easiest production on-ramp for Dapr today.

AKS runs Dapr as an installed component, typically via the official Helm chart or the Dapr operator. The team owns the control plane (one to three replicas of each component depending on scale), version upgrades, mTLS certificate rotation through Sentry, and integration with cluster networking and observability. The reward is full control over Dapr configuration, the ability to develop custom components, and access to Dapr capabilities not yet exposed in the Container Apps integration. For platform teams already operating AKS at scale, the marginal cost of also operating Dapr is small.

Container Apps Express does not yet support Dapr. Workloads that need it stay on a standard Container Apps environment until that gap closes. The decision boundary between Express and standard ACA tracks closely with whether the workload needs any of the integrated building blocks.

The placement decision between Container Apps and AKS for Dapr workloads follows the broader Container Apps vs AKS framework. If the team would have picked Container Apps without Dapr, adding Dapr does not change the answer. If the team would have picked AKS for other reasons (Kubernetes API surface, custom operators, specific networking patterns), Dapr installs cleanly on top.

The Honest Trade-off

Dapr’s strongest argument is the developer experience. A consistent set of APIs across state, pub/sub, secrets, and workflow means new services start from the same shape and the abstraction surface stays small enough to reason about. Combined with Dapr Workflow for durable execution, the package is useful for teams building distributed applications without committing to a single proprietary platform stack.

The cost is the sidecar tax, the configuration surface, and the additional debugging layer. For the workloads that benefit from the building-block model, these costs are manageable. For workloads that do not benefit, the same costs read as pure overhead.

The CNCF graduation does not change the architectural decision. It changes the risk profile. Adopting a graduated project carries a different procurement and governance burden than adopting an incubating project. The November 2024 milestone moves Dapr into the same long-term-bet category as Kubernetes, Prometheus, and Envoy, which is the category most enterprise architecture review boards can sign off on without a separate justification document.

Where This Leaves Architects

Pick Dapr when the building-block model matches how the team already thinks about distributed services and when state, pub/sub, secrets, and workflow are recurring concerns across multiple workloads. For Azure-first teams, Container Apps with Dapr enabled gives the cleanest operational profile. Reach for AKS with self-managed Dapr when the team already operates Kubernetes as a platform product and wants control over the Dapr configuration surface.

Skip Dapr when one cloud is the firm commitment, the team prefers native SDKs, and no service in the portfolio benefits from the durable workflow or pluggable secrets story. The sidecar tax is real and the developer-experience benefit only lands if the team uses the abstraction across enough services to amortise the operational cost.

The most common Azure-first answer is mixed: Container Apps with Dapr for the production microservices that fit the building-block model, native SDKs for everything else, and a stated boundary in the architecture documentation so the team does not end up running both patterns side by side without a reason.

If your team is evaluating Dapr for an Azure-first portfolio, we help architecture teams identify which services benefit from the building-block model, decide between Container Apps and AKS placement, and define a clear boundary against native SDK use. Get in touch about a Dapr placement review.

Related: Azure Container Apps vs AKS Decision Framework the broader platform decision Dapr sits on top of · Container Apps Express in 2026 the new ACA tier that does not yet support Dapr · AKS in 2026 and When It Still Wins the cluster-ownership end of the spectrum where self-managed Dapr lives · Azure AI Enterprise Architecture in 2026 the AI integration layer where the Dapr conversation building block is relevant.