Cloud Signals

Ingress-NGINX has stopped receiving patches, so it's time to plan the move. Here's what I would look at, whether you run AKS or managed Kubernetes at a hosting provider, plus what I learned testing the migration paths.

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 behav

A request can fail even when every Kubernetes pod is Running . The application may be waiting for a Dapr component, a retry may be hiding 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 taken by a request.

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-

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 independentl

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 Com

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 g

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.

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 H

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 l

The real question is not whether to use the Azure Key Vault provider for the Secrets Store CSI Driver or the External Secrets Operator (ESO). Instead, it’s whether your workload should access secret data as mounted files or via native Kubernetes Secret objects . That choice influences application design, rotation, incident handling, RBAC, observability, Helm compatibility, and GitOps. In short: CSI offers a more secure default for applications that consume files; ESO provides a more practical pl

This is test post