Dapr (Distributed Application Runtime) is a sidecar that exposes common distributed-systems primitives — service-to-service invocation, pub/sub, state stores, secrets, bindings, workflows, and virtual actors — as a local HTTP/gRPC API your application calls over localhost. Your code never imports a Kafka client or an S3 SDK; it POSTs to http://localhost:3500/v1.0/publish/mybroker/mytopic and Dapr routes the message to whatever broker the operator has configured.
The key idea is a separation between application code (which uses stable Dapr APIs) and “components” (pluggable implementations of those APIs). A state store component can be Redis in dev, CosmosDB in production, and PostgreSQL in a regulated environment, without touching code. Pub/sub can swap between Kafka, RabbitMQ, Azure Service Bus, NATS, or Pulsar the same way. Dapr ships with over 100 components. The actor building block implements Orleans-style virtual actors with automatic placement and turn-based concurrency; the workflow engine is built on top of actors and provides durable, code-first workflows.
On Kubernetes, Dapr runs as a sidecar injected by a mutating webhook, plus control-plane services for placement (actors), operator, sentry (mTLS between sidecars via an automatic CA), and scheduler. It can also run as a process on VMs or locally. Dapr was created by Microsoft, graduated in the CNCF in 2024, and is backed commercially by Diagrid. It competes conceptually with service meshes (Istio, Linkerd) and application frameworks (Spring Cloud, Micronaut), but operates at a higher level of abstraction: it cares about application semantics, not just network traffic.