The Kladde can now serve several offices, and a test in the build proves that they stay separate. In this lesson it goes to Azure the way your ADR on the tenancy model from lesson 4.7.6 laid down, and you operate it there like a small provider: you roll out a new version step by step, bring a single office back from a backup, and measure what one office costs per month. These are proofs two and three from lesson 4.9.1.

Everything runs in your own subscription with the budget and the cost alert from K3. Plan the exercises so that the resources stand for only a few days; at the end of the lesson you tear everything down again. The amounts you measure go into your repository, not into notes.

Two models, two ways to Azure

In lesson 4.7.6 you compared the tenancy models for 3, 30 and 300 offices and chose one. For delivery that means:

One shared instance One stamp per office (deployment stamps)
What exists one container app with two replicas, one Orleans cluster, one database for all offices per office one container app and one database; environment, registry, logs and SQL server shared
A new office an entry in the registry of offices (4.9.2), no new resource an entry in the parameter file and a deployment
Isolation in the application (4.9.3), row-level security as a second safeguard additionally through separate databases and processes
A new version for everyone at once, gradually only through revisions and weights office by office, in rings
Bringing an office back pick the rows of one office out of a backup of the whole database restore the database of that one office
Cost per office distribute the shared costs by usage direct costs per office plus a share of the shared ones

Both are right, depending on the number and size of the offices, and many providers mix: small offices in a shared instance, a large one in a stamp of its own. The lesson shows both ways. Build the one your ADR demands; read along for the other, because the architecture review in 4.9.7 asks about the trade-off.