How Distributed Application Runtime (Dapr) has grown since its announcement

Since the October 2019 announcement of the Distributed Application Runtime (Dapr), we have seen a tremendous response and the emergence of an engaged Dapr community. Over the past six months, more than 120 contributors have jumped on board and participated in the effort to build and extend Dapr through the GitHub repos – opening issues, offering feature proposals, taking part in discussions, and making more than 350 distinct code contributions. This community engagement has demonstrated that Dapr enables developers from all backgrounds to solve some of the toughest challenges when developing distributed applications. We are grateful for the engagement and participation from the community helping us make Dapr better.

On top of the community response, we have also been busy working with customers around the world and from different industries to use Dapr for developing business-critical workloads. These customer engagements have been a tremendous source of feedback and participation, helping shape the roadmap for Dapr and putting Dapr on a path towards a stable v1.0 release. In future blog posts, we’ll share some of these real-world scenarios where Dapr is helping companies build their future applications.

What is Dapr?

Dapr is an event-driven, portable runtime for building microservices on cloud and edge and embraces the diversity of languages and developer frameworks. Dapr codifies best practices for building distributed applications and at its core are API abstractions that provide common capabilities needed to build microservices, including state management, service invocation, pub/sub messaging, secrets management, and others.

Each capability is abstracted through a “Building Block” that defines a simple and consistent API decoupled from the technology chosen to implement it through the use of pluggable components. This best practice of decoupling frees developers from the burden of integrating and having a deep understanding of the underlying technologies they use. The use of building blocks also allows swapping implementations when the application is deployed in different hosting environments or when needs change as the application evolves without affecting your code. Developers are free to use all, a few, or even just one building block as needed.

Since Dapr itself provides both HTTP REST or gRPC APIs, applications using Dapr are portable and can be written in any language. Furthermore, Dapr runs as a sidecar to the application so a developer using Dapr simply sends a call to the Dapr sidecar and Dapr takes care of the rest. Since Dapr is a process or container that runs alongside the application it can run in any environment including a local dev machine (running Linux, Mac, or Windows), a Kubernetes cluster, an ARM edge device, or any other compute infrastructure. Dapr is also not limited to either on-premises or cloud environments – it can run alongside any application, written in any language, deployed to any environment.

• To learn more about how Dapr read this overview.
• To try it yourself, see Getting started with Dapr.

Dapr evolution

Dapr has evolved considerably in the five versions released since October 2019. These are some of the highlights made in the past six months:

More building blocks, more components

Secrets building block – The first example of a community-driven addition to Dapr is the introduction of the Secrets building block which enables developers to retrieve secrets from secret stores that can then be used to authenticate to other resources, such as database access. The secrets building block takes away the complexity of authentication and secret retrieval with the store and turns this into a local API call. Currently supported secret stores include, HashiCorp Vault, Azure Key Vault, AWS Secret Manager, GCP Secret Manager, and Kubernetes.

More components – In addition, there have been many contributions of components, extending Dapr’s support for commonly used technologies across all building blocks. For example, Dapr was launched with support for two state stores (Redis and Azure Cosmos DB) and since has added components for a total of 16 different state stores, including Memcached, MongoDB, AWS DynamoDB, among others. To explore more components, see the components contribution GitHub repo.

Extended developer tools support

SDKs – While Dapr is independent of any programming language, it can be easily integrated into applications with language-specific SDKs. As we see more developers using Dapr, our investment in these SDKs to help streamline Dapr integration has increased. Dapr offers SDKs for JavaScript, Python, Java, .NET, Go, as well as recently added Rust and C++. In addition, based on community feedback many improvements have been added into the Java SDK, included virtual actors, typed classes, and integration with the Spring Boot web framework. For .NET there have also been improvements to the types classes and integration with ASP.NET Core web framework. Similar support is planned for the other SDKs as part of the future road map.

Visual Studio Code extension – Being able to develop applications on your local machine without any cloud dependency is important for productivity and cost and is a key goal of Dapr. The Dapr Visual Studio Code (VS Code) preview extension helps developers debug applications using Dapr, interact with the Dapr runtime, and combines with the Dapr CLI. You can find the extension in the Visual Studio Marketplace.

Dapr dashboard – This Dapr dashboard is a web UI that helps you visualize information about Dapr instances running on your local machine or on Kubernetes.

Increased security

Making sure that messages cannot be sniffed or tampered with in a distributed application is vital to prevent any malicious behavior. Dapr provides end-to-end secure encryption via mutual TLS. This includes encryption of network traffic between the sidecars and from every sidecar to the Dapr control plane. Mutual TLS is turned on by default for any application using Dapr and is configurable to rollover certificates on a frequent basis, for example, every hour. Users can bring their own certificates or use the built-in certificate authority Dapr provides to ease certificate generation and management. Learn more about Dapr security features.

Observability

As the Dapr sidecars run alongside services, it offers advanced observability capabilities including tracing, logging, and metrics collection. Dapr currently uses the Open Census standard and is moving to the Open Telemetry standard as it moves to a stable version. The adoption of standards, where possible, is a key goal of Dapr. For example, all pub/sub events also conform to the v1.0 Cloud Events specification

Tracing – Tracing provides visibility of the calls between your services to create an application map and help diagnose issues in production. Dapr uses middleware to intercept traffic and adds correlation-IDs to enable distributed tracing using W3C Trace Context. Since Dapr integrates at the application level it enables asynchronous tracing on top of synchronous tracing meaning, for example, intercommunication via pub/sub can be traced. Furthermore, tracing is handled by the Dapr sidecar, so no code changes are required to instrument an application.

Metrics – Metrics provide visibility into call latency times between services and resource usage. Dapr provides metric collection for both Dapr services (sidecar and the Dapr control plane system services), as well as the user application services. Metrics collected include CPU and memory usage, sidecar injection failures, request error rates, and many others. Dapr allows easy integrations with technologies such as Prometheus or Azure Application Insights so users can easily set up metric visualization. See how to setup Dapr with Prometheus and Grafana as an example.

What’s next on the roadmap?

As Dapr matures, the focus of the upcoming work is towards the v1.0 release, getting Dapr out of preview and to production quality. This includes finalizing APIs, making stability improvements including long-running tests, extending end-to-end testing, performance testing infrastructure including releasing benchmark numbers, external security audits and threat model analysis, and taking contributions from the community.

To ensure that we are confident in getting to stable v1.0 release, we are working closely with several companies to take Dapr into production, deployed into a number of different environments, and with a diverse set of developer frameworks, including .NET, Go, Java, C++, Node.js, and others.

Join the Dapr community

We’d love for you to try out Dapr for yourself and become a member of the Dapr community. You can get involved in many ways, including:

• Explore the GitHub repos. Read the docs, comment on issues or open new ones, and contribute through pull requests. Look for issues labeled as “good first issue” to start with, for example, in the dapr/dapr or the dapr/components-contrib.
• Ask questions and join the discussions in the Dapr community Gitter channel, follow @daprdev on Twitter, or join the community calls held every two weeks (or view recordings of previous calls).

It’s an exciting time to be a developer in the era of microservice development and we are excited to have you take part in the Dapr journey.