The architecture of Dapr

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 operators can adapt applications to the hosting environment by simply intervening in the configuration.

Here is a complete list of the tools and components of Dapr:

• The Dapr command-line interface (CLI): A cross-platform command-line tool to configure, manage, and monitor the Dapr environment. It is also the tool used to locally debug Dapr applications.
• The Dapr API: The API that defines how an application can interact with the Dapr runtime in order to leverage its building blocks.
• The Dapr runtime: This is the core of Dapr that implements the API. If you are curious, you can take a look at how it is developed in Go at Dapr's repository: https://github.com/dapr/dapr.
• The Dapr host: On your development machine, the host runs as a standalone process; in Kubernetes, it is a sidecar container in your application's pod.
• The Dapr operator: Specific to Kubernetes mode, the operator manages bindings and configurations.
• The Dapr sidecar injector: Once instructed via configuration in Kubernetes mode, this takes care of injecting the Dapr sidecar into your application pod.
• The Dapr placement service: This service has the objective of distributing (or placing) Actor instances across the Dapr pods.
• Dapr Sentry: A built-in certificate authority (CA) to issue and manage certificates used by Dapr to provide transparent mutual Transport Layer Security (mTLS).

Dapr provides several building blocks that microservice application developers can adopt selectively, based on their needs. These are outlined here:

• Service invocation: 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 building block is presented in more detail in Chapter 3, Service-to-Service Invocation.

• State management: This is to efficiently manage the application state as a simple key-value pair (KVP), relieving your stateful or stateless services of the need to support different backends. Dapr provides many state stores, which include Redis, Azure Cosmos DB, Azure SQL Server, and PostgreSQL, which can be plugged in via configuration.

  You can learn about this building block in Chapter 4, Introducing State Management.

• Publish and subscribe (pub/sub) messaging: The pub/sub 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.

  A discussion of this building block is presented in Chapter 5, Publish and Subscribe.

• Resource bindings: This is where the event-driven nature of Dapr shines: with bindings, your application can be triggered by a Short Message Service (SMS) message sent via Twilio (just one of the popular services in this area).

  This building block is presented in more detail in Chapter 6, Resource Bindings.

• Actors: The actor pattern aims to simplify highly concurrent scenarios by splitting the overall request load between 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. Dapr provides great benefits in this space.

  You can learn about this building block in Chapter 7, Using Actors.

• Observability: Dapr enables the developer and operator to observe the behavior of the system services and applications without having to instrument them.

  This building block is presented in more detail in Chapter 9, Tracing Dapr Applications.

• Secrets: It is a common requirement and a healthy practice to keep secrets at a safe distance from the code, even 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 Key Vault, among many options.

After learning about Dapr architecture and components, before we can start using them, we need to set up Dapr in our development environment, which will be the topic of the next section.