Coding With Taz

This builds directly on Part 7.

The main series focused on local development and the core Dapr building blocks. This appendix shifts to production‑oriented Kubernetes configuration, showing the shape of real-world-deployments without overwhelming you with every possible scenario.

We’ll cover:

Deployments with Dapr sidecars
State stores using Kubernetes secrets
Pub/Sub components for real brokers
Storage bindings for cloud providers
Secret stores
Namespace scoping
Notes on mTLS and the control plane
A production-ready checklist
Common mistakes to avoid

Companion GitHub repository: dapr-by-example.

These examples complement the main series without changing its local‑first learning flow.

1. Deploying a Dapr‑Enabled Service in Kubernetes

Dapr integrates with Kubernetes using annotations.
Here’s a minimal Deployment for the .NET Order Service from Part 7:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orderservice-dotnet
spec:
  replicas: 1
  selector:
    matchLabels:
      app: orderservice-dotnet
  template:
    metadata:
      labels:
        app: orderservice-dotnet
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "orderservice-dotnet"
        dapr.io/app-port: "8080"
        dapr.io/config: "tracing"
        dapr.io/enable-metrics: "true"
        dapr.io/metrics-port: "9090"
    spec:
      containers:
        - name: orderservice-dotnet
          image: localhost:5000/orderservice-dotnet:v1.0
          ports:
            - containerPort: 8080
          env:
            - name: ASPNETCORE_URLS
              value: "http://+:8080"

What this does

Injects the Dapr sidecar automatically
Assigns the app ID (orderservice)
Exposes the app port to the sidecar
Enables Dapr logs and tracing

No SDKs. No infrastructure code.
Just annotations.

2. State Store: Postgres with Kubernetes Secrets

A production state store should never embed credentials directly.
Here’s a Postgres component using secretKeyRef

Dapr Component

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
  labels:
    component: statestore
spec:
  type: state.postgresql
  version: v1
  metadata:
    - name: connectionString
      secretKeyRef:
        name: pg-secret
        key: conn
    - name: tableName
      value: "dapr_state"
    - name: schema
      value: "public"
    - name: cleanupIntervalInSeconds
      value: "3600"
    - name: actorStateStore
      value: "true"
scopes:
  - orderservice-dotnet
  - inventoryservice-dotnet
  - orderservice-go
  - inventoryservice-go

Notes:

scopes: ensures only the Order Service can use this component
The connection string lives in a Kubernetes Secret
Dapr handles retries, serialization, and concurrency
Components must live in the same namespace as the workloads that use them

3. Pub/Sub: Kafka Component for Production

Here’s a Kafka pub/sub component suitable for real clusters:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
  labels:
    component: pubsub
spec:
  type: pubsub.kafka
  version: v1
  metadata:
    - name: brokers
      value: "my-cluster-kafka-bootstrap.kafka.svc.cluster.local:9092"
    - name: consumerGroup
      value: "orderservice"
    - name: authType
      value: "none"
    - name: initialOffset
      value: "newest"
    - name: maxMessageBytes
      value: "1048576"
    - name: disableTls
      value: "true"
scopes:
  - orderservice-dotnet
  - inventoryservice-dotnet
  - orderservice-go
  - inventoryservice-go

Notes:

Dapr manages consumer groups
Ordering is not guaranteed
At‑least‑once delivery is the default
Scopes restrict which services can publish/subscribe
Pub/Sub and input bindings use CloudEvents by default

4. Storage Binding: AWS S3

Bindings expose simple operations (create, get, delete).
Here’s an S3 binding using IAM credentials stored in Kubernetes.

Dapr Component

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: storage
  labels:
    component: storage
spec:
  type: bindings.aws.s3
  version: v1
  metadata:
    - name: bucket
      value: "order-receipts"
    - name: region
      value: "eu-west-2"
    - name: endpoint
      value: "s3.eu-west-2.amazonaws.com"
    - name: accessKey
      secretKeyRef:
        name: s3-creds
        key: accessKey
    - name: secretKey
      secretKeyRef:
        name: s3-creds
        key: secretKey
    - name: decodeBase64
      value: true
scopes:
  - orderservice-dotnet
  - orderservice-go

Notes:

Works with the same Go and .NET code from Part 7
Credentials stay out of application code
Bindings intentionally expose limited operations

5. Secret Stores: Kubernetes, Azure Key Vault, AWS Secrets Manager, and more

Dapr supports multiple secret stores.
Here are the three most common.

5.1 Kubernetes Secret Store (default)

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: kubernetes
spec:
  type: secretstores.kubernetes
  version: v1

This is automatically available in most clusters.

5.2 Azure Key Vault

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azurekeyvault
spec:
  type: secretstores.azure.keyvault
  version: v1
  metadata:
    - name: vaultName
      value: "my-vault"
    - name: azureTenantId
      value: "tenant-guid"
    - name: azureClientId
      value: "client-guid"
    - name: azureClientSecret
      secretKeyRef:
        name: keyvault-creds
        key: clientSecret

