Over the last decade there has been a huge shift away from heavily coded monolithic applications to finer, self-contained microservices. – short for Distributed Application Runtime – is a new, open source project by Microsoft that provides an event-driven runtime to support the essential features you need to build microservices, including Dapr service invocation state management, and publish/subscribe messaging. It offers platform-agnostic features for running your applications on public cloud, on-premises, and even on edge devices. Here we outline the core concepts of Dapr’s architecture, to help you understand what it is and why it’s such an exciting technology. Architectural overview Event-driven processes play an important role in microservices, as applications can be designed to react efficiently to events from external systems or other parts of the solution. Those applications can also produce events, to inform other services of new facts or to continue processing elsewhere or at a later stage. Microservices offer a vast array of benefits, but these are balanced by increased complexities in team and product management. Usually a significant burden is placed on the developer and the team in order to get started. What if you could leverage a runtime to help you get through the common patterns you will likely need to adopt and ease your operations? With Dapr you can! Still in development, Dapr builds on the experience gained by Microsoft of developing hyper-scale cloud-native applications. It has been inspired by the design of Orleans and Service Fabric, which in turn enable many Microsoft Azure cloud services to operate resiliently and at large scale. 1 shows Dapr’s architectural building blocks: Figure Figure 1 – Dapr architecture Dapr is portable: it can run locally on your dev machine in self-hosted mode, it can be deployed to the edge, and it can run on Kubernetes. Moreover, portability extends beyond the hosting environment, for while Dapr is an initiative started by Microsoft, it can also run on Kubernetes on-premise or in the cloud: Microsoft Azure, Amazon AWS, Google GCP, or any other cloud vendor. Fig 2 - Dapr sidecar As shown in Figure 2, the Dapr runtime operates in sidecar processes, lifting most of the complexity from the application to a separate environment and greatly simplifying development and operations. These sidecar processes are run locally in your development environment or as containers in a pod on Kubernetes. From the application perspective, Dapr is an API which can be directly reached via HTTP or gRPC calls or, even simpler, via any of the SDKs available. At the time of writing, these are .NET Core, Java, Go, Python, C++, Javascript, and Rust. It is not necessary to adopt the Dapr SDK in your application: a call to a Dapr service can be as simple as an http call to an endpoint such as http://localhost:3500/v1.0/invoke/<app-id>/method/<method-name>. Nevertheless, using the SDK provides many benefits if you are writing a Dapr Service or leveraging the Dapr Actor model. What Dapr is not To appreciate what Dapr is, it can be helpful to think about what Dapr is not. Dapr’s goal is not to force the developer to embrace a programming model with strict rules and constraints. On the contrary, while the application developer is freed by Dapr of the many complexities of a microservice architecture, the developer is not mandated on how to write the application. Dapr is not a service mesh. While many similarities can be found in the general objectives of Dapr and service meshes, Dapr provides these benefits at the application level while service mesh operates on the infrastructure. For instance, Dapr applies a retry logic in its interaction with state stores and services, but it is the developer’s responsibility to decide how to handle the error Dapr might return in case there is a conflict or an intermittent issue. (Dapr is meant to be integrated with service meshes such as Istio.) Dapr is not a Microsoft cloud service: it does help the developer build microservice applications in the cloud, it surely provides many integrations with Azure cloud services, but it also has as many components for AWS, GCP and other services. Note Dapr provides the same benefits to Python (for example) developers as it does to .NET Core developers, providing SDKs for Dapr and Dapr Actor, working on MacOS and with Kubernetes as the deployment target. Dapr building blocks Dapr has been designed from the ground up as a set of pluggable building blocks: developers can create an application counting on the support of many facilities while the operators can adapt the applications to the hosting environment by simply intervening in the configuration. The following is a complete list of the tools and components of Dapr: I: Cross-platform command line tool to configure, manage and monitor the Dapr environment. It is also the tool to locally debug Dapr applications. : The API which defines how an application can interact with the Dapr runtime in order to leverage its building blocks. : This is the core of Dapr, which implements the API. If you are curious you can take a look at how it is developed in Go at Dapr’s repository . : On your development machine the host runs as a standalone process; in Kubernetes it is a sidecar container in your application’s pod. : Specific to Kubernetes mode, the operator manages bindings and configurations. : Once instructed via configuration in Kubernetes mode, it takes care of injecting the Dapr sidecar into your application pod. : This service has the objective to distribute (or to place) the Actor instances across the Dapr pods. : A built-in certificate authority to issue and manage certificates used by Dapr to provide transparent mTLS. Dapr provides several building blocks which microservice application developers can adopt selectively, based on their need. : Service-to-service invocation enables your code to call other services located in the same hosting environment, while taking care of the retry policy. : This is to efficiently manage the application state as a simple key/value pair, relieving your stateful or stateless services from the need to support different backends. Dapr provides many state stores which include Redis, Azure CosmosDB, Azure SQL Server, PostgreSQL which can be plugged via configuration. : The publish/subscribe pattern enables decoupled communication between microservices by exchanging messages, counting on the presence of a service bus which can route messages between producers and consumers. : This is where the event-driven nature of Dapr shines: with bindings your application can be triggered by an SMS sent via Twilio (just to name a popular service in this area). : The actor pattern aims to simplify highly concurrent scenarios by splitting the overall requests load towards a large number of computation units (the actors) which take care of the job in their smaller but independent scope, by processing requests to a single actor one at a time. Here Dapr provides great benefits. : Dapr enables the developer and operator to observe the behavior of the systems services and applications without having to instrument them. : It is a common requirement and a healthy practice to keep secrets at safe distance from the code, if only to prevent unintended access in a development environment to the connection string intended for the production environment. Dapr enables you to store secrets, and to reference these from other Dapr components, in Kubernetes or Azure KeyVault, among many options. Dapr CL Dapr API Dapr runtime https://github.com/dapr/dapr Dapr host Dapr operator Dapr sidecar injector Dapr placement service Dapr Sentry Service Invocation State Management Publish and Subscribe Messaging Resource Bindings Actors Observability Secrets Conclusion Dapr facilitates the development of microservice-based applications by providing support for key application features. It offers developers an approach to the design of microservices applications, the means to build them, and the runtime to operate them. The modular architecture of components and building blocks, and the sidecar approach, make implementing necessary microservices functionality far more straightforward. That Dapr does all this in a platform-agnostic way is the icing on the cake. Buy : Practical Microservices with Dapr and .NET http://packt.live/3rS1L4u

Amazon

Google

Microsoft

Sentry

Target

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Microsoft's DAPR (Distributed Application Runtime): An Overview

Too Long; Didn't Read

Companies Mentioned

Packt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Microsoft's DAPR (Distributed Application Runtime): An Overview

Too Long; Didn't Read

Companies Mentioned

Packt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES