Service ownership and contracts

Ownership means a next action

A service owner is the person or group responsible for keeping the service useful: reviewing changes, answering support questions and maintaining its recovery procedure. Ownership does not mean that person has every credential. A database administrator may restore data while an application maintainer checks that the restored data is usable.

In a one-person lab, you hold several roles. Naming them still matters because it separates two decisions: “Who decides?” and “Which automation is allowed to make the change?” A reconciler is the automation that repeatedly brings actual resources toward their declared configuration. Two reconcilers writing the same Deployment can undo each other's changes.

Ownership is a responsibility

A label identifies an owner; it does not implement support. For this personal lab, one learner may fill several roles. Name the roles anyway so you can see which responsibilities a future team would inherit.

The application owner understands transaction semantics, dependencies, and compatible schema changes. The platform owner maintains supported deployment inputs, controllers, templates, and recovery procedures. The data owner defines retention and restore checks. Use these roles to decide who investigates each failure, even when Kubernetes reports the symptom.

Make MicroBank's contract explicit

Record the actual source revision you built. The earlier lessons inspect f75da68, where the settlement-consumer and backend-authorization gaps are explicit. A separate working branch might add a worker, metrics, or demo login. Review, build, and verify those changes before adopting them into your deployment contract. Do not combine a two-service Kubernetes manifest with a worker-based Compose profile silently.

Document each service's image, port, health behavior, dependencies, and expected data. Distinguish acceptance of an Accounts request from the corresponding entry appearing in Ledger. Decide whether the observed Accounts status should remain pending in your baseline or be updated by an implemented consumer.

Follow a failure to its owner

These are starting points, not permission to stop investigating at a team boundary. An image-pull error might be a missing artifact, a bad registry credential or a network failure. Ask for the observation before assigning blame.

For the lab, draft a four-column record: resource, desired-state source, writer, recovery owner. Give Accounts Deployment exactly one writer, Argo CD. Give its runtime Secret an explicit separate delivery mechanism. The contract lab will replace draft entries with observations from your checkout.

Try it

Add an ownership table to the service contract:

Replace role names with real contacts only in your own working documentation. Add a change boundary: who approves a new image, a policy exception, or a destructive data change?

Checkpoint and revision

Explain which ownership field is descriptive and which system actually enforces permissions. Catalog metadata is not authorization. Keep known application limitations in the contract even when infrastructure checks pass.

Compare your reasoning

A catalog owner field helps someone find support. It does not grant Kubernetes RBAC or repository write access. If Terraform and Argo CD both own one Deployment, resolve that overlap before adding a portal; a nicer interface cannot make competing writers consistent.

Sources

Backstage entity descriptors↗, Kubernetes RBAC practices↗.