From de8be0cc2666a58131e8298af785494ff87f42f2 Mon Sep 17 00:00:00 2001 From: rkoster Date: Mon, 10 Aug 2026 11:27:31 +0200 Subject: [PATCH] Add research note: Dapr --- research/dapr.md | 81 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 research/dapr.md diff --git a/research/dapr.md b/research/dapr.md new file mode 100644 index 0000000..dec5830 --- /dev/null +++ b/research/dapr.md @@ -0,0 +1,81 @@ +--- +title: "Dapr — Distributed Application Runtime" +author: Ruben Koster (@rkoster) +date: 2026-08-10 +tags: [runtime-lifecycle, inter-agent-comms, identity, orchestration, ecosystem-survey] +cf_areas: [] +status: draft +sources: + - https://dapr.io/ + - https://docs.dapr.io/overview/ + - https://docs.dapr.io/developing-applications/building-blocks/ + - https://docs.dapr.io/concepts/dapr-services/sidecar/ + - https://docs.dapr.io/operations/security/mtls/ + - https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/ + - https://docs.dapr.io/developing-ai/dapr-agents/dapr-agents-introduction/ +--- + +## Summary + +Dapr (Distributed Application Runtime) is a [CNCF graduated project](https://www.cncf.io/projects) that +provides a set of language-agnostic HTTP/gRPC APIs — "building blocks" — for common distributed-systems +concerns (service invocation, pub/sub, state, actors, workflow, bindings, secrets), exposed via a sidecar +process rather than an in-process SDK. It decouples application code from infrastructure through pluggable +components, and is increasingly marketed by its maintainers not just as a microservices runtime but as a +"durable execution engine for workflows and AI agents" — i.e. infrastructure for building resilient, +crash-recoverable agentic systems. + +## Key findings + +- **Sidecar, not a library**: the Dapr APIs run in a separate process (`daprd`) alongside the app and are + called over local HTTP or gRPC — the app never links Dapr runtime code directly. On Kubernetes, + `dapr-sidecar-injector` watches for the `dapr.io/enabled` pod annotation and injects `daprd` as a + container in the same pod (or as a [native Kubernetes 1.28+ sidecar container](https://docs.dapr.io/concepts/dapr-services/sidecar/)); in self-hosted mode the CLI (`dapr run`) launches `daprd` next to the app binary. +- **Eleven building-block APIs**: [service invocation](https://docs.dapr.io/developing-applications/building-blocks/service-invocation/), [pub/sub](https://docs.dapr.io/developing-applications/building-blocks/pubsub/), [state management](https://docs.dapr.io/developing-applications/building-blocks/state-management/), + [bindings](https://docs.dapr.io/developing-applications/building-blocks/bindings/), [actors](https://docs.dapr.io/developing-applications/building-blocks/actors/), [workflow](https://docs.dapr.io/developing-applications/building-blocks/workflow/), [secrets](https://docs.dapr.io/developing-applications/building-blocks/secrets/), + [configuration](https://docs.dapr.io/developing-applications/building-blocks/configuration/), [distributed lock](https://docs.dapr.io/developing-applications/building-blocks/distributed-lock/), [cryptography](https://docs.dapr.io/developing-applications/building-blocks/cryptography/), and [jobs](https://docs.dapr.io/developing-applications/building-blocks/jobs/) + — each is independently adoptable, so an app can use only pub/sub without pulling in the rest. +- **Pluggable components**: state stores, pub/sub brokers, and bindings are backed by a component + abstraction — e.g. the state store can be Redis, PostgreSQL, Azure Cosmos DB, DynamoDB, etc., + swapped via YAML config with no application code change, similar in spirit to a service-broker/binding + model. +- **Control plane and mTLS**: a small set of control-plane services — `dapr-operator` (component + notifications), `dapr-placement-server` (actor placement), `dapr-sentry` (certificate authority), and + `dapr-scheduler-server` (jobs/reminders scheduling) — support the data-plane sidecars. `dapr-sentry` acts + as a CA issuing short-lived workload certificates (Ed25519 as of Dapr 1.18) for mutual TLS between + sidecars, and explicitly provides workload identity via [SPIFFE](https://spiffe.io/). +- **Virtual actors**: Dapr's actor runtime implements the [virtual actor pattern](https://docs.dapr.io/developing-applications/building-blocks/actors/actors-overview/) — single-threaded, + turn-based execution per actor instance, with the runtime handling activation/deactivation, state, and + timers/reminders. Actors are garbage-collected when idle, giving a lightweight per-entity concurrency + model without the app managing locks itself. +- **Workflow as a durable execution engine**: the [workflow building block](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/) provides a code-first + orchestration engine (activities, child workflows, multi-app workflows) where every step is persisted so + execution can resume from exactly where it left off after a crash or restart; execution histories can + optionally be [cryptographically signed and verified](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-history-signing/) for tamper-evidence. +- **Explicit agentic positioning**: Dapr's own docs now describe it primarily as "the durable execution + engine for workflows and AI agents." [Dapr Agents](https://docs.dapr.io/developing-ai/dapr-agents/dapr-agents-introduction/) (a separate framework, own note pending) builds on + this by giving each agent a cryptographic identity and backing agent/tool-call loops with the same + durable workflow engine, so an agent can crash and resume mid-task without losing progress — this is + covered in more depth in `research/dapr-agents.md`. + +## CF relevance + +Dapr's sidecar-plus-pluggable-component model is conceptually close to CF's app + service-binding pattern, +but pushed further: instead of just wiring credentials to an app, Dapr standardizes the *API surface* an +app talks to (pub/sub, state, secrets) and lets the operator swap the backing implementation transparently. +The mTLS-via-CA-issued-workload-certs-with-SPIFFE-identity model is also a natural point of comparison with +however CF chooses to do inter-app/inter-agent identity and transport security. Not sure yet whether the +right analogy is "Dapr building blocks as CF service types" or something closer to the CF runtime's own +process-to-process trust model — worth raising as an open comparison rather than a settled mapping. + +## Open questions + +- Does a CF-hosted agent runtime want app-level building-block APIs (state, pub/sub) as a platform + primitive, or should that remain squarely in "bring your own service broker" territory? +- How would Dapr's sidecar injection and per-app control-plane footprint (placement, sentry, scheduler) + map onto CF's Diego cell/app-instance model — is a sidecar-per-instance pattern already something CF + could support today, or does it need new primitives? +- Dapr's actor placement service assigns actor instances to specific sidecars — how would that interact + with CF's own instance placement and rebalancing? +- Is there overlap or conflict between Dapr's workflow durable-execution model and any workflow/orchestration + primitives CF might introduce for agent task orchestration?