Architecture Improvements Proposals

• 1: DAPR analysis

1 - DAPR analysis

DAPR analysis

Change motivation

The motivation behind adopting DAPR in our microservices platform is to enhance the development and operational efficiency of distributed applications.

DAPR provides a standardized way to handle common microservices challenges, such as service discovery, state management, and event-driven communication, which can significantly reduce the complexity of building and maintaining microservices architectures.

Summary

Currently, our platform relies on custom implementations for these functionalities, leading to increased development time and potential inconsistencies. By integrating DAPR, we aim to streamline our microservices development process, improve scalability, and enhance the overall reliability of our applications.

Moreover, DAPR would minimize the complexity of new services deployment leaning on features such as automatic service discovery and built-in support for various state stores and message brokers. This will allow our development teams to focus more on business logic rather than infrastructure concerns, ultimately accelerating our time to market and improving the maintainability of our codebase.

Date	Proposal leadership team
June 2025	Aura Engineering team

Advantages of using DAPR in a microservices platform

1. Complexity abstraction: DAPR abstracts the complexity of communication between microservices, allowing developers to focus on business logic.
2. Portability: Being language and platform agnostic, DAPR can run in any environment, whether in the cloud or on-premises servers.
3. Scalability: It facilitates horizontal scalability of services, enabling applications to grow as needed.
4. Interoperability: DAPR supports multiple programming languages and protocols, making it easier to integrate heterogeneous services.
5. Security: It provides built-in mechanisms for authentication and authorization between services.
6. Rich ecosystem: Includes building blocks such as service invocation, state management, event publishing/subscription, and more.

DAPR architecture

DAPR’s architecture is designed to provide a flexible and modular framework for building distributed applications.

It consists of a control plane and a data plane, where the control plane manages configurations and policies, while the data plane handles the actual service interactions.

Architecture diagram

Below is a visual representation of DAPR’s architecture:

graph TD
    classDef graphTitle font-size: 20px, font-weight: bold, fill:#f0f0f0, stroke:#333, stroke-width:2px;
    subgraph Control Plane
        A[Configuration Management]
        B[Policy Enforcement]
        C[Monitoring and Observability]
        D[Service Discovery]
        E[Scaling and Resilience]
    end
        F[Sidecars]
    subgraph Data Plane
        G[Service Invocation]
        H[State Management]
        I[Publish and Subscribe]
        J[Bindings]
    end

    A --> F
    B --> F
    C --> F
    D --> F
    E --> F
    F --> G
    F --> H
    F --> I
    F --> J

This diagram illustrates how the control plane and data plane interact to enable DAPR’s functionalities, ensuring seamless communication and management of distributed applications.

Components of DAPR Architecture

DAPR’s architecture is composed of several key components that work together to enable microservices communication and management:

1. Sidecars: These are lightweight containers that run alongside each microservice, providing DAPR’s functionalities such as service invocation, state management, and event handling.
2. Building blocks: DAPR offers modular building blocks for common tasks, including:
   • Service invocation: Enables direct communication between services.
   • State management: Provides distributed state storage.
   • Publish and subscribe: Facilitates event-driven communication.
   • Bindings: Connects services to external systems like databases and message queues.
3. Control plane: Manages the configuration, security, and monitoring of DAPR instances across the platform.
4. Data plane: Handles the actual runtime operations, including service-to-service communication and data processing.
5. APIs: DAPR exposes APIs that developers can use to interact with its features programmatically.

These components collectively simplify the development and operation of distributed applications, ensuring scalability, portability, and ease of integration.

Sidecars in DAPR

In the context of DAPR, a “sidecar” is a container that runs alongside each microservice on the same machine or pod. This container acts as an intermediary that provides DAPR capabilities to the microservice. Sidecars enable:

• Service communication: Facilitate service invocation and message transmission.
• State management: Provide distributed state storage.
• Event publishing and subscription: Allow services to communicate through events.
• Integration with external resources: Simplify connections to databases, message queues, and other external services.

Sequence diagram: communication flows in DAPR

Below is a simplified sequence diagram illustrating how communication works in DAPR:

sequenceDiagram
    participant ServiceA
    participant DAPR-SidecarA
    participant DAPR-SidecarB
    participant ServiceB

    ServiceA->>DAPR-SidecarA: Invoke ServiceB
    DAPR-SidecarA->>DAPR-SidecarB: Forward request
    DAPR-SidecarB->>ServiceB: Deliver request
    ServiceB->>DAPR-SidecarB: Respond
    DAPR-SidecarB->>DAPR-SidecarA: Forward response
    DAPR-SidecarA->>ServiceA: Deliver response

