Dapr + Score: Mixing the Perfect Cocktail for an Enhanced Develope... Mathieu Benoit & Kendall Roden

Dapr + Score: Mixing the Perfect Cocktail for an Enhanced Developer Experience

Speakers: Mathieu Benoit, Cloud Native Ambassador, Score Maintainer, Customer Success Engineer at Humanitec; Kendall Roden, Product Manager at Diagrid

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=-fGztPUuD8k

Overview

This talk, "Dapr + Score: Mixing the Perfect Cocktail for an Enhanced Developer Experience," delivered by Kendall Roden and Mathieu Benoit at KubeCon EU, delves into how the Distributed Application Runtime (Dapr) and the Score specification can be combined to significantly enhance developer productivity and streamline the deployment of cloud-native applications. The core problem addressed is the increasing cognitive load placed on developers, who are often forced to deal with complex infrastructure concerns, boilerplate code, and environment-specific configurations that detract from their primary goal of delivering business value.

Kendall Roden, representing the application developer perspective, highlights the need for abstractions that allow developers to focus on business logic without rewriting common patterns or implementing intricate resiliency logic. Mathieu Benoit, speaking as a platform engineer, outlines the mandate to build robust internal developer platforms (IDPs) that standardize governance, security, and automation, ultimately enabling developers. The talk demonstrates how Dapr provides a standardized runtime interface, while Score offers a standardized deployment interface, creating a powerful synergy that bridges the gap between local development and production environments.

The importance of this talk lies in its practical approach to a pervasive challenge in modern software development. By showcasing how Dapr abstracts away infrastructure complexities at runtime and how Score abstracts deployment configurations, the speakers present a compelling solution for organizations aiming to boost developer efficiency, reduce operational friction, and maintain consistent application deployments across diverse environments. This synergy empowers both developers and platform teams, fostering better collaboration and accelerating the delivery of innovative applications.

Background

▶ Watch: Welcome, speaker roles, and developer friction (0:00)

The modern cloud-native landscape presents a paradox: while offering immense flexibility and power, it also introduces significant complexity for developers. As applications become increasingly distributed, developers find themselves grappling with a multitude of concerns that traditionally fell under operations or infrastructure teams. This "bleeding" of infrastructure concerns into the developer's inner loop leads to reduced productivity, as engineers spend valuable time implementing common patterns like service invocation, state management, and publish/subscribe mechanisms, or configuring application resilience and observability. Each new dependency, library, or deployment target adds to this burden, creating a tightly coupled application that is difficult to maintain and standardize.

Platform engineering has emerged as a critical discipline to combat this complexity. Platform teams are tasked with building internal developer platforms (IDPs) that abstract away underlying infrastructure, providing developers with a streamlined, self-service experience. The goal is to standardize templates, enforce governance and security policies, and automate deployment processes. The CNCF Platform Working Group has released whitepapers and frameworks, such as those focusing on the building blocks of a platform, treating the platform as a product, and maturity models, to guide organizations in this endeavor. A key focus area for these platforms is the interface between the developer and the platform – how developers consume platform capabilities and how platform engineers expose them.

Prior to solutions like Dapr and Score, developers would often have to write explicit client code for specific databases (e.g., Redis client, Postgres client), message brokers, or cloud services. This meant code changes were required when swapping infrastructure providers, and developers needed deep knowledge of each service's API. For deployment, developers might manually craft Dockerfiles, Docker Compose configurations, or intricate Kubernetes manifests, often leading to "it works on my machine" syndrome and inconsistencies across development, staging, and production environments. Dapr and Score were created to address these specific pain points by introducing layers of abstraction and standardization, aiming to reduce developer cognitive load and enable platform teams to deliver a more opinionated and efficient developer experience.

Key Findings

▶ Watch: Platform engineer's mandate and IDP goals (2:00)

The central finding of this talk is the profound synergy achieved by combining Dapr and Score, which together create a comprehensive solution for abstracting infrastructure and deployment complexities throughout the entire application lifecycle. This combination effectively tackles the challenge of developer cognitive load and empowers platform teams to build robust, standardized internal developer platforms.

