 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
The Dapr open source distributed runtime is nearing a 1.0 release, possibly by the end of the year, noted Mark Chmarny, Microsoft principal program manager in the office of the Azure CTO, in a Cloud Native Computing Foundation Webinar held earlier this month.
It will be a timely release of a much-needed technology for the cloud native community. Introduced a year ago by Microsoft, Dapr (Distributed Application Runtime) tackles one of the toughest issues with distributed computing, namely how to make it easy enough for developers to use, without getting them bogged down in configuring all the supporting infrastructure necessary for the microservices components to interact with one another in a dynamic environment. It sets the stage for the much-desired multicloud operations, where it provides a single interface for developers to build apps that may move around, or even span, multiple commercial cloud services. And perhaps most importantly, it gives developers an easy abstraction for using Kubernetes.
Dapr allows the developer to write a single application that can run on multiple platforms — be they the cloud, bare metal, an internal Kubernetes deployment — by way of a standardized API. The API offers the most common usage patterns with distributed applications, such as service invocation, resource binding, state management, Pub/Sub, virtual actors, observability, and so on. These can serve as the basic building blocks for applications.
“Once registered in Dapr, a component is automatically accessible by way of the API,” Chmarny said.
Any language could be used, and calls across the components are made by http or gRPC, and offers telemetry across different components with no spans.
“Dapr really tries to meet the developers where they are,” Chmarny said.
This last point is especially valuable given the challenges in getting developers to understand how to use Kubernetes.
“When somebody’s creating a deployment for Kubernetes, they’re mixing application developer concerns in with operator concerns, in with infrastructure operator concerns. And so, as a developer authoring one of these manifests, you’ve got to know all of these different concepts related to the infrastructure, which distract you from your core goal, which is to define the application,” said Microsoft Azure Chief Technology Officer Mark Russinovich in a talk earlier this year.
In his talk, Russinovich demonstrated how to run a single application, with only minor configuration tweaks, on three different platforms: Azure, Amazon Web Services and a cluster of Raspberry Pis running on stage.
Behind the scenes, K8s manages Dapr through two customer resource definitions and four system pods, for sidecar injection, actor placements and certificate management and other duties. Dapr is an event-driven architecture, meaning an event must trigger an application, from Kafka or SQS, as well as through outside APIs, such as Twitter or Twilio.
Each microservice within the overall application communicates exclusively with a dedicated Dapr sidecar. “Dapr executes the functionality on behalf of the application,” Chmarny said. The application doesn’t even need to know about Dapr. With Kubernetes, linking a sidecar to an application is simple, merely adding the annotation to the YAML deployment file. A developer can switch between two service busses, say RabbitMQ and Redis, with no change in actual code, Chmarny demonstrated.
