Microsoft’s Dapr Introduces Cloud Native Development to the Enterprise
Kubernetes is a great tool for managing distributed workloads, but it presents a set of hurdles to developers who would potentially find it of benefit.
Coding for K8s, a developer has to worry about the kind of Ingress controller to use for their app, or what particular autoscaler technique to deploy. These sorts of concerns have traditionally have been the job of operations teams. “When you deploy your Kubernetes app, you’re basically, as a developer, responsible for handling all of that, all the way down to the infrastructure and describing that as part of your application description,” explained Mark Russinovich, Microsoft Azure chief technology officer.
Such additional responsibilities can slow development and even hamper an organization’s efforts to move to a more robust distributed, microservice architectures.
The idea behind Microsoft’s Distributed Application Runtime (Dapr) is to ease the typically difficult plumbing work required of developers to tie together distributed systems. Dapr provides a set of interfaces for enterprise-wide services, or “building blocks,” that make it easier to build portable applications that can be moved across clouds and on-prem environments. It also allows the enterprise to define a common set of services that can be used across all applications, which would certainly help the organization streamline and standardize its infrastructure.
Dapr was first released in October 2019 and this week, with the release of version 1.0, Microsoft has declared this portable, event-driven runtime as ready for professional use. “The primary goal [of Dapr] is to democratize cloud native development for the enterprise,” Russinovich told The New Stack.
It can be used for both stateless and stateful applications, on either the edge or in cloud computing environments, as well as across multiple clouds (“multicloud”). Dapr is using Kubernetes as the primary hosting environment to run production applications, though Dapr end users aren’t tied to using Kubernetes.
Much like service mesh software, Dapr is built on sidecars or small applications that control that sit along with an application and control all the input and output. The developer then calls the needed functionality from Dapr itself, rather than from each individual service.
But whereas a service mesh concerns itself primarily with the routing of messages (along with the related monitoring and security needs), Dapr is focused on addressing developer needs, or, “application-level constructs,” Russinovich said. To manage state, or to subscribe to a pub/sub messaging system, a developer would write to the Dapr construct. That said, there is some overlap between the service mesh and Dapr. For instance, Dapr can take of the mutual TLS-based encryption between microservices, as well as monitoring and logging.
Dapr can be run either for existing apps, including those that are now considered to be monolithic in design. In these cases, a Dapr sidecar can be installed on the same server as the application. For maximum microservices efficiency, Dapr can be installed onto a Kubernetes cluster, so all the applications running on that cluster that have Dapr annotations will automatically pick up the sidecar.
Microsoft has built an extension for Dapr into its Visual Studio developer platform, and there are several hooks into Azure services, including Azure Functions, and Azure Logic Apps. Primarily, Microsoft wants to integrate Dapr with the broader open source community: Dapr is open source, covered by the MIT License. “One of the messages we hear loudly and clearly from enterprise enterprises, is, ‘Hey, we want to build our applications on top of an open source, technology base so that it can be portable and we can take advantage of open source ecosystem,'” Russinovich said.
The problem of making Kubernetes palatable to developers has been tackled in a number of other open source efforts, largely around the idea of a universal control plane, which would set the stage for enterprises to build their own Kubernetes-based self-service style Platforms-as-a-Service for their developers. Crossplane, an open source control plane built by Upbound, enables provisioning cloud services from Kubernetes and rolling your own Kubernetes-based PaaS. KubeVela is an extensible “platform engine” that layers on top of Crossplane and Kubernetes, where developers need not worry about the underlying infrastructure.
None of these efforts, however, has yet the reach into the enterprise that Microsoft has. A number of companies are already using Dapr in production settings, Microsoft reported. Autonomous system platform provider Roadwork combined Dapr with the KEDA Kubernetes event-driven autoscaler to create a data analysis system that automatically scales both the application and the underlying cluster based on the incoming traffic. Opto-electronics ZEISS used Dapr on Azure to reengineer a previously decades-old monolithic validation and ordering system so users could more easily update, reroute, or track orders without reconfiguring tables. And South Africa-based technology business Ignition Group built order processing software to track products, manage subscriptions, and handle payments Using Dapr and .Net.
