The Cloud Native Computing Foundation (CNCF) recently announced that it accepted the Distributed Application Runtime (Dapr) as a CNCF incubating project. This statement follows an earlier announcement by Dapr, announcing the formation of the Dapr project's Steering and Technical Committee (STC).
As a CNCF-hosted project, Dapr is part of a neutral foundation aligned with its technical interests and the broader Linux Foundation. The CNCF provides governance, marketing support, and community outreach. Chris Aniszczyk, CTO of CNC, said the following:
Distributed applications and microservices form the basis for containers and cloud-native, but writing distributed applications that are scalable and reliable can be incredibly difficult. Dapr integrates well with other CNCF projects and provides best practices developers can build on top of using any language or framework. We're excited to welcome Dapr to the CNCF and work to cultivate their community.
Microsoft introduced Dapr in 2019, and the Dapr team announced its production-ready v1.0 release in February of this year. Many organisations use Dapr in production. A major use case on Alibaba Cloud was published this past March. Adopters run Dapr on all major cloud vendors and on-premises environments.
Today, the Dapr STC governs the project with Alibaba, Intel, and Microsoft representatives. The STC steers the overall direction and vision of the project and provides technical guidance to the project's maintainers.
Following the recent announcements, InfoQ took the opportunity to speak with Yaron Schneider, co-founder of Dapr and KEDA and a member of Dapr's STC.
InfoQ: The CNCF recently accepted Dapr as a CNCF incubating project. What does it mean for Dapr? How will it affect Dapr's developers and users?
Yaron Schneider: Dapr's acceptance into the CNCF as an incubating project can help the project and the cloud-native ecosystem in several ways. For Dapr, this means getting more traction with CNCF projects developers, bringing new contributions and perspectives to the project. For CNCF, I think the Dapr developer community can bring their application-centric perspectives and know-how and contribute to the entire ecosystem. As more developers contribute to Dapr, they will add more features to benefit Dapr's end users.
InfoQ: Dapr 1.0 was announced back in February. How has Dapr's adoption grown since then? Do you expect that being accepted to the CNCF will help drive adoption?
Schneider: We've seen tremendous growth both in contributions to the project and also with enterprises and startups alike. In October, we hosted the first-ever DaprCon, where many adopters shared their stories. I highly recommend watching the content to see how the project's grown since its inception. I definitely expect to see more end-user adoption now that the project is in CNCF.
InfoQ: A Steering and Technical Committee (STC) governs Dapr. How does it work? Who decides which features get prioritised and how?
Schneider: The Steering and Technical committee currently comprises five members from different companies and can grow to 11. No single organisation can have over-representation, and this is how vendor neutrality is guaranteed. Dapr maintainers are the primary decision-makers in terms of features. That doesn't change with the introduction of the STC. The STC drives the overall technical direction of the project, so things like new building blocks and APIs will most likely need STC approval.
InfoQ: In your opinion, who should use Dapr? Which use-cases does it solve best?
Schneider: Developers writing microservices will find Dapr really useful as it helps manage things at a large scale using built-in best practices. You get things like state management and pub/sub as "distributed systems ready" features with all the correct practices in place from the API to tooling. We found that developers who deploy their apps on Kubernetes find Dapr particularly helpful. They get these consistent APIs that can work locally on their dev machine and a Kubernetes cluster.
InfoQ: What are the current focus areas in Dapr's development?
Schneider: As maintainers, we're trying to nail down what we call Fundamentals - our test infrastructure and release pipelines and processes. Notably, we want to make the Dapr release processes more open to the community. In terms of features, the upcoming 1.5 release will see the addition of the Configuration building block - a feature that's been in the works for months.
InfoQ: What is your vision for Dapr? What's the next "big thing"? Is version 2.0 on the table?
Schneider: With Dapr now in the CNCF, I want to see the Dapr APIs becoming a standard and ultimately separate from the Go implementation. This change will allow for different implementations like a Dapr edge distribution, for example. Version 2.0 is currently not on the table, although allowing for non-Go-based components and dynamically loading components might be a step in that direction.
InfoQ: How can InfoQ readers learn Dapr? What learning resources are available?
Schneider: The best resources are the Dapr docs and the quickstarts repository. Beyond that, there are some outstanding books out there. I can recommend "Introducing Distributed Application Runtime (Dapr)" and "Practical Microservices with Dapr and .NET". Also, I've myself written a book on Dapr called "Learning Dapr".
Dapr is an open-source, portable, event-driven runtime that allows developers to build resilient, microservices-based, stateless, and stateful applications that run on the cloud and edge. It aims to enable developers to write business logic instead of solving distributed system challenges, significantly improving their productivity and reducing development time. Microsoft Azure recently included out-of-the-box support for Dapr in its Azure Container Apps preview.
