Close

Dapr versus Service Mesh

Modern applications are typically architected as distributed collections of microservices. As the collection of microservices grows in size and complexity, it can become harder to understand and route message traffic between services.

Dapr (dapr.io) stands for Distributed Application Runtime for microservices. It’s an open source project that provides building blocks that make it easier for developers to build applications as microservices. The building blocks solve common challenges, such as recovering state after failures, managing secrets or discovering and securely calling other microservices. You can incrementally use one or more of the Dapr building blocks. Dapr provides APIs for these building blocks. Dapr also provides extensive security and telemetry (tracing, metrics, logs) by default.

When running Kubernetes, Dapr is installed on a separate sidecar container within your pod. That means, Dapr scales automatically with your microservice. By letting Dapr’s sidecar take care of the complex challenges such as service discovery, message broker integration, encryption, observability, and secret management, you can focus on business logic and keep your code simple.

A service mesh is a dedicated infrastructure layer that transparently adds capabilities to your application without adding them to your own code.
In other words, a service mesh moves certain operational capabilities from the application layer to the infrastructure layer. This eases the strain on development teams.

Istio is an example of a service mesh and offers the following capabilities:

  • Traffic management. Routing traffic, both within a single cluster and across clusters. Istio’s traffic routing rules let you easily control the flow of traffic and API calls between services. Istio simplifies configuration of service-level properties like circuit breakers, timeouts, and retries, and makes it easy to set up important tasks like A/B testing, canary deployments, and staged rollouts with percentage-based traffic splits. Traffic management also includes load balancing.
  • Observability. Istio generates detailed telemetry/metrics for all communications within a service mesh, empowering operators to troubleshoot, maintain, and optimize their applications. Istio’s telemetry includes detailed metrics, distributed traces, and full access logs.
  • Security. Microservices have particular security needs, including protection against man-in-the-middle attacks, flexible access controls, auditing tools, and mutual TLS. It provides strong identity, powerful policy, transparent TLS encryption, and authentication, authorization and audit (AAA) tools to protect your services and data.
  • Policy Enforcement. Such as rate limiting.

While Dapr and service meshes do offer some overlapping capabilities, Dapr is not a service mesh. Service mesh focuses on networking concerns (infrastructure-centric). Dapr focuses on development concerns (developer-centric).

Some common capabilities that Dapr shares with service meshes include:

  • Secure service-to-service communication with mTLS encryption
  • Service-to-service metric collection
  • Service-to-service distributed tracing
  • Resiliency through retries

Differences:

  • Dapr does not provide capabilities for traffic behavior such as routing or traffic splitting.
  • Traffic routing is often addressed with ingress proxies to an application and does not have to use a service mesh.
  • When it comes to observability (tracing and metrics), service meshes operate at the network level and trace the network calls between services.
  • Dapr provides observability for both service-to-service invocation and pub/sub and is therefre more extensive.