Exploring 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.

The following 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.
• Dapr Helm charts: It is worth mentioning that Helm charts are provided for a richer experience in installing and updating Dapr in a Kubernetes environment.
• 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 at 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, and they are as follows:

• 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 4, 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 5, 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 6, 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 the area of communication API).

This building block is presented in more detail in Chapter 7, 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 8, 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 11, Tracing Dapr Applications.

• Secrets: It is a healthy practice to keep secrets segregated from the code. Dapr enables you to store secrets and to reference these from other components, in Kubernetes or Azure Key Vault, among many options.
• Configuration: Introduced in Dapr version 1.8 in Alpha state, this building block addresses the common need to retrieve the configuration data needed by an application.
• Distributed lock: Introduced with Dapr version 1.8 in Alpha state, it provides a powerful lease-based mechanism to manage mutually exclusive access to a named lock. The lock can be used by the application to assure exclusive access to a resource by many concurrent instances.

After learning about Dapr architecture and components, and 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.