This diagram demonstrates how DAPR sidecars facilitate communication between services, ensuring seamless interaction and abstraction of complexity.

Events in DAPR

DAPR uses a publish-and-subscribe model to manage events. This model allows services to communicate asynchronously and decoupled. Events in DAPR have the following characteristics:

• Decoupling: Event producers and consumers do not need to know each other.
• Scalability: The system can handle large volumes of events without affecting performance.
• Compatibility with multiple brokers: DAPR supports various messaging systems such as Kafka, RabbitMQ, Azure Service Bus, among others.
• Ease of use: Developers can define their subscriptions and publications easily through configurations.

State management with Redis

DAPR supports state management by providing a distributed state store that can be backed by various storage solutions, including Redis. Redis is a popular in-memory data structure store that is often used for caching, session management, and real-time analytics.

How DAPR uses Redis for state management

1. Configuration: Developers can configure DAPR to use Redis as the state store by specifying Redis connection details in the DAPR configuration file.
2. Key-value storage: Redis allows DAPR to store and retrieve state in a key-value format, making it simple and efficient.
3. Persistence: While Redis is primarily an in-memory store, it can persist data to disk for durability.
4. Scalability: Redis can be scaled horizontally to handle large amounts of state data across distributed systems.

Example use case

Imagine a shopping cart application where user session data needs to be stored temporarily. DAPR can use Redis to store the cart state, ensuring fast access and updates:

• Write state: When a user adds an item to the cart, DAPR writes the state to Redis.
• Read state: When the user views the cart, DAPR retrieves the state from Redis.
• Delete state: When the user checks out, DAPR deletes the state from Redis.

By leveraging Redis, DAPR ensures efficient and reliable state management for distributed applications.

Control plane in DAPR

The control plane in DAPR is responsible for managing the overall configuration, security, and monitoring of the runtime environment. It ensures that the distributed application operates smoothly and adheres to defined policies.

Key responsibilities of the control plane

1. Configuration management: The control plane handles the configuration of DAPR components, including sidecars, building blocks, and integrations with external systems.
2. Policy enforcement: It ensures that security policies, resource limits, and other operational rules are applied consistently across the platform.
3. Monitoring and observability: The control plane provides tools and interfaces for monitoring the health and performance of DAPR instances and microservices.
4. Service discovery: It facilitates the discovery of services within the distributed application, enabling seamless communication between microservices.
5. Scaling and resilience: The control plane supports scaling operations and ensures resilience by managing failover and recovery mechanisms.

By centralizing these responsibilities, the control plane simplifies the management of distributed applications and enhances their reliability and security.

Cost implications of DAPR

When adopting DAPR, it is important to consider the cost implications of its components:

Sidecars

• Lightweight and efficient: DAPR sidecars are designed to be lightweight, consuming minimal resources. They run alongside microservices and provide essential functionalities without adding significant overhead.
• Almost free: The resource usage of sidecars is negligible in most scenarios, making them an economical choice for enabling DAPR features.

Control plane

• Resource intensive: Unlike sidecars, the control plane requires dedicated resources to manage configurations, policies, monitoring, and scaling operations.
• Operational costs: The control plane introduces additional costs related to infrastructure, maintenance, and monitoring tools.
• Scalability considerations: As the platform scales, the control plane may need to be expanded to handle increased workloads, further adding to the costs. This would mean deploying new nodes in the environment, that would also mean extra charges.

The overall cost of the control plane is based on the number of nodes needed to support it. As an estimation, it would need adding 1 extra node to the current environment in the case of the production environment in Spain and 2 extra nodes in the case of the production environment in Brazil. Assuming the cost of each node of the family D4as v4 is around 150 € per month (this is the raw price shown publicly in Microsoft pricing page, without any discounts and for west europe region), the monthly cost for the control plane would be approximately:

• Spain: 1 nodes * 150 € = 150 € per month
• Brazil: 2 nodes * 150 € = 300 € per month

Prices in June 2025 ¹

Conclusion

DAPR is a powerful tool for building distributed applications based on microservices. Its focus on simplicity, portability, and scalability makes it an ideal choice for developers looking to optimize their microservices platforms. Sidecars and the event model are key components that facilitate communication and integration between services, making applications more robust and easier to maintain.