Open-source application framework combines building blocks for Kubernetes and support for classic distributed application design patterns. More is on the way.
Dapr, the distributed application runtime, is close to leaving the Cloud Native Computing Foundation’s incubation program. Regular updates have refined existing features and added new capabilities. The result is a capable platform for building and running cloud-native applications built on top of Kubernetes or as a self-hosted binary.
The self-hosted option lets you bring IoT devices, among others, into your applications, accessing them directly from your code. This ties in with tools that let you include state in your applications without having to build your own tools to manage state outside of a Kubernetes application.
Another useful aspect of Dapr is its support for message-oriented development, building on the classic actor/message design pattern with tools that support reliable messaging and your choice of consistency models. This builds on the platform’s heritage in distributed systems design, with key contributors bringing many years of experience in the field, including work on Microsoft’s virtual actor platform Orleans.
Microsoft remains a major contributor to the project, but newer companies have emerged that can focus on Dapr. These include Diagrid, which was founded at the end of 2022 by former Microsoft engineers Mark Fussell and Yaron Schneider, who between them have been working on distributed systems for many years. The two co-founded the Dapr project, Fussell worked on Azure Service Fabric, and Schneider was part of KEDA and Azure Container Apps.
Diagrid’s tools add additional features to the open source Dapr. Catalyst provides APIs that help build messaging and workflow-based applications, and Conductor adds automated management tools and gives you a way to visualize your applications. Catalyst is currently in preview, and there is a free version of Conductor to help develop Dapr applications.
What’s new in Dapr?
I spoke to Mark Fussell about the upcoming Dapr 1.14 release and the philosophy behind Dapr. As he points out, the role of Dapr is to deliver cloud-native applications in a better way, by understanding that at heart, they’re distributed applications. “Dapr really helps [developers] with software architectures or coding patterns, that they don’t have to be inventing themselves.”
That’s an important point, as it lets us take advantage of mature architectural patterns, like actors and workflows. Fussell notes, “Workflows are very important because they can create long-running durable execution. And they allow us to create this coordinated set of other activities.” By having a way to orchestrate and coordinate services across a set of microservices, we can think about how those services are composed into an application and how they interact with each other and with our data.
I previously looked at Dapr when it was still a very early release, but the fundamentals haven’t changed much. It still adds a set of building blocks to your Kubernetes environment, which you can use to write event-driven microservices in any language and your choice of service model. There’s integration with familiar storage platforms, such as Redis, so you can manage state across a distributed application, offering both strong and eventual consistency models, as well as first-write or last-write wins.
Dapr installs as a CLI-based tool, with the dapr init command launching a set of containers that prepare your environment to work with Dapr. Once installed you can start to explore the Dapr API through http or gRPC. The team provides a growing set of sample applications that demonstrate how to use key features, for example, setting up a pub/sub messaging environment.
We’re close to the launch of Dapr 1.14, which introduces a small set of new features while improving the performance of its existing APIs. That should set us up for a major Dapr 1.15 release later this year, which will add more APIs and more features to simplify the development of cross-cloud applications.
Add cron to Kubernetes with Dapr’s Jobs API
Perhaps the most interesting new feature in 1.14 is Dapr’s Jobs API. Here the platform doubles down on its role as an actor scheduler, managing actors running inside Dapr, as well as offering a batch processing platform for both automated operations and application features.
At its heart, the Dapr Jobs API is a scheduler that guarantees execution of the job in question. That guarantee is for at least one execution, working with the scalability tools of the underlying Kubernetes environment to ensure operation. There’s also support for Dapr’s self-hosted mode. The job won’t execute before the target time, but it may fail if invoked after that time, as it is not guaranteed beyond the time. The job schedule data is held in the scheduler’s own etcd database, separate from other Dapr data.
The scheduler is part of a bigger story, as it’s the basis for performance and scale improvements in the Dapr workflow tool. Workflows in distributed applications need to scale to tens or hundreds of thousands of parallel executions. That led to the development of Jobs support. Fussell points out, “There was a great need for people to kick off cron-like jobs.” Kubernetes does have some basic jobs features, but very low-level and not really accessible to developers.
You can use the Jobs API for more than application services, as it can run platform engineering tasks, updates and maintenance code, as well as regularly scheduled application operations. A typical application job might update its database with the latest operational data, running an ETL task on data from your line-of-business systems. You can schedule jobs for a specific time, much like embedding a cron job in your application, or after a specific duration, for example, to run a clean-up task after an application task has run.
One other option for using Dapr jobs is taking functions from existing applications and moving them to a distributed cloud-native environment. If you’ve been batching up financial reporting for overnight processing, you can bring that same operating model to your updated code while still taking advantage of modern scalability features.
Scalability is key. You can use a scheduled job to run the same job across multiple replicas, allowing you to build, say, a Monte Carlo simulation and run multiple variants in parallel to get results quickly.
This, perhaps, is the real value of Dapr, as it allows you to bring a wider range of business applications to cloud-native platforms, taking advantage of their orchestration capabilities to manage resources automatically.
More than a sidecar
Another useful new feature is Dapr Shared. This gives you an alternative way of using Dapr with Kubernetes, installing as a daemonset or as a deployment. Although working as a sidecar remains the default, there are use cases, such as serverless applications, where you may want to use Dapr’s APIs, but the overhead of injecting a sidecar every time you launch a container could add significant latencies to service startups. At the same time, you may need to keep Dapr’s APIs and message services running when a service scales to zero.
Using a daemonset, a Dapr pod runs alongside your workloads. Each time the Kubernetes scheduler deploys a new instance of your application, it’ll deploy a new Dapr daemon, so that the Dapr APIs are always available with minimum latency. There is, of course, a downside, in that this approach takes more system resources than using a sidecar.
If resources are an issue, you can use Dapr as a Kubernetes deployment, installing one instance of the Dapr runtime per cluster. The Kubernetes orchestrator will determine which node it uses for Dapr, so there can be network latencies between workloads and APIs. You may need to rethink how your application handles messages and what consistency model you use.
Most of the updates in Dapr 1.14 are improvements to existing features, such as performance and security, which, together with the larger changes, should make it easier to build and deploy Dapr applications across your choice of clouds and development tools. Among the many available SDKs, the .Net implementation offers a full set of features, including support for Actors and Dapr’s workflow tools. If you prefer Python, Go, JavaScript, or even Java, you can find stable SDK releases; C++ and Rust are under development.
