IDP-Komponenten: Portal, Catalog, Scaffolding

Lernziele

Nach dieser Lektion kannst du die drei sichtbarsten IDP-Bausteine erklären und voneinander abgrenzen: das Developer Portal als Einstiegspunkt, den Service Catalog als Ownership- und Metadaten-Verzeichnis und das Scaffolding als Werkzeug, das Golden Paths anfassbar macht. Du verstehst, wie die drei zusammenspielen, warum das Portal nur die Fassade der Plattform ist — und kannst eine Catalog-Beschreibung selbst schreiben.

Das Problem: 300 Services und niemand hat den Überblick

Eine Organisation wächst auf 40 Teams und 300 Services — und plötzlich kosten triviale Fragen Stunden: Gibt es schon einen Service, der Adressen validiert? Wem gehört die Payment-API, die gerade Fehler wirft? Wo ist die Doku? Welche Version läuft in Produktion? Und wie fange ich einen neuen Service an — welches Repo kopiere ich als Vorlage?

Die Antworten existieren — verteilt über Repos, Wikis, Chat-Verläufe und die Köpfe einzelner Kollegen. Genau diese Discovery-Lücke füllt die Developer-Experience-Schicht der IDP (L4 aus Lektion 8) mit drei Bausteinen, die jeweils eine der Fragen beantworten: Der Catalog beantwortet „was existiert und wem gehört es”, das Scaffolding beantwortet „wie starte ich richtig”, und das Portal macht beides an einem Ort zugänglich.

Der Service Catalog: Ownership als Datensatz

Der Catalog ist das maschinenlesbare Inventar aller Software-Komponenten: Services, APIs, Websites, Pipelines, Ressourcen — jeweils mit Owner, Lebenszyklus-Status, Beschreibung und Beziehungen („konsumiert API X, gehört zu System Y”). Das Entscheidende ist das Pflegeprinzip: Die Metadaten leben als Datei im Repository der jeweiligen Komponente und werden vom Catalog eingesammelt. Beim verbreitetsten Open-Source-Portal Backstage ist das die catalog-info.yaml:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout-service
  description: Bezahlvorgang und Warenkorb-Abschluss
  annotations:
    github.com/project-slug: acme/checkout-service
spec:
  type: service
  lifecycle: production
  owner: team-checkout
  system: shop

Warum dieses Prinzip so wichtig ist: Die Information liegt dort, wo das Team ohnehin arbeitet, und wird im normalen Review-Prozess mitgepflegt — statt in einer zentralen Datenbank, die nach drei Monaten veraltet ist (das Schicksal jeder klassischen CMDB). Der Catalog wird damit zur Grundlage für alles Weitere: Incident-Routing („wer wird gerufen?”), Abhängigkeits-Analysen („was bricht, wenn wir X abschalten?”), Tech-Radar-Auswertungen („wie viele Services laufen noch auf der alten Runtime?”) und schlichtes Onboarding.

Die ehrliche Einschränkung: Ein Catalog ist nur so gut wie seine Abdeckung. Bei fünfzig erfassten von dreihundert Services ist er schlimmer als nutzlos — er erweckt den Anschein von Vollständigkeit. Erfolgreiche Einführungen koppeln die Erfassung deshalb an bestehende Abläufe: Neue Services bekommen ihre Catalog-Datei vom Scaffolding automatisch, Bestandsservices werden initial per Skript aus der Repo-Landschaft importiert und dann von den Teams verifiziert.

Scaffolding: der Golden Path zum Anfassen

Scaffolding (bei Backstage: Software Templates) ist die ausführbare Form des Golden Path aus Lektion 5: Ein Entwickler wählt eine Vorlage — „REST-Service (Go)”, „Frontend (React)”, „Daten-Pipeline” —, füllt wenige Parameter aus (Name, Team, Beschreibung) und bekommt in Minuten ein fertiges Fundament: Repository mit Projektstruktur und Beispielcode, CI/CD-Pipeline, Deployment-Konfiguration, Dashboard — und die catalog-info.yaml, womit der neue Service vom ersten Commit an im Catalog steht.

Zwei Design-Punkte entscheiden über den langfristigen Wert:

Wenige, gepflegte Templates statt vieler verwaister. Jedes Template ist ein Wartungsversprechen (dieselbe Logik wie bei der TVP): Es muss mit dem Stand der Plattform mitziehen, sonst erzeugt es ab Tag eins veraltete Services. Drei aktuelle Templates schlagen fünfzehn vergammelte.

Der Tag-2-Effekt ist begrenzt. Scaffolding wirkt bei der Geburt eines Service — was danach mit dem generierten Code passiert, kontrolliert es nicht mehr. Ändert sich der Hausstandard, sind die zweihundert bereits erzeugten Services nicht automatisch aktualisiert. Dieses Drift-Problem ist lösbar (zentral gepflegte Pipeline-Bausteine statt kopierter Pipelines, automatisierte Update-PRs), aber es ist ein eigenes Arbeitsfeld — im Interview zeigt der Hinweis darauf, dass du über die Demo hinausgedacht hast.

Das Portal: Fassade mit genau einem Job

Das Developer Portal ist die Oberfläche, die Catalog, Templates, Dokumentation (idealerweise „Docs-as-Code” aus den Repos gerendert) und Statussichten — Deployments, Pipelines, Dashboards — an einem Ort bündelt. Sein Wert liegt in der Aggregation: Ein Entwickler findet zu einem Service alles Zugehörige auf einer Seite, statt fünf Systeme zu durchsuchen.

