Course Preview

Dapr

Dapr (Distributed Application Runtime) is a portable runtime that simplifies building distributed microservices. It provides building-block APIs for service invocation, state management, pub/sub messaging, and secrets, letting applications use these capabilities through HTTP or gRPC without vendor-specific SDKs.

itCloud native tools and technologies | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic: Dapr

Dapr is a runtime that sits beside an application and gives it local APIs for the distributed-system chores that otherwise breed client libraries, configuration files, and a slightly alarming collection of retry loops. The application keeps its business logic. The sidecar, a nearby daprd process or container, handles selected calls to other applications and infrastructure. This is not magic. It is a carefully positioned extra process, which is more useful than magic because it can be inspected when it misbehaves.

The useful split is between a building block and a component. A building block is the API your application calls for service invocation, state, pub/sub, secrets, or another capability. A component is the configured implementation behind it, such as a state store or broker. That division lets application code avoid a vendor-specific client, but it does not make every broker or data store behave alike. The word portable therefore means "portable at the Dapr API boundary," not "free from testing," which would be a suspiciously generous offer from a distributed system.

Each application has an application ID, which Dapr uses for routing, discovery, identity, and policy. For a service call, the caller talks locally to its sidecar; the sidecars carry the request to the destination application. For a component call, the sidecar uses the named component to reach the backing system. The local API is the stable bit. The exact component features, credentials, latency, and failure modes are the parts that still require grown-up attention.

The surprise is that reliability policies are not correctness policies. A timeout tells a caller to stop waiting. A retry repeats an attempt. Neither can tell whether a remote write already happened. Dapr can apply timeouts, retries, and circuit breakers, but the application must make duplicate work safe and must decide what a partial result means. A cheerful YAML file cannot settle that argument for you, despite its confidence.

Start with the Intro when you need the complete architecture and the difference between building blocks and components. Use Slides for the call paths and control-plane map. Keep Cheatsheet nearby when choosing scopes, policies, and failure tests. The practice reference then gives the local sidecar a name, a port, and a metadata endpoint, which is an excellent way to meet a runtime before asking it to coordinate anything important.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources