Understanding Dapr

Dapr is an event-driven, portable runtime created by Microsoft with an open source approach and it is a Cloud Native Computing Foundation (CNCF) incubated project.

Being event-driven (which is emphasized in the definition of Dapr) plays an important role in microservices; this is because an application can be designed to efficiently react to events from external systems or other parts of the solution and to produce events as well in order to inform other services of new facts or to continue processing elsewhere, or at a later stage.

Dapr is portable as it can run locally on your development machine in self-hosted mode; it can also be deployed to the edge, or it can run on Kubernetes.

The following diagram shows the many building blocks provided by Dapr:

Figure 1.1 – Dapr architecture

Portability does also extend beyond the hosting environment—while Dapr is an initiative that was started by Microsoft, it can also run on Kubernetes on-premises or in the cloud with Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP), or any other cloud vendor.

Dapr has been built on the experience gained by Microsoft in developing hyperscale cloud-native applications. It has been inspired by the design of Orleans and Service Fabric, which in turn enables many Microsoft Azure cloud services to operate resiliently and at a large scale.

A brief history of Dapr

Dapr was first released in October 2019, and you can find more information at https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-dapr-open-source-project-build-microservice-applications/.

Dapr adopted an open governance model early on in the initial development phase in September 2020; see the description at https://blog.dapr.io/posts/2020/09/30/transitioning-the-dapr-project-to-open-governance/.

Dapr reached the production-ready v1.0 release in February 2021; see https://blog.dapr.io/posts/2021/02/17/announcing-dapr-v1.0/ for more details. In November 2021, Dapr joined CNCF as an incubated project; see the announcement at https://blog.dapr.io/posts/2021/11/03/dapr-joins-cncf-as-an-incubating-project/.

Dapr offers developers an approach to design the tools to build and the runtime to operate applications, based on a microservice architecture style.

Microservices offer a vast array of benefits balanced by increased complexities in team and product management, usually with a significant burden on the developer and the team in order to get started.

What if you could leverage a runtime such as Dapr to help you get through the common patterns you will likely need to adopt, and thus ease your operations?

The following figure shows the two Dapr hosting modes:

Figure 1.2 – Dapr sidecar

As depicted in Figure 1.2, the Dapr runtime operates in sidecar processes, lifting most of the complexity from the application to a separate environment, greatly simplifying development and operations as well. These sidecar processes are run locally in your development environment or as containers in a Pod on Kubernetes.

From an application perspective, Dapr is an Application Programming Interface (API) that can be directly reached via HyperText Transfer Protocol (HTTP), Remote Procedure Call (gRPC) calls, or, even more simply, via any of the Software Development Kits (SDKs) available for .NET, Java, Go, Python, PHP, JavaScript, C++, and Rust languages.

As we will experience later, it is not necessary to adopt the Dapr SDK in your application; a request 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/<methodname>. Nevertheless, using the SDK does provide many benefits if you are writing a Dapr service adopting the server extensions, interacting with Dapr via the client SDK, or leveraging the Dapr actor model with the Actor SDK.

You can learn more about SDKs and the supported languages in the Dapr docs at https://docs.dapr.io/developing-applications/sdks/.

Now that we have learned about the high-level architecture of Dapr, it is time to also clarify what Dapr is not.

What Dapr is not

While we hope the overview of Dapr has informed and intrigued you enough to spend time on this book, when we have the chance to talk about Dapr, we often find ourselves in need of clarifying what Dapr is not. This makes it easier to eliminate any misconceptions we may have about what Dapr does, as follows:

• Dapr does not 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. As an example, the management of the connection to the database where the state is stored is a responsibility of Dapr and, as we will see in the following chapters, it is transparent to the microservice application code.
• Dapr is not a service mesh. While many similarities can be found in the general objectives of Dapr and service meshes, Dapr does provide these benefits at the application level, while a service mesh operates on the infrastructure. For instance, it is the developer’s responsibility to decide how to handle errors Dapr might return if there is a conflict or an intermittent issue; whether it is adopting a retry policy as provided by the Dapr resiliency configurations, raising an error back to the client, or compensating the operation, these are explicit choices only the developer can make.

Dapr is designed to be integrated with service meshes such as Istio, which is out of the scope of this book.

• Dapr is not a Microsoft cloud service. It does help the developer build microservice applications in the cloud, and it surely provides many integrations with Azure cloud services, but it also has as many components for AWS, GCP, and other services. At the same time, Azure does offer rich support to Dapr in Azure Kubernetes Service (AKS) with the native extension, in Azure API Management with Dapr policies, and in Azure Container Apps with Dapr native integration.
• Dapr is not a .NET only technology. Dapr itself has been written in the Go language and any language can leverage it. SDKs for many languages are available but you can also choose to interact directly with the Dapr API without any additional library.

Important note

While this book is heavily skewed toward .NET, Dapr does provide the same benefits to Python developers (just as an example) as it provides SDKs for Dapr and Dapr Actor, with Kubernetes as the deployment target—Dapr welcomes all developers in a vendor-neutral and open approach.

We hope this perspective on the Dapr objectives and role will help you in properly adopting this technology. The next section will be dedicated to understanding the architecture of Dapr.