Distributed Application Runtime- Dapr

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

Last year, Microsoft announced a new approach to develop modern applications based on Dapr. 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 website describes it as an event-driven, portable runtime that makes it easy to build stateless and stateful microservices based applications. Initially, one contemplates Dapr as just another service mesh. Dapr operates as a sidecar, but provides a totally different functionality than a service mesh. Dapr is focused on providing building blocks that make it easier for developers to build microservices, unlike a service mesh, which is focused on networking concerns.

HOW DAPR WORKS

Communication between multiple microservices commands the use of gRPC (general-purpose Remote Procedure Calls), API (Application Programming Interface), pub/sub (publish-subscribe pattern), etc. Moreover, developers have to do Service Discovery as well as State Management. These two instances involve several parameters. Depending on whether it’s a stateless or stateful app, developers have to work with different SDKs (Software Development Kit) and programming models.

Dapr uses a sidecar pattern which is similar to side-car implementation in service mesh architecture, where a local proxy is used to route requests. Side-cars in Dapr are used to enable integration of microservice building blocks at runtime versus at compile time. This brings-in the advantage of having Dapr integrated with existing and legacy code operated through a standard HTTP (Hyper Text Transfer protocol)/gRPC interface, which enables enterprise developers to experience the benefits of microservices development without having to re-write their applications.

How it is different from Kubernetes?

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.ie Dapr can run either in the self-hosted more or as a sidecar process in a Kubernetes pod.

Dapr Vs Service Mesh

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.

DEVELOPER LANGUAGE SDKS AND FRAMEWORKS

Dapr can be integrated with any developer framework. For example, in the Dapr .NET SDK you can find ASP.NET Core integration, which brings stateful routing controllers that respond to pub/sub events from other services. And, in the Dapr Java SDK you can find Spring Boot integration.

DEVELOPER FRAMEWORKS
Dapr can be integrated with any developer framework. For example, in the Dapr .NET SDK you can find ASP.NET Core integration, which brings stateful routing controllers that respond to pub/sub events from other services. And, in the Dapr Java SDK you can find Spring Boot integration.

COMPONENTS
Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. All of the components are pluggable so that you can swap out one component with the same interface for another. You can get a list of current components available in the current hosting environment using the dapr components CLI command.

MIDDLEWARE COMPONENTS

Dapr allows custom middleware to be plugged into the request processing pipeline. Middleware can perform additional actions on a request, like authentication, encryption and message transformation before the request is routed to the user code, or before the request is returned to the client. The middleware components are used with the Service Invocation building block.

CONCLUSION

Dapr offers best practices for common capabilities when building microservice applications that developers can use in a standard way and deploy to any environment. Dapr brings around some of the demonstrated techniques and best practices to microservice development. In fact, Dapr does what ODBC (Open Database Connectivity) and JDBC (Java Database Connectivity) did to data-driven client/server applications for consuming common services required by modern, cloud-native applications. TypeScript, C#, Scala, Ruby, and Rust are also slated for SDK development in the near future.