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.
You learned Kafka directly in earlier chapters. You wrote code that knew about brokers, topics, and consumer groups. If you wanted to switch from Kafka to RabbitMQ, you'd rewrite your messaging code. Different SDK, different connection logic, different error handling.
Now imagine a different world. You write code that says "publish this message" or "save this state." You don't specify where or how. That decision lives in a configuration file. To switch from Kafka to RabbitMQ, you change one YAML file. Your application code doesn't change at all.
This is Dapr's abstraction model: building blocks provide the API (what you can do), and components provide the implementation (how it actually happens). This lesson explores how this separation works and why it matters for portable, maintainable distributed systems.
A building block is a Dapr capability exposed through an HTTP or gRPC API. It defines what you can do, not how it's done underneath.
Think of building blocks like a universal remote control. The remote has buttons for "power," "volume," and "channel." It doesn't care if you're controlling a Samsung TV, a Sony TV, or a projector. Same interface, different devices.
When you use the state management building block, your code makes HTTP calls like:
Notice what's missing from this request:
Your code says "save this state." Dapr handles everything else.
A component is a Dapr configuration that binds a building block to a specific backend technology.
Continuing the remote control analogy: the component is the IR (infrared) blaster pointed at your specific TV. The remote (building block) doesn't change. The blaster (component) tells Dapr "when someone uses state management, talk to this Redis server."
The state management building block can use any of these components:
The pub/sub building block has similar flexibility:
This is the single most important concept in Dapr.
Your application code calls the building block API:
What happens next depends entirely on which component is configured with the name pubsub:
Your code doesn't know or care. The component YAML makes that decision.
In earlier chapters, you wrote Kafka-specific code:
With Dapr, that same functionality becomes:
The Dapr version is simpler and portable. Change the component configuration, and you've switched message brokers without touching code.
Every Dapr component is defined in a YAML file with a consistent structure. Understanding this structure helps you read, write, and debug component configurations.
Let's examine each part:
When your code calls:
Dapr looks for a component where metadata.name equals statestore. The spec.type tells Dapr which building block (state) and which implementation (Redis) to use.
Redis State Store:
Kafka Pub/Sub:
Kubernetes Secrets Store:
Notice that some components need extensive configuration (Kafka needs broker addresses and consumer groups), while others need almost none (Kubernetes secrets store uses the cluster's built-in secrets API).
Here's where Dapr's abstraction model pays dividends.
Development (simple setup):
Production (robust messaging):
Your application code is identical in both environments. It publishes to pubsub and subscribes to topics. The infrastructure decision—Redis in dev, Kafka in production—lives entirely in configuration.
By default, Dapr components are available to all applications in a namespace. You can restrict which apps can access a component using scopes.
Add a scopes field to your component:
Only applications with dapr.io/app-id: payment-service or dapr.io/app-id: billing-service can access this secrets store.
If you omit the scopes field, the component is available to every Dapr-enabled app in the namespace.
You built a dapr-deployment skill in Lesson 0. Test and improve it based on what you learned.
Does your skill clearly distinguish these concepts?
Ask yourself:
If you found gaps:
You now understand Dapr's abstraction model. Use AI to explore how this applies to your own systems.
Open your AI assistant with context about Dapr. These prompts help you apply concepts to real scenarios.
What you're learning: The building block/component separation is Dapr's core innovation. This prompt forces you to articulate the abstraction clearly and see how it enables backend swapping.
What you're learning: Reading component YAML fluently is essential for debugging and configuration. Notice the secretKeyRef pattern—Dapr can pull sensitive values from secret stores instead of hardcoding them.
What you're learning: This is the portability payoff. You'll see that your code references pubsub_name='pubsub' and the component YAML decides whether that means Redis or Kafka. The swap is purely configuration.