1. Dapr for Runtime Abstraction: Dapr provides a set of standard interfaces through its APIs and SDKs, enabling developers to consume underlying platform capabilities without direct infrastructure coupling. Key functionalities like service invocation, state management, publish/subscribe (PubSub), and stateful workflows are exposed through a consistent API surface, regardless of the underlying technology. The sidecar model allows Dapr to run alongside application code, intercepting and routing requests to configured Dapr components. This means developers can write code that "saves state" or "publishes an event" without needing to know if the backend is Redis, Azure Cosmos DB, or RabbitMQ.
2. Score for Deployment Abstraction: The Score specification allows developers to declare their application's intent and resource dependencies in a platform-agnostic and environment-agnostic YAML file. This specification simply states what the application needs (e.g., "I need a state store," "I need a pubsub broker") without specifying how those resources will be provisioned or configured. This shifts the responsibility of concrete implementation to the platform team.
3. Seamless Inner Loop to Production Workflow: The integration of Dapr and Score facilitates a smooth transition from local development to production. Developers can use Dapr locally with default components (e.g., a local Redis instance via dapr init). When it's time to deploy, Score takes the developer's simple declaration and, using Score implementations provided by platform engineers, generates the necessary Docker Compose files for local containerized testing or complex Kubernetes manifests for staging and production environments. This eliminates the need for developers to manually create and maintain these intricate deployment configurations.
4. Empowering Platform Engineers: Dapr components and Score implementations serve as powerful tools for platform engineers. They can author "recipes" that define how Dapr APIs map to specific infrastructure services (e.g., Redis, Postgres, RabbitMQ, Azure, GCP) and how Score specifications translate into concrete deployment artifacts with standardized labels, annotations, and security configurations. This enables platform teams to enforce governance, security, and best practices across all deployments, ensuring consistency and auditability.
5. Reduced Developer Cognitive Load: By abstracting both runtime interactions with infrastructure and the complexities of deployment, Dapr and Score significantly reduce the mental burden on developers. They can focus on writing business logic, knowing that the platform will handle the underlying infrastructure and deployment details, promoting faster innovation and higher productivity. The ability to swap infrastructure backends (e.g., Redis to Postgres/RabbitMQ) without any changes to application code or Score files is a testament to this powerful abstraction.

Technical Deep Dive

▶ Watch: Dapr and Score: standard interfaces for dev and platform (4:00)

The talk provides a detailed exploration of Dapr and Score's technical underpinnings, illustrating how they achieve their respective abstractions and how they integrate to create a cohesive developer experience.

Dapr: The Distributed Application Runtime

Dapr is a graduated CNCF project designed to make it easier to build resilient, portable, and scalable microservices applications. Its core architecture revolves around the sidecar model. When deployed, Dapr runs as a separate process (a sidecar) alongside each application instance, typically injected into Kubernetes pods or run as a local process. This sidecar exposes a set of standard APIs that applications can interact with via HTTP or gRPC, abstracting away the complexities of various infrastructure concerns.

Key Dapr APIs demonstrated include:

• Service Invocation: Enables reliable communication between microservices with built-in features like MTLS (mutual TLS) for secure communication, retries, and circuit breakers, similar to a service mesh.
• State Management: Provides a consistent API for storing and retrieving key-value pairs, abstracting the underlying state store. Developers simply call Dapr client.SaveState() or GetState() with a state store name.
• Publish/Subscribe (PubSub): Allows applications to publish events to and subscribe from topics without direct knowledge of the message broker. Dapr supports over 20-25 different PubSub brokers, all consumed through a single API.
• Stateful Workflows: Enables the orchestration of long-running, stateful business processes. Dapr workflow activities handle the actual computation, while the workflow definition structures the execution flow. The Dapr workflow SDK facilitates this, establishing a continuous gRPC stream between the application and the Dapr sidecar to manage work items.

The abstraction provided by Dapr is powered by Dapr components. These are configuration files (typically YAML) that platform engineers define to map a generic Dapr API call (e.g., "save state") to a concrete infrastructure service (e.g., a Redis instance, an Azure Cosmos DB database, a PostgreSQL database). These components are loaded at runtime by the Dapr sidecars and can be scoped and governed by platform teams. For example, a state store component named "order-store" could be configured to use Redis locally, but Postgres in production, without any change to the application code.

For local development, Dapr offers a streamlined experience:

• dapr init: Installs Dapr onto the local machine, leveraging Docker to provide essential control plane services. This includes an actor placement service (for distributed actors), a scheduler (for stateful workflows), Zipkin for distributed tracing (emitting OpenTelemetry traces), and a default Redis instance for state management and PubSub.
• dapr run: Launches the application alongside a Dapr sidecar process (not containerized locally, but a separate process) that acts as the intermediary layer, enabling the application to use Dapr APIs. The command takes a YAML manifest to configure the application and Dapr sidecar, including app ID and ports.