Genauso wichtig ist, was das Portal nicht ist: Es ist nicht die Plattform. Provisionieren, Deployen, Policies durchsetzen — das leisten die Schichten darunter (L2/L3 aus Lektion 8); das Portal macht sie sichtbar und auslösbar. Aus dieser Rollenverteilung folgen zwei praktische Konsequenzen: Erstens darf das Portal ausfallen, ohne dass Deployments stehen — es ist Komfort, nicht kritischer Pfad. Zweitens scheitert die beliebte Abkürzung „wir führen mal Backstage ein, dann haben wir eine IDP” zuverlässig: Ein Portal über einer Plattform ohne Self-Service ist ein schöner Katalog ohne Ware — die Klicks führen dann doch wieder zu Ticket-Formularen.

Zur Einordnung der Tool-Landschaft: Backstage (Open Source, von Spotify gestartet, CNCF-Projekt) ist der verbreitetste Unterbau, verlangt aber spürbaren Eigenbetrieb und Anpassungsaufwand; daneben existieren kommerzielle Portal-Produkte mit schnellerem Start — die Abwägung dazu hast du in Lektion 11 gelernt, und Lektion 14 vertieft Backstage im Detail.

Praxis: Catalog-Einträge schreiben und verknüpfen

Diese Übung braucht nur einen Editor:

1. Wähle drei Komponenten eines (realen oder erdachten) Webshops: einen Backend-Service, die API, die er anbietet, und das Frontend, das sie konsumiert.
2. Schreibe für den Backend-Service eine vollständige catalog-info.yaml nach dem Muster oben — mit sinnvollem owner, lifecycle und system.
3. Erweitere sie um die API-Beziehung: Ergänze unter spec das Feld providesApis mit dem Namen deiner API (z. B. providesApis: [checkout-api]). Schreibe dann einen zweiten Eintrag mit kind: API für die API selbst und einen dritten für das Frontend mit consumesApis: [checkout-api].
4. Prüfe dein Modell mit den Fragen vom Anfang der Lektion: Kannst du aus den drei Dateien ablesen, wem was gehört, was von was abhängt und was bricht, wenn die API sich ändert?
5. Zusatz: Skizziere stichpunktartig, welche Dateien dein Scaffolding-Template für einen neuen Backend-Service erzeugen müsste, damit er „catalog-ready” geboren wird.

Wer die Beziehungsmodellierung einmal selbst geschrieben hat, kann sie im Interview erklären — das unterscheidet dich von Kandidaten, die das Portal nur aus Screenshots kennen.

Typische Stolperfallen

Portal einführen und auf Plattform-Wirkung hoffen. Die Fassade ohne Self-Service dahinter erzeugt Frust mit besserer Optik. Erst Delivery- und Service-Schicht, dann (oder parallel) das Schaufenster.

Catalog als Einmal-Befüllung. Ohne Kopplung an Scaffolding und Team-Workflows veraltet der Catalog wie jede CMDB. Pflege muss im normalen Arbeitsfluss passieren, nicht als Sonderaufgabe.

Template-Inflation. Für jeden Sonderfall ein neues Template anzulegen verteilt die Wartungslast, bis keines mehr aktuell ist. Lieber wenige Templates mit klaren Parametern — und Escape Hatches für den Rest.

Ownership ohne Konsequenz. Ein owner-Feld, das nirgends verwendet wird (Incident-Routing, Review-Pflichten, Kosten-Zuordnung), wird nicht gepflegt. Metadaten bleiben nur aktuell, wenn etwas von ihnen abhängt.

Interview-Vorbereitung

Auf „Welche Komponenten hat eine IDP — und wie spielen sie zusammen?” antwortest du am stärksten so: Problem (Discovery- und Ownership-Lücke ab einigen Dutzend Services) → drei Bausteine mit je einem Job (Catalog: was existiert, wem gehört es — als Dateien in den Repos; Scaffolding: richtiger Start in Minuten, erzeugt den Catalog-Eintrag gleich mit; Portal: Aggregation an einem Ort) → Rollenklärung (Portal ist Fassade über den Self-Service-Schichten, nicht die Plattform).

Rechne mit diesen Follow-ups:

• „Warum liegen die Catalog-Daten in den Repos statt in einer zentralen Datenbank?” — Pflege im normalen Review-Workflow der Teams; zentrale Inventare veralten, weil niemand dort arbeitet.
• „Was passiert mit Services, die vor dem Scaffolding entstanden sind?” — Initialer Import per Skript plus Verifikation durch die Teams; ein Catalog mit Lücken ist gefährlicher als gar keiner.
• „Wie hältst du generierte Services aktuell, wenn sich Standards ändern?” — Tag-2-Problem benennen: geteilte Pipeline-Bausteine statt kopierter Konfiguration, automatisierte Update-PRs; Scaffolding allein löst das nicht.
• „Backstage oder kaufen?” — Auf die Build/Buy/Adopt-Kriterien verweisen (Lektion 11): Team-Kapazität und Anpassungsbedarf gegen Time-to-Value; Backstage ist mächtig, aber kein Wochenend-Projekt.

Zusammenfassung

Die Developer-Experience-Schicht einer IDP besteht aus drei Bausteinen mit klar getrennten Jobs: Der Service Catalog beantwortet „was existiert, wem gehört es” — gepflegt als Metadaten-Dateien in den Repos, nicht als zentrale Inventar-Datenbank. Das Scaffolding macht den Golden Path ausführbar und sorgt dafür, dass neue Services standardkonform und catalog-registriert geboren werden. Das Portal aggregiert beides mit Doku und Statussichten — als Fassade über der Plattform, nicht als ihr Ersatz.

Die nächste Lektion nimmt das verbreitetste Portal-Framework auseinander: Backstage im Deep Dive — Architektur, Plugins und was der Betrieb wirklich kostet.