5.3 AWS Secrets Manager

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: aws-secrets
spec:
  type: secretstores.aws.secretsmanager
  version: v1
  metadata:
    - name: region
      value: "eu-west-1"
    - name: accessKey
      secretKeyRef:
        name: aws-creds
        key: accessKey
    - name: secretKey
      secretKeyRef:
        name: aws-creds
        key: secretKey

6. Namespaces and Component Scoping

In multi‑team clusters, scoping is essential.

Best practices

Put components in the same namespace as the services that use them
Use scopes: to restrict access
Use separate namespaces for staging vs production
Avoid global components unless absolutely necessary
Keep secrets and components close to the workloads that depend on them

7. mTLS and the Dapr Control Plane

Dapr enables mTLS by default in Kubernetes.

This means:

All service‑to‑service traffic via Dapr is encrypted
Certificates rotate automatically
No application code changes are required

The control plane includes:

Operator — injects sidecars
Sentry — issues and rotates certificates
Placement — manages actors

You rarely need to configure these unless customising certificate lifetimes or issuers.

8. Putting It All Together

A real‑world Dapr deployment typically includes:

A Deployment with Dapr annotations
A state store component using secrets
A pub/sub component for Kafka or Service Bus
A storage binding for S3 or Azure Blob
A secret store (Kubernetes, Key Vault, or Secrets Manager)
Scopes to restrict component access
Automatic mTLS from the control plane

Your application code, whether Go, .NET, Python, or Java, etc., stays clean and infrastructure‑agnostic.

Production Architecture Diagram

Kubernetes Pod
 ├─ Your Application
 └─ Dapr Sidecar
       ├─ State Store (Postgres / Redis)
       ├─ Pub/Sub Broker (Kafka / Service Bus)
       ├─ Storage Provider (S3 / Blob)
       └─ Secret Store (K8s / Vault / AWS SM)

Dapr becomes the consistent interface between your service and the platform.

Common Mistakes to Avoid

1. Putting components in the wrong namespace

Components must live in the same namespace as the workloads that use them.

2. Forgetting to use scopes

Without scopes, components may be unintentionally shared across services.

3. Embedding secrets directly in components

Always use secretKeyRef or a secret store.

4. Assuming local and Kubernetes behavior are identical

Local mode does not hot‑reload components; Kubernetes does.

5. Ignoring sidecar resource limits

Set CPU/memory limits to avoid noisy‑neighbor issues.

6. Forgetting CloudEvent envelopes

Pub/Sub and input bindings wrap messages in CloudEvents unless disabled.

Production‑Ready Checklist

Application

[ ] Dapr annotations applied
[ ] App ID defined
[ ] App port exposed
[ ] Resource limits set for both app and sidecar

Components

[ ] Components placed in correct namespace
[ ] Scopes applied
[ ] Secrets referenced via secretKeyRef
[ ] Pub/Sub configured with consumer groups
[ ] State store configured with proper consistency/concurrency modes

Security

[ ] mTLS enabled (default)
[ ] Secret store configured
[ ] No credentials in code or components

Observability

[ ] Tracing sampling configured via Dapr Configuration
[ ] Prometheus scraping enabled
[ ] Logs aggregated centrally

Operations

[ ] Resiliency policies defined (timeouts, retries, circuit breakers)
[ ] Health probes configured
[ ] Versioned components stored in Git

Final Thoughts

This appendix isn’t meant to be exhaustive.
It’s meant to show the shape of real‑world Dapr usage:

Clean separation of concerns
Infrastructure defined declaratively
Secrets handled securely
Sidecars injected automatically
Observability built in
Polyglot services sharing the same building blocks

If the main series showed how Dapr simplifies distributed systems, this appendix shows how those same patterns scale into production.

Over the past six posts, we’ve explored Dapr’s core building blocks one by one:

Individually, each building block simplifies a specific problem. Together, they form a powerful pattern for building distributed systems where application code stays focused on business logic not infrastructure.

In this final post, we’ll put everything together by walking through a simple but realistic service that uses multiple Dapr capabilities in a single workflow.

The Scenario

We’ll build a service that:

Accepts an order
Stores order state
Publishes an event
Writes an order receipt to object storage

The service will use:

State management for persistence
Pub/Sub for eventing
Bindings for storage
Observability for tracing and metrics

And importantly:

There will be no Redis, Kafka, or cloud storage SDKs in the application code

Companion Repository

The full implementation of this scenario, including the Go and .NET services, Dapr components, and local‑first development setup is available in the companion GitHub repository: dapr-by-example.

You can clone it and follow along as you read, or use it as a reference architecture for your own Dapr‑enabled services.

