AKS on Wolkwacht

Production Readiness for Dapr on AKS: Upgrades, Disaster Recovery, and Lessons Learned

Sat, 31 Oct 2026 00:00:00 +0000

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?

Securing and Scaling Dapr for Production on AKS

Wed, 21 Oct 2026 00:00:00 +0000

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.

Observability for Dapr on AKS: Traces, Metrics, and Logs

Sun, 18 Oct 2026 00:00:00 +0000

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.

Bindings, Secrets, and Actors with Dapr on AKS

Wed, 14 Oct 2026 00:00:00 +0000

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.

Pub/Sub Messaging with Dapr and Azure Service Bus on AKS

Sun, 11 Oct 2026 00:00:00 +0000

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.

State Management with Dapr on AKS

Sun, 04 Oct 2026 00:00:00 +0000

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.

Service Invocation with Dapr on AKS

Wed, 30 Sep 2026 00:00:00 +0000

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.

From OrbStack to AKS: Installing Dapr on a Managed Cluster

Sat, 26 Sep 2026 00:00:00 +0000

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.

Installing Dapr on Kubernetes Locally with OrbStack

Wed, 16 Sep 2026 00:00:00 +0000

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.

Dapr on Kubernetes and AKS Series

Sun, 13 Sep 2026 00:00:00 +0000

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.

What Is Dapr, and Why Run It on Kubernetes?

Sun, 13 Sep 2026 00:00:00 +0000

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.

Is Azure Container Apps Eating AKS's Lunch for Smaller Workloads?

Fri, 04 Sep 2026 00:00:00 +0000

Kubernetes has become so familiar that many teams don’t choose to adopt it anymore; they just start using it. When a new internal API appears, someone sets up an AKS cluster, and within weeks, the team manages node pools, upgrade channels, ingress, identity, policies, observability, and a backlog of Helm charts. None of these decisions are incorrect, but the issue is that the workload might never have required a Kubernetes platform in the first place.