Service catalog · 02 of 05 · Two catalogs

The menu and the inventory

"Service catalog" means two different things. One is a list of what exists. The other is a list of what you're allowed to ask for. A platform needs both, and it works best when the first is generated from the second.

The menu and the inventory Two panels. The inventory answers "who owns baggage-api?": what is running and whose it is, through components, owners with team and on-call, and docs, collected in the Backstage catalog, which is generated from what the control plane reports. The menu answers "can I have a database?": what you can ask for and what you get, through APIs such as PostgreSQL, Redis and SecretStore, defined in Airframe as XRDs with outputs, conditions and reasons. Airframe feeds the Backstage catalog. Below, an agent or a new hire reads both and needs both answers before acting. THE INVENTORY · WHAT EXISTSTHE MENU · WHAT YOU CAN ASK FORFEEDSWho owns baggage-api?what is running, and whose is itComponenta running serviceOwnerteam · on-callDocsTechDocs · APIsBackstage cataloggenerated from what the control plane reportsCan I have a database?what can I ask for, and what do I getPostgreSQLsize · instancesRedisa cache per envSecretStoreapp · clusterAirframeXRDs with outputs, conditions and reasonsAn agent, or a new hireneeds both answers before actingMost catalogs only answer the question on the left, and go stale answering it.LEGENDThe questionThe menuThe inventoryThe readerGeneratesAnswers

The inventory

Ownership, docs and dependencies for everything that runs. Useful, and famously hard to keep true when people maintain it by hand.

The menu

Typed APIs with a schema, defaults, outputs and an honest status. This is the part that defines the platform, and the part I built first.

Generated, not typed

In Hangar, Backstage's entities and its templates are both generated from Airframe's live XRDs and XRs, so the inventory stays true to what the menu created.

Hangar · Airframe · Service catalog