5 Reasons Why You Should Use Microsoft Dapr to Build Event-driven Microservices

Why Dapr excels at building distributed, loosely-coupled, event-driven Microservices

A visual guide to Dapr by Nitya Narasimhan

Microservices architectures are inherently distributed. Building Microservices always bring in the most challenging problems, such as resilient service invocation, distributed transactions, on-demand scaling, and exactly-once processing of messages.

Putting Microservices on Kubernetes doesn’t always solve these problems as Kubernetes doesn’t have an application logic. Frameworks like Spring Boot, Akka, and Quarkus offered great help when building distributed Microservices architectures. But they are tightly coupled to specific programming languages and often opinionated.

So developers remain searching for a portable runtime to build distributed, scalable, and event-driven Microservices.

Dapr — Distributed Application Runtime

Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless, and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.

Dapr is a Microsoft-incubated open-source project that hit its 1.0 milestone recently, signifying the project’s readiness for production use cases.

In my opinion, the following are the key reasons that Dapr outshines its competitors.

Dapr has pre-built components that solve a common set of problems.

Dapr codifies the best practices for building microservice applications into open, independent building blocks that solve everyday problems like state management, event handling, bindings to external systems, actors, etc. Each building block is entirely independent, and you can use one, some, or all of them in your application.

Dapr’s Building Blocks — Source

Dapr is portable

The building blocks mentioned above are available as a portable runtime. To be specific, Dapr runs as a sidecar, allowing your application to interact with it through standard HTTP and gRPC interfaces. That enables developers to build portable applications with the language and framework of their choice.

Dapr is platform-agnostic

Dapr is platform-agnostic, meaning you can run your applications locally, any Kubernetes cluster, and other hosting environments that Dapr is installed. That enables you to build microservice applications that can run on the cloud and edge.

The Dapr Ecosystem — Source

Building Event-driven Microservices with Dapr

A Typical Event-driven Architecture — Source

An event-driven system is composed of loosely-coupled, self-contained components that utilize events to communicate with each other. We can group these components and assign them the following roles based on how they interact with events.

  • Event producers — Who produces events?
  • Event consumers — Who consume events?
  • Event brokers — Who store events until they are consumed

Building an event-driven system means identifying what components will be playing the above roles and carefully modeling their asynchronous interactions using events.

While being portable and platform-agnostic, the following are the five reasons why you should consider Dapr to build your next event-driven system.

1. Compose your system with loosely-coupled, polyglot components

Dapr exposes its APIs as a sidecar architecture, either as a container or as a process, not requiring the application code to include any Dapr runtime code.

As shown in the figure below, the application code can communicate with Dapr APIs through standard interfaces such as HTTP and gRPC.

How building blocks expose a public API that is called from your code, using components to implement the building blocks’ capability.

That enables developers to pick their favorite programming language to build loosely-coupled, polyglot components that compose their event-driven systems while harnessing the power brings by Dapr.

For example, a Java-based order processing component can communicate with a NodeJS based Emailing component via common Dapr runtime.

2. Provides first-class support for producing and consuming events with its building blocks

The Dapr pub/sub building block provides a platform-agnostic API to send and receive messages with the at-least-once guarantee.

Publishing a message requires your service to make a network call to a Dapr pub/sub building block, exposed as a sidecar. This building block then makes calls into a Dapr pub/sub component that encapsulates a specific message broker product. To receive messages, Dapr subscribes to the Dapr pub/sub component on behalf of your service and delivers the messages to an endpoint when they arrive.

That approach makes your service implementation portable and less dependent on the underlying messaging infrastructure. Dapr currently supports a wide range of message brokers, including Redis, Kafka, NATS, and cloud services such as AWS SQS/SNS, Azure EventHubs, and Google Pub/sub. You can find the complete list here.

Dapr’s pub/sub architecture — Source

Moreover, you can trigger your service with events coming in from external systems or interface with external systems using Dapr bindings.

Bindings eliminate the need to write boilerplate code for connecting to and polling from messaging systems such as queues and message buses.

3. Easily harness the true power of Kubernetes.

Dapr is platform-agnostic and can run on any hosting environment, including local development machines, Kubernetes, and public clouds such as AWS, Azure, and GCP.

The ability to deploy your event-driven Microservices on Kubernetes adds extra benefits in on-demand scalability, high availability, and portability.

For Kubernetes, Dapr integrates with KEDA, an event-driven auto-scaler for Kubernetes. Many of Dapr’s pub/sub components seamlessly integrate with the scalers provided by KEDA. That allows you to offload the auto-scaling needs to the underlying hosting platform and focus on the business logic.

4. Dapr provides rich observability.

Event-driven applications are often criticized for not having visibility for the movements of events. But with the right set of observability tools, that can be solved.

Dapr provides a rich set of observability tools to monitor the ingress and egress routes for events in your architecture.

With tools like Zipkin, Dapr provides distributed tracing for your services. Dapr takes care of automatically sending trace data to Zipkin so that your services don’t have to. Dapr utilizes the OpenTelemetry standard to collect trace data so you can plug any compatible tracing tool of your choice later.

Dapr Provides OpenTelemetry compliant trace collection — Source

5. Dapr wraps events with the CloudEvents format

In an event-driven system, the ability to standardize the format of events is crucial. That enables heterogeneous systems to exchange events with a format that is understood commonly.

CloudEvents is a specification for describing events. It aims to ease interoperability. With the rise of event-driven architecture, it’s not surprising to see Cloud Events gaining popularity.

Dapr uses the CloudEvents 1.0 specification as its message format to enable message routing and provide additional context with each message. Any message sent by an application to a topic using Dapr is automatically “wrapped” in a Cloud Events envelope, using Content-Type header value for datacontenttype attribute.

Dapr implements the following Cloud Events fields:

  • id
  • source
  • specversion
  • type
  • datacontenttype (Optional)

The following example shows an XML content in CloudEvent v1.0 serialized as JSON:

"specversion" : "1.0",
"type" : "xml.message",
"source" : "https://example.com/message",
"subject" : "Test XML Message",
"id" : "id-1234-5678-9101",
"time" : "2020-09-23T06:23:21Z",
"datacontenttype" : "text/xml",
"data" : "<note><to>User1</to><from>user2</from><message>hi</message></note>"




EdU is a place where you can find quality content on event streaming, real-time analytics, and modern data architectures

Recommended from Medium

5 Time Estimation Techniques Engineers Are Not Using

Working with Finder tags on macOS

How to configure a pre-commit for a flutter application.

Working with Callables and Futures

MaxCompute Query Optimization with Calcite

Blow up your cloud using cloud-nuke

I made a game in C run in a web browser and so can you

We don’t have time to test

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dunith Dhanushka

Dunith Dhanushka

Editor of Event-driven Utopia(eventdrivenutopia.com). Technologist, Writer, Developer Advocate at StarTree. Event-driven Architecture, DataInMotion

More from Medium

Apache Kafka as cloud-native iPaaS Integration Middleware

In this blog, I am going to explain you how State store in Kafka streams is managed in…

Microservices: The Saga Pattern

Moving from embedded to remote workflow engines