Dapr — Distributed Application Runtime for Cloud and Edge

Introduction

Dapr (Distributed Application Runtime) is a CNCF graduated project that codifies the best practices for building microservice applications into open, independent building blocks. It runs as a sidecar alongside your application so you can call APIs for state, pub/sub, bindings, and actors without reinventing distributed-systems plumbing for every service.

What Dapr Does

• Provides language-agnostic HTTP/gRPC APIs for service invocation, state management and pub/sub
• Abstracts over dozens of backends (Redis, Kafka, NATS, S3, Postgres, Azure, AWS, GCP)
• Runs as a sidecar so you can bring any language or framework
• Offers virtual actors, workflows and secrets management out of the box
• Integrates with Kubernetes via an operator plus self-hosted mode on a laptop

Architecture Overview

Each application instance is paired with a Dapr sidecar (daprd) that exposes the building-block APIs over localhost. The sidecar talks to pluggable components defined by YAML (a Redis state store, a Kafka broker, a Vault secret store) and enforces policies like mTLS, retries and access control. On Kubernetes the Dapr control plane (operator, placement, sentry, sidecar-injector) coordinates sidecar injection, actor placement and certificate issuance.

Self-Hosting & Configuration

• dapr init installs the runtime, placement service and bundled Redis/Zipkin locally
• Components are declared in YAML under ~/.dapr/components or a ConfigMap on K8s
• dapr init -k deploys the control plane with Helm into the dapr-system namespace
• Configuration CRDs control tracing, metrics, mTLS and middleware pipelines
• Use the dapr annotations on Pods to enable sidecar injection automatically

Key Features

• Building blocks: state, pub/sub, bindings, service invocation, actors, workflows, secrets
• Observability: OpenTelemetry traces, Prometheus metrics and structured logs for every call
• Security: automatic mTLS between sidecars, component-scoped access control, secret-store references
• Resiliency policies: retries, timeouts, circuit breakers declared in YAML
• Workflows authored in code (Go, Python, .NET, Java, JS) backed by durable actors

Comparison with Similar Tools

• Istio / Linkerd — service meshes focused on L7 traffic; Dapr adds app-level APIs (state, pub/sub)
• Spring Cloud — Java-only; Dapr is language-agnostic and deploys as a sidecar
• Temporal — specialised workflow engine; Dapr workflows are lighter weight but less feature-rich
• Knative Eventing — Kubernetes eventing only; Dapr spans self-hosted and edge too
• NATS / Kafka direct — Dapr pub/sub hides broker details so you can swap implementations

FAQ

Q: Is Dapr a service mesh? A: No. Dapr focuses on application-level concerns (state, pub/sub, bindings) and complements meshes that focus on L4/L7 routing.

Q: What languages are supported? A: Anything that can speak HTTP or gRPC. First-party SDKs exist for Go, Python, .NET, Java, JavaScript, PHP and Rust.

Q: Can I run Dapr without Kubernetes? A: Yes. dapr init enables a self-hosted mode that is perfect for local development, edge devices or VMs.

Q: How does Dapr handle secrets? A: Components reference a configured secret store (Vault, AWS Secrets Manager, Kubernetes Secrets) so you never embed credentials in YAML.

Sources

• https://github.com/dapr/dapr
• https://docs.dapr.io