DAPR – Distributed Application Runtime

Distributed Application Runtime for the Development of Resilient Microservices 

Developers used to spend a lot of time maintaining the environment and infrastructure rather than building code that addressed business objectives. In any normal project situation, it is required to handle the configuration of platforms and infrastructure before starting coding. It seems complicated to postpone certain choices since the libraries and frameworks necessary for each platform influence how code is organized and developed.  

For example, switching to Kafka would damage the project’s timeliness once you have created the interfaces to interact with Rabbit MQ. This issue becomes much more acute when we have many microservices and wish to modify the underlying platform protocol. This is where Dapr comes in to solve the platform challenge from the business codebase.  

Dapr is a free and open-source runtime system aiming to accelerate cloud-native and serverless computing development. It is designed to be deployed as a sidecar to the central business microservices and is intended to be a technical helper sidecar. Following the sidecar paradigm, it attaches to the business logic runtime and assumes responsibility for doing the additional technical job on your behalf. These may include providing pub/sub behavior, implementing distributed caching, managing the application’s secrets, service discovery, application health monitoring, telemetry logging, etc.

Dapr codifies best practices for constructing microservice applications into open, agnostic building blocks that allow you to design portable apps in your preferred language and framework. Each construction piece is segregated and detached, allowing the developer to utilize one, some, or all in the program. 

Each computing unit receives a sidecar (container or process) from Dapr. The sidecar interfaces with the main microservice runtime using standard HTTP or gRPC protocols and interacts with event triggers. Because its communication is over HTTP or gRPC, Dapr may expand, be upgradable, and be easily accessible for any language of choice due to the separation of the runtimes via standard protocols. 

Features of DAPR: 

• Event-driven Pub-Sub system with pluggable providers and at-least-once semantics.  
• Input and output bindings with pluggable providers. 

• State management with pluggable data stores. 
• Consistent service-to-service discovery and invocation. 
• Opt-in stateful models: Strong/Eventual consistency, First write/Last-write wins. 
• Cross-platform virtual actors. 
• Secrets management to retrieve secrets from secure vaults. 

• Rate limiting. 
• Built-in Observability support. 
• It runs natively on Kubernetes using a dedicated Operator and CRDs. 
• Supports all programming languages via HTTP and gRPC. 
• It runs anywhere, as a process or containerized. 

• It runs as a sidecar – removes the need for unique SDKs or libraries. Dedicated CLI – developer-friendly experience with easy debugging. 
• Clients for Java, .NET Core, Go, JavaScript, Python, Rust, and C++.  

 
It is challenging to create high-performance, scalable, and trustworthy distributed applications. Dapr assists by bringing established patterns and practices to the table, supporting all programming languages without requiring framework lock-in. Business logic developers are not exposed to low-level primitives such as threading, concurrency management, partitioning, and scalability. 

One of the custom use cases we implemented using Dapr is to create a util error handling helper sidecar. Dapr is used to offer gRPC and HTTP communication functionality for this sidecar. It may be deployed to any significant business microservice runtime and will respond to any request to manage application issues. 

Communication with the Dapr-based sidecar is done using the gRPC protocol, which uses the protobuf format; however, HTTP may alternatively be utilized. The business logic will be unaffected if anything goes wrong with the sidecar.