Since lesson 4.5.1, the Kladde has been running in Azure with exactly one replica. The reason is in a comment in your Bicep file: with UseLocalhostClustering, every replica would be a cluster of its own, and the same quote would have two activations. In this lesson you lift that limit. The silos find each other through Azure SQL, the Container App runs with two replicas, and you show that neither a restart nor a deploy loses a quote. At the end, you tear everything down again.

What turns silos into a cluster

Four things have to be right for several silos to be one cluster and not several clusters that happen to use the same database:

  1. A meeting point. At startup, every silo enters itself into a membership table and reads there who else is around. The silos detect failures by checking each other directly; the table records what they have agreed on. In the Kladde it lives in Azure SQL, next to the grain state.
  2. Fixed IDs. The ClusterId says which silos belong together; it is the key in the membership table. The ServiceId says which application stored state belongs to (lesson 4.5.3). For the Kladde, both stay kladde forever, across all replicas and all deploys. Then the silos of a new version join the same cluster instead of forming a second one.
  3. Reachability. Silos talk to each other directly, over the silo port (11111 by default). Every silo enters its address on the network into the table. The replicas of a Container Apps environment reach each other through these addresses; port 11111 needs no ingress and is not reachable from outside. The gateway port (30000) is for clients in other processes; the Kladde does not need it, because its web application is itself a silo.
  4. Nothing that only one silo knows. Grain state (4.5.3) and reminders (4.5.7) are already in the database. What still runs on each replica for itself, you check further down: background services, the keys of Data Protection and the connections of the interactive islands.