Production readiness starts where most tutorials end. Installing Dapr, deploying sidecars, and proving the building blocks are necessary milestones, but they do not answer the operational questions: How will you upgrade without moving every workload at once? Which state must survive a lost cluster? Can another region actually receive traffic? How quickly can you undo a bad change? ...
A Dapr-enabled application can work perfectly with one replica and still be unprepared for production. The sidecar may have no resource requests, every application may be able to load every component, a rollout may require capacity the cluster does not have, or an autoscaler may react to application CPU while ignoring a throttled daprd container. Production readiness is therefore not one switch. It is a chain of explicit decisions about identity, authorization, isolation, capacity, rollout behaviour, scaling signals, and control-plane availability. ...
Transferring a Dapr-enabled application from local Kubernetes to AKS should be straightforward. The annotations, app ID, application port, sidecar API, and workload manifest stay familiar. The key difference is ownership: a temporary local setup transforms into a shared runtime that requires a version policy, availability plan, network access, identity strategy, and support structure. This post moves the sample from Installing Dapr on Kubernetes Locally with OrbStack to an existing AKS cluster. We will compare the open-source installation path with the AKS Dapr extension, install the extension, verify the control plane, and deploy the same NGINX workload. ...
Dapr on Kubernetes and AKS Dapr gives applications a consistent set of APIs for common distributed-systems concerns while leaving the backing infrastructure replaceable. This series starts with the mental model, builds a fast local development loop, moves the same workload to Azure Kubernetes Service, and then works through the building blocks and production concerns. The series is written for developers and platform engineers who already know the basics of Kubernetes but are new to Dapr. Each post stands on its own; reading in order gives you the smoothest path from first principles to production. ...
Every distributed application gathers various plumbing components. One service requires retries and timeouts, another needs a message broker client, and a third must store some state, retrieve secrets, or discover other services. Over time, each team ends up with a unique set of client libraries, connection handling methods, telemetry, and failure behaviors. Dapr, the Distributed Application Runtime, provides a uniform API for the underlying infrastructure. Your application communicates with a local Dapr process via HTTP or gRPC. Dapr then interacts with services, the state store, the broker, the secret store, or other components on your application’s behalf. While the application retains control of its business logic, Dapr offers reusable capabilities for building distributed applications. ...