Module 7 takes the agent you built in Module 6 and turns it into a production cloud service. You'll containerize the stack, orchestrate it on Kubernetes, automate delivery, and operate it with observability, security, and cost controls. The goal: a reliable Digital FTE that runs 24/7 for real users.
Prerequisites: Modules 4-6. You need a working agent service to deploy.
Your Task API is growing. What started as a simple FastAPI application now needs to:
The obvious approach: import the SDKs. You add redis-py, aiokafka, hvac for HashiCorp Vault, and httpx with retry logic. Your requirements.txt grows. Your code gets entangled with infrastructure:
Now your DevOps team says: "We're moving from Redis to PostgreSQL for state, and from Kafka to RabbitMQ for messaging." Your response? Rewrite the application. Different SDKs. Different connection patterns. Different error handling. The infrastructure has invaded your business logic.
This is the infrastructure coupling problem. And it gets worse as your system grows. Every service that touches Redis, Kafka, or Vault must change when infrastructure changes. Every developer must understand every SDK. Every deployment must coordinate infrastructure and application updates.
What if there was a translator sitting next to your application? One that speaks all infrastructure languages so your application doesn't have to?
Imagine you're attending an international business conference. You speak English. The conference has speakers in Mandarin, Spanish, Arabic, and French. You have two options:
Option 1: Learn every language yourself. Spend years becoming fluent in each. Hope no new languages get added. Maintain all that knowledge over time.
Option 2: Hire a translator who sits beside you. The translator speaks all languages. You speak English to them. They handle all translation. When a new language appears, the translator learns it. Your job stays simple: communicate in English.
The sidecar pattern is Option 2 for infrastructure.
Your application speaks one simple language: HTTP calls to localhost. A sidecar process running alongside your application handles all infrastructure communication. It translates your simple HTTP requests into Redis commands, Kafka messages, Vault API calls, and service invocations.
You never import redis-py. You never configure Kafka brokers. You POST to localhost:3500 and the sidecar figures out the rest.
Dapr (Distributed Application Runtime) implements the sidecar pattern. When you deploy with Dapr, a process called daprd runs alongside your application. This daprd sidecar exposes two APIs:
Your application picks whichever protocol is easier. Most Python applications use HTTP because it's familiar and requires no special libraries. High-throughput scenarios might use gRPC for efficiency.
The key insight: your application container and the Dapr sidecar container share the same network namespace inside the pod. That's why your app calls localhost:3500; the sidecar is literally running on the same network interface.
The sidecar pattern provides five concrete benefits:
The sidecar reads a component YAML file that says "statestore uses Redis." Change that YAML to say "statestore uses PostgreSQL." Restart. Done. Your application code never changes.
Your application's requirements.txt shrinks. Your developers learn one API pattern, not dozens.
The sidecar applies policies uniformly:
Without a sidecar, you'd implement these in every service, for every SDK, with inevitable inconsistencies.
Dapr's HTTP/gRPC APIs work with any language. Your Python Task API and your Go Notification Service both call localhost:3500. Same pattern, same reliability, same observability.
Infrastructure teams manage components (Redis connections, Kafka brokers, secrets backends). Application teams manage business logic. Clean separation. Clear ownership.
On Kubernetes, you don't manually deploy the daprd sidecar. You add annotations to your deployment, and Dapr's sidecar injector automatically adds the sidecar container.
When you apply this deployment, Dapr's sidecar injector (running in the dapr-system namespace) intercepts the pod creation and adds the daprd container automatically.
After deployment, check your pods:
That 2/2 tells you: two containers are ready. Your application container and the Dapr sidecar container. If you see 1/2, the sidecar hasn't started yet; if you see 1/1, sidecar injection didn't happen (check your annotations).
Dapr runs in two modes depending on your environment:
You built a dapr-deployment skill in Lesson 0. Does it explain sidecar architecture and why it matters?
Does your skill cover:
Ask yourself:
If you found gaps:
Open your AI companion (Claude, ChatGPT, Gemini) and explore these scenarios.
What you're learning: How to articulate the sidecar value proposition. The AI helps you understand the architectural shift from SDK-per-infrastructure to single-API-for-all.
What you're learning: Critical evaluation of architectural patterns. The AI pushes you to understand both benefits and costs, helping you make informed decisions about when sidecar patterns apply.
What you're learning: Kubernetes mechanics of sidecar injection. The AI connects annotations to observable pod behavior, building your mental model of how Dapr works in practice.
As you explore sidecar patterns with AI, remember that adding a sidecar adds latency (typically 1-5ms per call) and resource overhead. For simple applications that will never change infrastructure, direct SDKs may be simpler. Evaluate the trade-offs for your specific use case. AI suggestions about architecture should be validated against your performance requirements and operational constraints.