Service catalog and ownership

Learn the small catalog model first

A catalog records things people need to find. In this path, a System groups the MicroBank application, a Component represents an actual service, and a Group represents a maintainer role. Relationships connect those entries. They are metadata, not live proof that a service is deployed.

Describe what exists

The first catalog can contain a MicroBank System and Accounts and Ledger Components, with a Group representing the lab maintainer role. Add the frontend or a settlement worker only when included in your selected, verified application profile. Do not register the upstream README's absent Notifications implementation as a running service.

A catalog entity records metadata and relationships. It does not discover every runtime dependency automatically or enforce the listed owner's access. Keep source, runbook, environment, and evidence links current through a defined update process.

Model useful relationships

Accounts depends on its database and messaging path. Ledger depends on its database and transaction queue. A frontend calls APIs. Those are different relationships from “is owned by.” Use entities and relationship fields supported by the chosen catalog, and check that referenced owners and systems resolve.

Use a lifecycle value that fits the local exercise, such as experimental. A production label in a catalog cannot make an unauthenticated demo API production-ready.

Read a Component descriptor

This is an isolated reading example. The capstone supplies the corresponding System and Group definitions and the registration procedure.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: microbank-ledger
spec:
  type: service
  lifecycle: experimental
  owner: group:default/microbank-maintainers
  system: microbank

metadata.name identifies the entity. The spec describes its kind of component, declared lifecycle and relationships. The owner reference names a Group in the default catalog namespace; it is not a Kubernetes ServiceAccount or repository permission.

Work through a rename: if microbank-maintainers becomes banking-lab-maintainers, the Group and references need coordinated updates. A well-formed YAML file can still point at an entity that does not exist. After registration, follow the owner and System links rather than checking only that Ledger appears in search.

Now list three links a new learner would actually use: source code, a runbook and the current deployment record. Add real destinations in your implementation. Do not invent an owner email, team or service just to fill the catalog.

Try it

Create the catalog descriptors supplied in the capstone lab and register them in a local portal. Replace the sample role with your actual owner model. Follow every relationship and link. Then deliberately break an owner reference in an offline copy and inspect the resulting validation or unresolved relation.

Add one runbook and a link to the authoritative build/deployment view. Keep private transaction evidence behind its access control. You can describe the exercise on LearnWithSK while keeping credentials and internal control-plane access private.

Checkpoint and revision

Can a learner identify who supports Ledger, where its source lives, and which deployment record is current? Explain what must be updated when a service is renamed, retired, or moves to another owner.

Compare your reasoning

The experimental lifecycle describes the intended status of this lab. Runtime health belongs to a separate observation with a time and source. An owner relation helps a person navigate; access controls remain in the systems that perform the work.

Sources

Backstage catalog model↗, Backstage descriptors↗.