Kendall demonstrated an order processing workflow:

1. Inventory Management: An API call to restock inventory uses the Dapr state API to save a key-value pair, confirmed by inspecting the local Redis instance via docker ps.
2. Workflow Initiation: Submitting an order triggers a Dapr workflow via the Dapr workflow SDK.
3. Workflow Activities: The workflow coordinates calls to reserve inventory (using Dapr state API), processes payment, and handles shipping. A notify activity publishes messages to a UI using the Dapr PubSub API, demonstrating how the Dapr client can publish events to a configured pubsub component (e.g., the default Redis). Subscriptions are also declarative, referencing the PubSub component.
4. Service Invocation: The workflow invokes other microservices (e.g., payment service, shipping service) using Dapr's invocation API, which provides MTLS out-of-the-box.

Score Specification and Implementations

While Dapr handles the runtime abstraction, Score addresses the deployment abstraction. Score introduces two core concepts:

1. Score Specification: This is a platform-agnostic, environment-agnostic YAML file authored by developers. It describes the intent to deploy a workload and its dependencies. Developers declare what their application needs (e.g., "I need a Dapr state store," "I need to subscribe to a pubsub topic") without specifying the concrete implementation details. This succinct file removes the burden of understanding complex infrastructure or platform-specific configurations from the developer.
2. Score Implementations: These are concrete "recipes" provided by platform engineers. They translate a generic Score specification into environment-specific deployment artifacts for target runtimes like Docker Compose, Kubernetes, Fly.io, or Humanitec. Platform engineers can author implementations for various infrastructure services (e.g., Postgres, Redis, RabbitMQ), whether they are local Docker containers, cloud services (Azure, GCP), or on-premises solutions. This provides standardization at the platform level.

Mathieu demonstrated how Score simplifies the journey from local development to production:

• Developer's Perspective: Developers write simple Score files for each workload (e.g., notification and inventory), declaring resources like dapr.io/StateStore and dapr.io/PubSub and their associated components.
• Local Containerized Deployment (Docker Compose): Using the Score Compose tool, platform engineers provide an implementation that, when run with score-compose generate <score-file.yaml>, automatically generates a comprehensive Docker Compose file. This generated file includes all necessary containers (application, Dapr sidecars, Dapr control plane services, Redis instances for state and PubSub) and their interconnections. Developers then simply run docker compose up to test their application locally in a containerized environment, abstracted from the complexity of authoring the Docker Compose file themselves.
• Kubernetes Deployment: For staging or production, platform engineers provide a Score Kubernetes implementation. Running score-kubernetes generate <score-file.yaml> generates a potentially 600-line Kubernetes manifest file with all the necessary deployments, services, Dapr annotations, labels, and configurations. This manifest is then deployed to the Kubernetes cluster. Critically, the demo showed how the platform team could swap out the underlying components – from local Redis to Postgres for state and RabbitMQ for PubSub – in the Kubernetes environment without any changes to the developer's application code or Score file. This highlights the power of abstraction and standardization.

The technical deep dive underscores that Dapr handles the runtime integration with infrastructure via its sidecar and components, while Score handles the deployment integration by generating environment-specific manifests from a generic declaration. Together, they create a powerful and flexible system for managing microservices applications.

Demo / Proof of Concept

▶ Watch: Introduction to Dapr: a graduated CNCF project (5:30)

The talk featured a comprehensive two-part demonstration, seamlessly transitioning from local Dapr development to multi-environment deployments using Score.

Part 1: Dapr Local Development (Kendall Roden)

Kendall began by illustrating the inner loop development experience with Dapr. Due to Wi-Fi concerns, dapr init was pre-executed, but she confirmed its effect by showing docker ps output, revealing the running Dapr control plane services: dapr_placement, dapr_scheduler, and a dapr_redis instance, along with Zipkin for tracing.

The core of this demo involved an order processing workflow. Kendall launched the application using dapr run, which uses a YAML manifest to define the application and its Dapr sidecar configuration. The console output clearly distinguished between the application's logs (blue) and the Dapr sidecar's logs (white), indicating the sidecar was ready.

To demonstrate state management, she first queried the current inventory using the Dapr state API, confirming it was empty. She then made an API call to restock inventory, which internally leveraged the Dapr API to save a key-value pair. A quick refresh of the Redis CLI (running in Docker as the default Dapr state store) showed the inventory items successfully stored, proving the abstraction as the application code itself contained no explicit Redis client calls.

