Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.
Any language, any framework, anywhere
Today we are experiencing a wave of cloud adoption. Developers are comfortable with web + database application architectures (for example classic 3-tier designs) but not with microservice application architectures which are inherently distributed. It’s hard to become a distributed systems expert, nor should you have to. Developers want to focus on business logic, while leaning on the platforms to imbue their applications with scale, resiliency, maintainability, elasticity and the other attributes of cloud-native architectures.
This is where Dapr comes in. Dapr codifies the best practices for building microservice applications into open, independent, building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is completely independent and you can use one, some, or all of them in your application.
In addition Dapr is platform agnostic meaning you can run your applications locally, on any Kubernetes cluster, and other hosting environments that Dapr integrates with. This enables you to build microservice applications that can run on the cloud and edge.
Using Dapr you can easily build microservice applications using any language, any framework, and run them anywhere.
Microservice building blocks for cloud and edge
There are many considerations when architecting microservices applications. Dapr provides best practices for common capabilities when building microservice applications that developers can use in a standard way and deploy to any environment. It does this by providing distributed system building blocks.
Each of these building blocks is independent, meaning that you can use one, some or all of them in your application. In this initial release of Dapr, the following building blocks are provided:
|Service-to-service invocation||Resilient service-to-service invocation enables method calls, including retries, on remote services wherever they are located in the supported hosting environment.|
|State management||With state management for storing key/value pairs, long running, highly available, stateful services can be easily written alongside stateless services in your application. The state store is pluggable and can include Azure CosmosDB, Azure SQL Server, PostgreSQL, AWS DynamoDB or Redis among others.|
|Publish and subscribe||Publishing events and subscribing to topics|
|Resource bindings||Resource bindings with triggers builds further on event-driven architectures for scale and resiliency by receiving and sending events to and from any external source such as databases, queues, file systems, etc.|
|Actors||A pattern for stateful and stateless objects that make concurrency simple with method and state encapsulation. Dapr provides many capabilities in its actor runtime including concurrency, state, life-cycle management for actor activation/deactivation and timers and reminders to wake-up actors.|
|Observability||Dapr emit metrics, logs, and traces to debug and monitor both Dapr and user applications. Dapr supports distributed tracing to easily diagnose and serve inter-service calls in production using the W3C Trace Context standard and Open Telemetry to send to different monitoring tools.|
|Secrets||Dapr provides secrets management and integrates with public cloud and local secret stores to retrieve the secrets for use in application code.|
Dapr exposes its APIs as a sidecar architecture, either as a container or as a process, not requiring the application code to include any Dapr runtime code. This makes integration with Dapr easy from other runtimes, as well as providing separation of the application logic for improved supportability.
Dapr can be hosted in multiple environments, including self hosted for local development or to deploy to a group of VMs, Kubernetes and edge environments such as Azure IoT Edge.
In self hosted mode Dapr runs as a separate side-car process which your service code can call via HTTP or gRPC. In self hosted mode, you can also deploy Dapr onto a set of VMs.
In container hosting environments such as Kubernetes, Dapr runs as a side-car container with the application container in the same pod.
Developer language SDKs and frameworks
Note: Dapr is language agnostic and provides a RESTful HTTP API in addition to the protobuf clients.
Dapr can be used from any developer framework. Here are some that have been integrated with Dapr.
In the Dapr .NET SDK you can find ASP.NET Core integration, which brings stateful routing controllers that respond to pub/sub events from other services.
In the Dapr PHP-SDK you can serve with Apache, Nginx, or Caddyserver.
Dapr SDKs support for virtual actors which are stateful objects that make concurrency simple, have method and state encapsulation, and are designed for scalable, distributed applications.
Dapr integrates with the Azure Functions runtime via an extension that lets a function seamlessly interact with Dapr. Azure Functions provides an event-driven programming model and Dapr provides cloud-native building blocks. With this extension, you can bring both together for serverless and event-driven apps. For more information read Azure Functions extension for Dapr and visit the Azure Functions extension repo to try out the samples.
To enable developers to easily build workflow applications that use Dapr’s capabilities including diagnostics and multi-language support, you can use Dapr workflows. Dapr integrates with workflow engines such as Logic Apps. For more information read cloud-native workflows using Dapr and Logic Apps and visit the Dapr workflow repo to try out the samples.
Designed for Operations
The monitoring tools support provides deeper visibility into the Dapr system services and side-cars and the observability capabilities of Dapr provide insights into your application such as tracing and metrics.
Running Dapr on a local developer machine in self hosted mode
Dapr can be configured to run on your local developer machine in self-hosted mode. Each running service has a Dapr runtime process (or sidecar) which is configured to use state stores, pub/sub, binding components and the other building blocks.
Running Dapr in Kubernetes mode
Dapr can be configured to run on any Kubernetes cluster. In Kubernetes the
dapr-operator services provide first class integration to launch Dapr as a sidecar container in the same pod as the service container and provide notifications of Dapr component updates provisioned into the cluster.
dapr-sentry service is a certificate authority that enables mutual TLS between Dapr sidecar instances for secure data encryption. For more information on the
Sentry service read the security overview
Deploying and running a Dapr enabled application into your Kubernetes cluster is as simple as adding a few annotations to the deployment schemes. You can see some examples here in the Kubernetes getting started sample. Try this out with the Kubernetes quickstart.