With this lesson the final project of K3 begins. Hardly any new tools are added. What is new is the demand: In the end the Kladde runs out of an empty subscription, through nothing but the pipeline, Bicep and a runbook, without a single step on your own machine. It is monitored, its recovery has been rehearsed, and you can clear up an incident from the logs.
The module has twelve lessons:
| Lesson | What happens | Hours |
|---|---|---|
| 3.10.1 Planning and estimating | Goals, issues, definition of done for operations, costs and budget | 3 |
| 3.10.2 The empty subscription | Budget, policies, resource groups and identities as Bicep, a runbook for the rest | 5 |
| 3.10.3 The pipeline from scratch | The first pull request runs all the way to prod |
5 |
| 3.10.4 The application without keys | A script looks for secrets and finds none | 5 |
| 3.10.5 The import via Service Bus | A hundred messages with duplicates and a poison message | 5 |
| 3.10.6 Observation and alerts | Every alert is triggered once and arrives | 5 |
| 3.10.7 Resilient under load | A load test against the target from this lesson | 5 |
| 3.10.8 Recovery rehearsed | Bring back the database and files, measure the time | 3 |
| 3.10.9 Teardown and rebuild | Tear everything down and rebuild it from the empty subscription | 4 |
| 3.10.10 Review and operations manual | The second code review, the manual for operations | 4 |
| 3.10.11 Incident drill | Clear up a built-in incident from the logs | 3 |
| 3.10.12 Wrapping up | Demo, code reading and practice questions | 3 |
Before you build anything, you write down what operations should deliver and what it may cost. That is what this lesson is about.
Where the Kladde stands
After module 3.9, your Kladde has almost everything operations needs. It just has never come into being from nothing in one go. Go through the modules in the order in which you learned them:
| Module | What the Kladde has since then |
|---|---|
| 3.0 Infrastructure from the ground up | clean shutdown on SIGTERM, checked with scripts/check-shutdown.ps1; docs/network.md with an address plan and rules for a network of its own later |
| 3.1 Azure fundamentals | subscription with a budget, "EU only" policies, names, tags and permissions, docs/operations.md, docs/costs.md |
| 3.2 Infrastructure as code | its own Bicep modules under infra/, environments dev and test, a deployment stack |
| 3.3 Security in operation | SQL without a password, the signing key in Key Vault, redacted logs, push protection |
| 3.7 CI/CD | every pull request tested, main to dev, prod after approval, versioned images, no stored secret |
| 3.4 Observability | telemetry in Application Insights, custom metrics, queries under ops/queries/, health checks, alerts |
| 3.6 Data in the cloud | migrations in the pipeline, raw data in Blob Storage, scripts/restore-drill.ps1 |
| 3.5 Messaging and events | the import via Service Bus, CSV import via Event Grid, idempotent, dead-letter alert |
| 3.8 Advanced testing | integration tests against containers in the pipeline, a measured load test |
| 3.9 Resilience and performance | timeouts, retries only where allowed, cache, rate limiting |
Some of that you built in a subscription where something was already lying around: the budget from 3.1.2, the policies from 3.1.5, a role assignment that you made in the portal because the pipeline wasn't allowed to. Exactly such leftovers show up when you switch subscriptions. The final project makes them visible and turns them into code.