We are living in a world where every other day we see a new technical innovation. For most of us mere mortal it is not easy to quickly figure out if the technology is worth our time. Making sense of new technical innovations is one of the core aspects of my current role so by taking the pain of writing this series I will help myself as well.
In this post, I will cover Dapr. Dapr stands for distributed application runtime.
What does distributed application runtime means?
These days most of us are developing distributed systems. If you are building an application that uses Microservices architecture then you are building a distributed system.
A distributed system is a collection of autonomous computing elements that appears to its users as a single coherent system.
Distributed application runtime provides you the facilities that you can use to build distributed systems. These facilities include:
- State management. Most applications need to talk to a datastore to store state. Common examples like PostgreSQL, Redis, etc.
- Pub/sub. For communication between different components and services.
- Service to service communication. This also includes retries, circuit breaking.
- Observability. To bring visibility into systems.
- Secret management. For storing password and keys.
- Many other
One important thing to note is that these are application level concerns. Distributed application runtime does not concern itself with infrastructure or network level concerns.
What is Dapr?
Dapr is an open source project by Microsoft. The website describes it as an event-driven, portable runtime that makes it easy to build stateless and stateful Microservices based applications.
Dapr is an implementation of Distributed application runtime. Its main goal is to make it easy to build distributed applications by codifying all the best practices for building distributed applications into one runtime.
The above is the image I took from Dapr docs. The picture clearly tell where Dapr fits. It sits on top of infrastructure layer by providing capabilities like service-to-service invocation, state management, publish and subscribe, actors, secrets, etc. The best part is that it is extensible so you can write your own plugins. When Dapr was launched in 2019 it only had support for less than five databases.Today, it supports more than fifteen databases. You can refer to Dapr docs to see list of supported databases.
How it is different from Kubernetes?
It should be clear from the above picture that Dapr is an higher abstraction than Kubernetes. Kubernetes does not have any concept of application.
You can use Dapr as a sidecar container with your application containers running in Kubernetes. You can also use Dapr as a process for traditional deployments as well.
Can Dapr run outside containers?
I answered this in the previous question but let me reiterate. Dapr can run either in the self-hosted more or as a sidecar process in a Kubernetes pod.
The default installation of Dapr require Docker containers. When you install dapr using dapr init then runs few services like Redis and daprd. These are required to run dapr. So, to make it easy to run itself dapr uses Docker containers.
But you can run dapr in the self-hosted mode by running following command.
dapr init --slim
The above will not require Docker.
Isn’t Dapr a service mesh?
I am glad you asked. I also had a hard time understanding the difference between the two. The dapr docs writes following:
Dapr can be used alongside any service mesh such as Istio and Linkerd. A service mesh is a dedicated network infrastructure layer designed to connect services to one another and provide insightful telemetry. A service mesh doesn’t introduce new functionality to an application.
Dapr introduces new functionality to an app’s runtime. Both service meshes and Dapr run as side-car services to your application, one giving network features and the other distributed application capabilities.
Istio is not a programming model and does not focus on application level features such as state management, pub-sub, bindings etc. That is where Dapr comes in.
So, there are some similarities between the two. But, as suggested by the dapr documentation we can use them together as well. Dapr will not focus on network concerns like traffic routing, A/B testing etc. This is where service mesh like Istio will provide value. Dapr will be more application centric.
What’s my view on Dapr?
Personally I am not yet sold on Dapr. I don’t see it adding much value. I can get all this value from my framework. I understand the value of sidecar architecture approach but still it is not enough for me. I am using Kubernetes and Istio in my work and I don’t think Dapr will add much value in my setup. It looks interesting and it allows a development team to build their PaaS using Dapr. For now it is an interesting technology that I don’t see much business value.
Shekhar Gulati 