Microsoft released Dapr in 2019, and by February 2021, it hit version 1.0. The project aims to simplify distributed application patterns using a sidecar model that hides cloud provider differences.
The sidecar model runs Dapr alongside your app. Your app talks to it via HTTP or gRPC on localhost. Dapr handles retries, pub/sub, state management, secrets, and tracing—all without polluting your code with distributed system logic.
Dapr components abstract infrastructure. For example, pub/sub might use Redis in dev and Azure Service Bus in production. You swap providers by changing config, not code.
For instance, I've seen teams use Dapr with RabbitMQ for pub/sub in development, then switch to Amazon SQS in production. This change is as simple as updating the component configuration, without modifying the application code. We've also used Dapr with Apache Kafka in on-prem environments, which required careful tuning of the Kafka cluster to achieve the desired throughput. In one case, we needed to handle 10,000 messages per second, which required adjusting the number of Kafka partitions and the batch size for the Dapr pub/sub component.
Calling services by name instead of host:port is a significant improvement. Dapr handles DNS, mTLS, and load balancing. In Kubernetes, it uses the service registry. From your app’s perspective, it’s a localhost call, but Dapr adds resilience.
In a recent project, we used Dapr to call a service that was deployed across multiple Availability Zones in Azure. Dapr automatically handled the load balancing and failover, ensuring that our application remained available even when one of the zones went down. We also used Dapr's built-in support for circuit breakers to detect and prevent cascading failures. By configuring Dapr to detect when a service was not responding, we could prevent our application from retrying failed requests and reduce the overall latency.
Dapr’s state API gives you a key-value store. Backends include Redis, Cosmos DB, or PostgreSQL. It supports ETags for concurrency and lets you choose consistency levels. Stateful microservices can store session data without knowing the backend.
The choice of backend for the state API depends on the specific requirements of your application. For example, if you need strong consistency and high availability, you may choose to use Cosmos DB. On the other hand, if you need low latency and high throughput, you may choose to use Redis. We've used Dapr with Redis in several applications, and have been able to achieve latency as low as 1-2 milliseconds for read and write operations. However, this required careful tuning of the Redis cluster and the Dapr state component, including adjusting the connection pool size and the timeout values.
The secret management component fetches credentials from HashiCorp Vault, Azure Key Vault, or AWS Secrets Manager. Your app reads secrets through a uniform API, avoiding hardcoded values.
Observability is baked in. Dapr integrates with OpenTelemetry for distributed tracing. You get end-to-end traces across services without instrumenting each one.
Development to production parity is easier. You can test against mocked components locally, then switch to real ones in staging. No rewrite needed when deploying to production.
Dapr’s design prioritizes portability. A service built with Dapr’s pub/sub API works unchanged whether it’s using Kafka on-prem or SNS/SQS in AWS.
The v1.0 release stabilized core features like state management, service invocation, and secrets. Microsoft continues adding components like configuration management and resource binding.