Welcome to Wolkwacht

For years, the answer to “how do we get traffic into the cluster?” was the same in almost every team I worked with: install ingress-nginx, add a few annotations, done. It was the default in tutorials, the default in Helm charts, and on AKS it was even the engine behind the application routing add-on. ...

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. ...

A request can fail even when every Kubernetes pod is Running. The application may be waiting for a Dapr component, a retry may mask a slow dependency, or a call may reach the wrong app ID. Pod health tells us that the processes are alive; it does not explain the path a request takes. Dapr exposes three complementary signals. A trace reconstructs a single request across service boundaries. Metrics show whether a symptom is becoming a trend. Logs explain what a particular application or sidecar decided at a particular moment. The useful operational view comes from connecting all three. ...

The first six parts of this series covered Dapr’s most familiar building blocks: service invocation, state management, and pub/sub. They solve application-to-application calls, state, and asynchronous messaging. Three other capabilities often appear beside them, but they solve different problems. Bindings connect an application to an external system through a trigger or an operation. Secret stores keep credentials out of component manifests. Actors give stateful entities an address and a single-threaded execution boundary. Dapr Workflow then coordinates longer-running, multi-step processes, including work performed by actors. ...

A synchronous request establishes a direct dependency: the caller pauses while the destination handles the task. This approach is suitable when an immediate response is required. However, it is less ideal when multiple independent services need to respond to an event that has already occurred. An order can be accepted immediately without waiting for notification, fulfillment, analytics, or fraud services to complete. Publishing an order placed event allows these consumers to operate independently, scale separately, and recover from temporary failures. However, it also introduces new responsibilities such as managing event contracts, handling duplicate deliveries, setting retry limits, dealing with poison messages, maintaining order, and managing broker operations. ...

Persisting a shopping cart often involves database-related tasks: choosing a client library, setting up a connection pool, managing credentials, serializing the model, retrying transient failures, and deciding on concurrent update policies. When using a different language or database, much of this integration effort varies. Dapr state management moves the infrastructure-facing layer behind a local HTTP or gRPC API. The application works with keys, values, ETags, and consistency hints. A Dapr Component tells the sidecar which store to use for those operations, such as Redis, Azure Cosmos DB, PostgreSQL, or another supported store. ...

A direct HTTP call between two Kubernetes services seems simple. The caller needs a hostname, a timeout, and sufficient error handling to survive a disappearing pod. Soon it also needs retries, tracing, metrics, transport security, and an answer to which failures are safe to retry. Repeating that work in every service and language is where simple calls become distributed-systems plumbing. Dapr service invocation moves much of that plumbing into the sidecars. The caller sends a standard HTTP or gRPC request to its local Dapr endpoint and identifies the destination by app ID. Dapr discovers a healthy destination instance, preserves tracing context, communicates between sidecars using mTLS on Kubernetes, and forwards the request to the destination application. ...

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. ...

To quickly grasp Dapr on Kubernetes, it’s best to start locally rather than with an AKS cluster. Local setup allows for rapid pod creation in seconds, minimizes the consequences of mistakes, and keeps all control-plane components easily accessible for inspection. In this post, we’ll demonstrate setting up OrbStack’s single-node Kubernetes cluster on macOS, installing Dapr in development mode, examining the creation process, deploying a simple web app with a sidecar, and accessing it via Dapr’s HTTP API. The same annotations and runtime model apply to AKS later, with only differences in the platform and installation approach. ...