Next, an order was submitted through a UI. This action initiated a Dapr workflow via the Dapr workflow SDK. A notification service, subscribing to workflow activities, displayed real-time messages (e.g., "workflow started," "payment processed") in the UI. This showcased Dapr's PubSub API in action, where the application published events to a pubsub component (the default Redis), and the notification service subscribed to these events.

A quick code tour further solidified these concepts:

• The application imported Dapr clients for PubSub, service invocation, and state management, as well as the Dapr workflow SDK.
• It highlighted the gRPC stream established between the application and the Dapr sidecar for workflow management.
• The notify activity within the workflow used Dapr client.PublishEvent() to send messages, emphasizing that the code remains generic, irrespective of the underlying message broker (configured via a Dapr component).
• The inventory activity used the Dapr state API to reserve inventory, again demonstrating infrastructure abstraction.
• A Dapr pubsub component YAML file (pubsub.yaml) was shown, explicitly configuring the pubsub component to use Redis. A declarative subscription YAML (subscription.yaml) referenced this component, demonstrating how services subscribe to messages.
• Finally, the use of Dapr's service invocation API was shown for calling other microservices (e.g., an inventory service's reserve endpoint), highlighting built-in features like MTLS.

Part 2: Graduating Environments with Score (Mathieu Benoit)

Mathieu picked up from Kendall's demo, focusing on how Score enables seamless deployment across different environments. He emphasized that the goal was to take the same application and its same Score files and deploy them to Docker Compose and then to Kubernetes, all while swapping out backend infrastructure without changing developer code.

First, he showcased the Score files for the notification and inventory workloads. These YAML files concisely described the workload's metadata (e.g., port) and, crucially, declared its resource dependencies: a dapr.io/PubSub component for the notification service and a dapr.io/StateStore for the inventory service. The developer simply states the need, not the implementation.

Next, for the local containerized environment, Mathieu used the Score Compose tool. Executing score-compose generate against the Score files, it automatically generated a comprehensive, multi-hundred-line Docker Compose file. This complex file included all necessary Dapr sidecars, control plane components, and two Redis instances (one specifically configured for state, one for PubSub) – all abstracted from the developer. Running docker compose up brought up the entire application stack locally, and Mathieu demonstrated generating traffic to the notification page, confirming the application functioned correctly with its Dapr-powered Redis backends.

The final and most impactful part of the demo involved deploying to Kubernetes. Using the Score Kubernetes tool, score-kubernetes generate was executed, which produced a massive, 600-line Kubernetes manifest file. This manifest included all Kubernetes resources (Deployments, Services, Dapr annotations, etc.) necessary to deploy the application. Crucially, in this Kubernetes environment, the platform engineers had configured the Score implementation to use Postgres for the state store and RabbitMQ for the PubSub broker, instead of Redis. Mathieu deployed this manifest, generated traffic, and showed the application running successfully on Kubernetes, now powered by Postgres and RabbitMQ. This vividly demonstrated the core value proposition: the developer's code and Score specification remained unchanged, yet the underlying infrastructure components were seamlessly swapped, showcasing the power of Dapr components and Score implementations in abstracting environment-specific details.

The demo conclusively proved that Dapr and Score, when used together, create an elegant solution for bridging the gap between developer intent and complex infrastructure realities, significantly enhancing developer productivity and platform consistency.

Defensive Implications

▶ Watch: Dapr's sidecar model and standard APIs explained (6:00)

While the talk primarily focuses on developer productivity and platform engineering, the architectural patterns introduced by Dapr and Score have significant positive implications for an organization's security posture. By centralizing control and standardizing interfaces, these tools inherently build a more defensible application landscape.

