Open Source Dapr Project Adds SDKs to Better Manage Workflows
An update to the open source Distributed Application Runtime (Dapr) project adds JavaScript and TypeScript software development kits (SDKs) that make it simpler to orchestrate workflows across a distributed computing environment.
In addition, version 1.13 of Dapr adds an SDK written in the Rust programming language to make it simpler to invoke Dapr Actors, a programming model for highly scalable stateful applications.
Originally developed by Microsoft, Dapr provides a framework for reusing application programming interfaces (APIs) for communication, publish/subscribe, state management, workflow and secret management. Rather than having to recreate these APIs for every application, the Dapr framework now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) allows developers to accelerate application development by reusing the same APIs for these services across every application.
A survey of 151 Dapr developers, architects and managers conducted by Dimensional Research on behalf of Diagrid, a provider of an instance of Dapr for enterprise IT organizations, finds three-quarters (74%) of respondents are using Dapr for mission-critical applications based on a range of architectures, including microservices (93%), event-driven (79%) and software-as-a-service (SaaS) applications.
More than a third of respondents (37%) have Dapr deployed in a production environment, while 37% have applications in development that they plan to deploy in a production environment. Three-quarters (75%) of respondents run Dapr on Kubernetes. Windows (47%) or WSL on Windows Subsystem for Linux (20%), macOS (25%) and Linux (8%) are the most commonly used platforms for building applications that incorporate Dapr. Nearly two-thirds of respondents (65%) are using Dapr to build greenfield applications, the survey finds.
Diagrid CTO Yaron Schneider said the latest SDKs added to Dapr will make it simpler to orchestrate services across modern asynchronous applications. The challenge developers face is that building asynchronous applications across a distributed computing environment is significantly more challenging than building synchronous applications, he added.
The survey finds asynchronous messaging using the publish and subscribe building block is the most common use case for Dapr (85%), followed by synchronous service-to-service invocation (79%), state management (66%), secrets management (48%) and workflow (23%). An additional 41% are also planning to use the workflow block in the future.
A full 95% reported that Dapr saves developer time, with more than half (55%) seeing a savings in developer time of 30% or more, the survey found. Top reasons for using Dapr are it makes building microservices easier (65%), followed by no code changes when swapping components (60%). Overall, 86% of respondents expect to see their Dapr usage grow.
However, more than half (53%) noted that debugging/troubleshooting is hard, while 29% said documentation is inadequate. Respondents said they would like to see better sample code (73%) as well as recommendations for best practices (73%), architecture patterns (67%) and solution templates (60%). A total of 59% would also like to see building blocks for a document (59%) and BLOB storage (55%) APIs.
It’s not clear whether Dapr will gain traction outside of Windows environments in the coming year, but as many developers continue to be challenged by building modern asynchronous applications, the need for some type of reusable framework for invoking services is only going to become more pronounced.