High‑Level Architecture

At runtime, the flow looks like this:

Client
  ↓
Order Service
  ↓
Dapr Sidecar
  ├─ State Store (Redis / Postgres)
  ├─ Pub/Sub (Kafka / RabbitMQ / Service Bus)
  └─ Storage (S3 / Azure Blob)

Your application talks only to Dapr.
Dapr talks to the infrastructure.

This separation is what makes the system portable, testable, and easy to evolve.

The Order Model

We’ll use a simple order model shared across examples.

{
  "orderId": "order-123",
  "amount": 100
}

Step 1: Accepting an Order

Go example

type Order struct {
    OrderID string `json:"orderId"`
    Amount  int    `json:"amount"`
}

func createOrder(w http.ResponseWriter, r *http.Request) {
    var order Order
    json.NewDecoder(r.Body).Decode(&order)

    saveOrder(order)
    publishOrder(order)
    storeReceipt(order)

    w.WriteHeader(http.StatusAccepted)
}

The handler coordinates the workflow.

All infrastructure interactions happen through Dapr.

.NET example

app.MapPost("/orders", async (Order order, DaprClient dapr) =>
{
    await dapr.SaveStateAsync("statestore", order.OrderId, order);
    await dapr.PublishEventAsync("pubsub", "orders", order);
    await dapr.InvokeBindingAsync(
        "storage",
        "create",
        Encoding.UTF8.GetBytes($"Order {order.OrderId}")
    );

    return Results.Accepted();
});

Step 2: Storing Order State

Go

func saveOrder(order Order) error {
    state := []map[string]interface{}{
        {
            "key":   order.OrderID,
            "value": order,
        },
    }

    body, _ := json.Marshal(state)

    _, err := http.Post(
        "http://localhost:3500/v1.0/state/statestore",
        "application/json",
        bytes.NewBuffer(body),
    )

    return err
}

.NET

await dapr.SaveStateAsync("statestore", order.OrderId, order);

The backing store can be Redis, Postgres, or something else, the code doesn’t care.

Step 3: Publishing an Event

Go

func publishOrder(order Order) error {
    body, _ := json.Marshal(order)

    _, err := http.Post(
        "http://localhost:3500/v1.0/publish/pubsub/orders",
        "application/json",
        bytes.NewBuffer(body),
    )

    return err
}

.NET

await dapr.PublishEventAsync("pubsub", "orders", order);

Consumers can subscribe to this event without the order service knowing who they are.

Dapr handles CloudEvents, retries, and delivery semantics.

Step 4: Writing to Object Storage

Go

func storeReceipt(order Order) error {
    payload := map[string]interface{}{
        "operation": "create",
        "data":      []byte("Order receipt"),
        "metadata": map[string]string{
            "blobName": order.OrderID + ".txt",
        },
    }

    body, _ := json.Marshal(payload)

    _, err := http.Post(
        "http://localhost:3500/v1.0/bindings/storage",
        "application/json",
        bytes.NewBuffer(body),
    )

    return err
}

.NET

await dapr.InvokeBindingAsync(
    "storage",
    "create",
    Encoding.UTF8.GetBytes("Order receipt"),
    new Dictionary<string, string>
    {
        ["blobName"] = $"{order.OrderId}.txt"
    }
);

This works with S3, Azure Blob Storage, or any supported provider.

What Changed Compared to a Traditional Approach?

Notice what’s missing from the application code:

No Redis client
No Kafka or Service Bus SDK
No cloud storage SDK
No connection strings
No retry or backoff logic

All of that lives in Dapr components and configuration.

Your application code stays focused on the workflow, not the plumbing

Why This Matters in Real Systems

This approach enables:

Infrastructure portability

Swap Redis for Postgres, Kafka for Service Bus, or S3 for Azure Blob without code changes.

Polyglot services

Go and .NET services use the same APIs and patterns.

Cleaner boundaries

Application code focuses on business logic.

Incremental evolution

Infrastructure decisions can change independently of services.

Consistent observability

Tracing and metrics flow through Dapr automatically.

When This Pattern Works Best

This style of architecture works particularly well when:

Services own their own state
Systems are event‑driven
Teams want to avoid vendor lock‑in
Multiple languages are in use

It’s less useful for:

Query‑heavy, relational workloads
Highly specialised broker features
Single‑service applications

Final Thoughts

Dapr is not a silver bullet, and it doesn’t remove the need to understand your infrastructure. What it does provide is a consistent, portable abstraction over the parts of distributed systems that are otherwise repetitive and error‑prone.

Used thoughtfully, Dapr can significantly reduce the amount of glue code in your systems and make them easier to evolve over time.

If you want to see how this looks in Kubernetes, the Appendix covers some real‑world manifests.

Series Recap

You now have everything you need to build a real‑world Dapr‑enabled service from scratch.