1. Standardization and Vetted Configurations: Dapr components and Score implementations are defined by platform engineers, not individual developers. This means that security best practices, hardened configurations, and vetted infrastructure choices (e.g., specific versions of Redis, secure Postgres setups, RabbitMQ with TLS) can be enforced consistently across all applications. Instead of each developer configuring their own database connection strings or message broker settings, these are centrally managed and distributed via the platform. This drastically reduces the risk of misconfigurations, which are a common source of security vulnerabilities.
2. Reduced Attack Surface through Abstraction: Developers interact with Dapr's generic APIs (e.g., SaveState, PublishEvent) rather than directly with raw infrastructure APIs or client libraries. This abstraction layer means that developers are less likely to accidentally expose sensitive infrastructure details or misconfigure security-sensitive settings. Dapr's sidecar acts as a secure intermediary, handling network communication, authentication, and authorization, effectively reducing the application's direct attack surface.
3. Built-in Security Features: Dapr itself incorporates several security features out-of-the-box. For instance, service invocation between microservices automatically leverages MTLS (mutual TLS), encrypting communication and verifying identities without requiring developers to implement complex cryptographic logic. This provides a baseline level of secure communication across the service mesh that would otherwise be a significant development and operational burden.
4. Centralized Policy Enforcement: Platform teams can use Dapr components to enforce access control lists (ACLs) for service invocation or define fine-grained authorization policies for state stores and PubSub topics. Similarly, Score implementations can inject security-related Kubernetes annotations or labels, ensuring that deployments adhere to organizational security policies, such as network policies, Pod Security Standards, or specific resource quotas. This allows for a "shift-left" of security, embedding it into the platform's foundation rather than relying on individual application-level implementations.
5. Improved Auditability and Observability: With Dapr, OpenTelemetry traces are automatically emitted (e.g., via Zipkin in local development). In a production environment, this standardized tracing provides a clear, consistent view of application interactions and data flows, which is invaluable for security monitoring, incident response, and forensic analysis. Standardized deployments via Score also ensure consistent logging agents and security tooling are deployed alongside applications.
6. Supply Chain Security: By centralizing the definition of infrastructure and deployment configurations, platform teams can better manage the software supply chain. They can ensure that Dapr components point to approved, scanned container images for infrastructure services and that Score implementations generate manifests referencing trusted base images and security-hardened configurations. This reduces the risk associated with unvetted third-party dependencies.
7. Simplified Configuration Management: The generation of complex Kubernetes manifests by Score Kubernetes, abstracted from the developer, significantly reduces the potential for human error in security-sensitive configurations. Incorrect indentation, missing labels, or misconfigured network policies in manually crafted manifests can open critical vulnerabilities. Score automates this, ensuring consistency and adherence to predefined secure patterns.

In essence, Dapr and Score empower platform teams to build a secure-by-design platform where security is an inherent part of the infrastructure and deployment process, rather than an afterthought for each application team. This not only enhances security but also frees developers to innovate without being bogged down by security implementation details.

Key Takeaways

• Dapr abstracts common microservice patterns: Dapr provides a set of standard APIs (service invocation, state management, PubSub, workflows) and a sidecar model that abstracts away underlying infrastructure complexities, allowing developers to focus on business logic.
• Score standardizes workload declarations: The Score specification offers a platform-agnostic, environment-agnostic YAML file for developers to declare their application's resource dependencies and deployment intent, removing the need for developers to understand complex infrastructure configurations.
• Seamless inner loop to production workflow: The combination of Dapr and Score streamlines the entire development lifecycle, enabling developers to move from local development with Dapr's default components to containerized testing with Score Compose and finally to production deployments on Kubernetes with Score Kubernetes, all while maintaining consistent developer experience.
• Empowers platform engineers for standardization: Platform teams leverage Dapr components and Score implementations to define and enforce standardized infrastructure choices, security policies, and deployment configurations, promoting consistency, governance, and auditability across all applications.
• Reduces developer cognitive load and boosts productivity: By abstracting both runtime infrastructure interactions and deployment complexities, Dapr and Score significantly reduce the mental burden on developers, allowing them to deliver business value faster and with greater focus.
• Enables flexible infrastructure swapping without code changes: The layered abstraction allows platform engineers to seamlessly swap underlying infrastructure backends (e.g., from Redis to Postgres for state and RabbitMQ for PubSub) across different environments without requiring any modifications to the application code or the developer's Score specification.

About the Speaker(s)

Kendall Roden is a Product Manager at Diagrid. She has a rich background in cloud-native technologies, having previously worked at Microsoft. For the past four years, Kendall has been deeply involved with the open-source Dapr project, contributing to its development and adoption within the community. Her expertise lies in enabling developers to build resilient and scalable microservices applications by abstracting infrastructure complexities.

Mathieu Benoit serves as a Cloud Native Ambassador and is a maintainer of the Score project. He is also a Customer Success Engineer at Humanitec. Mathieu's work focuses on the intersection of developer experience and platform engineering, helping organizations build effective internal developer platforms. His involvement with the Score project highlights his commitment to standardizing the way developers declare their workload dependencies, fostering greater collaboration and automation in cloud-native environments.