"Is It Observable" — the Dynatrace DevRel YouTube channel — explores Dapr's functionalities, its various APIs, configuration options, and observability features.
What is Dapr?In traditional application development, developers often tie their business logic to specific backend solutions like Kafka for messaging or PostgreSQL for databases. Migrating between these solutions requires significant code changes. Dapr addresses this by acting as a proxy, providing a predefined set of actions translated into Dapr API calls. This means your application interacts with the Dapr proxy, which then translates the request to the correct format and protocol for the chosen storage solution. This approach frees developers from managing specific libraries for backend interactions, allowing them to focus on core business logic.
Dapr Deployment Models
Dapr proxies can be deployed in several ways:
- Sidecar Proxy: The Dapr component is included in the local runtime of your pod or container, offering low latency but with increased resource footprint.
- Daemon Sets: In Kubernetes, Dapr components can be deployed as daemon sets, with each node having a Dapr proxy.
- Dapr Deployments: A single Dapr proxy can serve a set of components, receiving all their requests.
For Kubernetes deployments, the Dapr operator injects the Dapr proxy into your workload using Dapr annotations.
Dapr Building Blocks (APIs)Dapr provides various building blocks, each designed for specific features in distributed systems:
- Service Invocation: Enables communication between microservices using HTTP or gRPC, decoupling services and allowing for easy migration of backend services.
- State Management: Provides a key-value pair storage solution, supporting traditional options like Redis and in-memory stores, as well as databases like PostgreSQL.
- Pub/Sub: Bundles operations for asynchronous messaging systems, supporting various message brokers like Kafka, Rabbit MQ, and Azure Service Bus. It allows publishing and subscribing to messages.
- Bindings: Acts as a bridge between applications and event-producing solutions. Input bindings listen for events from third-party systems, while output bindings allow applications to produce events to external solutions like databases or file systems.
- Secret Management: Offers a secure and centralized way to manage and access sensitive information like API keys and database credentials from various secret stores (e.g., AWS Secrets Manager, Azure Key Vault).
- Actors: Enables the creation of independent, stateful objects that collaborate in a distributed environment, each with its own data and actions.
- Configuration: Allows applications to retrieve and subscribe to configuration changes dynamically from sources like config maps or Azure App Configuration, enabling re-configuration without restarts.
- Workflow: Facilitates the visual mapping of complex multi-step processes, managing workflow states, errors, and rollbacks for distributed applications.
- Conversation API: A newer building block designed for interaction with Large Language Model (LLM) systems.
- Jobs: Provides the ability for Dapr to trigger and schedule jobs within a business process.
- Crypto: Offers a common library for encrypting and decrypting data in various formats.
Dapr also provides different SDKs (Software Development Kits) for client, actor, workflow, and server-side interactions, with the client SDK being the most commonly used.
Dapr ConfigurationTo connect the Dapr proxy to desired storage backends, several configuration objects are used:
- Core Configuration: Sets up tracing, logging, metrics, and TLS for secure connections between Dapr proxies.
- Resiliency Configuration: Defines rules for Dapr to handle failures, including timeouts, retries, and circuit breakers.
- Component Configuration: Informs Dapr about specific backend services. Each component has a name used in the code, a type indicating the building block it supports (e.g., pub/sub, state management), and specific settings based on the backend being used (e.g., Redis configuration).
Example Use CasesThe video demonstrates Dapr's capabilities through two examples in an OpenTelemetry demo application:
- Product Catalog with PostgreSQL: Replacing a file-based product catalog with a PostgreSQL database. This involves importing the Dapr client SDK, creating a function to query the Dapr state management component, and defining a Dapr component for PostgreSQL.
- Kafka Integration: Interacting with Kafka by importing the relevant SDK, creating a Dapr component, and using Dapr API functions for publishing or subscribing messages.
Dapr ObservabilityDapr offers significant observability features for its proxy, configurable directly within Dapr's configuration objects.
- Tracing: Supports various backends and has native OpenTelemetry support. Tracing settings allow defining sampling rates and stdout settings for detailed spans produced by the Dapr proxy, which include time spent interacting with Dapr and the storage.
- Metrics: Produced in Prometheus format, though OpenTelemetry support is not currently available. Metrics can be enabled via annotations or configuration objects, offering control over cardinality, error codes, and latency buckets. Dapr provides smart options to group URLs and disable method dimensions to control metric cost.
- Logging: Dapr produces different types of logs:
- Control Plane Logs: Produced by Dapr's control plane, with adjustable severity and JSON formatting options. Log levels can be adjusted for individual control plane components like placement, injector, and operator.
- Proxy Logs: Default logs provide details on the starter process and interactions. These can be enabled with annotations and configured for JSON output.
- API Logs: Also known as access logs, these can be enabled and configured within the logging section of the configuration object, with options for obfuscating URLs and including health check details.
Logs are sent to stdout, requiring collectors like OpenTelemetry Collector or Fluent Bit for collection. The metrics, traces, and logs provided by Dapr are rich enough for troubleshooting and understanding misconfigurations. Additionally, Dapr exporters expose Go runtime information, aiding in assessing the health of Dapr components.
Future Outlook
Dapr is considered an "amazing project" for its ability to decouple the infrastructure layer. The current production of spans is appreciated, although more SQL details would be beneficial. The speaker expresses a strong desire for OpenTelemetry support for metrics and logs in Dapr, which would simplify management. Finally, there is an ongoing discussion about integrating Dapr more tightly with service meshes like Istio, potentially as part of the mesh itself, to avoid an extra proxy layer and improve resource and latency efficiency in Kubernetes environments for cloud-native applications.
