DAPR: future of cloud-native & microservices
In this article I am going to explain about what is DAPR, and how it works?
If you want to learn/understand how a dotnet developer can create/deploy cloud native distributed application(s) rapidly with DAPR, please check this article where I have explained step by step process of how to use DAPR with sample code.
Unless you have been living under a rock, You must have heard of Cloud, and if you are a developer, you must have heard of Microservices. As the overgrowing demands of Distributed Systems, there is an exponential rise to tackle the underlying complexities. And with the rise of multiple clouds and hybrid setups, these complexities like resilient service invocation, distributed transactions, on-demand scaling, resiliency, maintainability, elasticity are also growing in multifold. This has given rise to Cloud-Native Apps. Now Cloud-Native comes with it’s own set of sophistications and developers has to learn different languages, technologies, frameworks, dev-ops etc. All in all developers has to be a one man avenger team.
Here comes the rescue: DAPR. Distributed Application Runtime, a new way to build modern distributed applications. As per the definition,
DAPR is a portable, serverless, event-driven runtime that makes it easy for developers to build resilient, stateless and stateful microservices that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
DAPR codifies the best practices for building microservice applications into open, independent, building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is independent and you can use one, some, or all of them in your application.
How DAPR works?
- Building Blocks for Developers
For any developer to build an application, few building blocks are needed like:
- Service Invocation: Invoke direct, secure service-to-service calls using platform agnostic protocols and well-known endpoints. Click here to know in detail.
- State Management: Support contextual information for long running stateful services. Click here to know in detail.
- Publish & Subscribe: Implement secure, scalable pub/sub messaging between services. Click here to know in detail.
- Bindings: Trigger code from events raised by external resources with bi-directional communication. Click here to know in detail.
- Observability: Monitor and measure message calls across networked services. Click here to know in detail.
- Secrets: Securely access external secret stores. Click here to know in detail.
- Actors: Encapsulate logic and data in reusable actor objects. Click here to know in detail.
All of this can be done in a lot of different ways and as a developer we spend a lot of time to write code to achieve these functionalities but all in different ways. What DAPR does is to codifies the best practices, encapsulates and runs it as a sidecar along with the application.
- Any Language, Anywhere
DAPR is language agnostic and can run on any hosting environment including local development machines, Kubernetes, and public clouds. You can use SDKs based on your language preference. If not able to find sdk of your preferred language, you can make use of simple HTTP or gRPC calls. It is a s simple as that.
- Pluggable Components
DAPR provides pluggable components which simplifies the binding of application with infrastructure. It has a concept of component(Dapr component configuration yaml file). For example if you have a use case to store state/data of application, you can write a code targeting redis or may be mongoDB. Now because of cloud adoption you need to use cosmosDB or DynamoDB then again you need to write code specific to it.
With the help of DAPR, developer(s) can write application code(CRUD) for state-store. Then based on infrastructure, just by changing component configuration the same application code can work for redis, mongodb, cosmosdb or dynamodb. That’s the beauty of DAPR.
- Sidecar Architecture
The sidecar pattern is a single-node pattern made up of two containers. The first is the application container. It contains the core logic for the application. The second container in the pod augments and improves the application container and is called sidecar container.
DAPR uses this sidecar pattern to expose its building blocks and components. This way all the plumbing part and it’s logic is isolated and encapsulated in one container and the application container can focus on only the important part- business logic.
- DAPR performance considerations
As you got to know that DAPR works as sidecar, you can see in the below diagram that any call between 2 services has to go through extra network call. You must be thinking that what about latency and overhead incurred for each call. Doesn't it going to make the performance slow?
The answer to the above question is that DAPR team has spent tremendous amount of engineering effort to make it very very efficient. DAPR uses gRPC (which delivers high performance and small binary payloads and is super super fast) for calls between DAPR sidecars. So the additional overhead are in sub-millisecond. To improve the performance, developers can call the Dapr building blocks(which are in sidecar) with gRPC. If you want to learn more about gRPC, please check my articles in which I have explained it in detail.
- Dapr and service meshes
Service Meshes are another evolving technology for distributed applications. service mesh is a configurable infrastructure layer with built-in capabilities to handle service-to-service communication, resiliency, load balancing, and telemetry capture. It moves the responsibility for these concerns out of the services and into the service mesh layer using sidecar architecture.
So you must be thinking now that is DAPR another service mesh? The answer is no. Both uses same architecture but serves different purpose. Service Mesh provides networking communication between services and DAPR provides application services such as state management, binding, pub-sub or actor services. On a high level Service mesh helps mostly infrastructure team(s). But DAPR can help both the application developer team(s) and infrastructure team(s) also.
Both can be utilized in conjunction to improve the overall performance and tackle the inherent complexities of Distributed applications. There are some capabilities which can be achieved by both DAPR and service mesh. When both are deployed together, choose either of the common capabilities like mTLS or tracing.
- If you want to learn/understand how a dotnet developer can create/deploy cloud native distributed application with DAPR, please check this article where I have explained step by step process of how to use DAPR with sample code.
- For further reading you can go to https://docs.dapr.io/concepts/.
- If you are a dotnet developer you can make use of https://docs.microsoft.com/en-us/dotnet/architecture/dapr-for-net-developers/ to understand DAPR with sample code.
