Das Kürzel „IDP“ ist mehrfach belegt. Es steht für beides:
- Internal Developer Platform — den zugrunde liegenden Capability-Stack (Kubernetes, IaC, Observability, Golden Paths).
- Internal Developer Portal — die UI-/Katalogebene (Backstage, Port, Eigenbau).
Die meisten Diskussionen werfen beides durcheinander. Die eigentliche Frage — „Brauchen wir Backstage?“ — hat unterschiedliche Antworten, je nachdem, von welcher IDP die Rede ist.
Plattform vs. Portal
Eine Plattform ohne Portal funktioniert trotzdem. Ein Portal ohne Plattform ist Tapete.
Die Plattform beantwortet: „Welche Fähigkeiten können Produktteams per Self-Service nutzen?“
- Bereitstellung von Umgebungen
- Anwendungs-Deployment
- Bereitstellung von Datenbanken, Queues und Caches
- Onboarding in die Observability
- Secrets, Identity, Netzwerkzugang
Das Portal beantwortet: „Wie finden Produktteams diese Fähigkeiten und wie greifen sie darauf zu?“
- Servicekatalog
- Einstiegspunkt in die Dokumentation
- Self-Service-Formulare und -Aktionen
- Kosten- und SLO-Dashboards pro Service
Ohne Plattform funktioniert Self-Service nicht. Das Portal wird für die Auffindbarkeit gebraucht, sobald die Zahl der Services über das hinauswächst, was Teams im Kopf behalten können.
Wann Sie ein Portal brauchen
Ein Portal wird wertvoll, wenn:
- die Zahl der Services groß ist — 50+ Services, bei denen Engineers den Überblick verlieren.
- das Team groß ist — viele Engineers, von denen sich viele auf der Plattform noch nicht sicher bewegen.
- teamübergreifende Service-Discovery real ist — Engineers aus Team A nutzen Services von Team B.
- Compliance oder Audit einen Servicekatalog verlangen — ein Serviceinventar, das der Aufsicht standhält.
Trifft nichts davon zu (kleine Organisation, wenige Services, routiniertes Plattformteam), verursacht ein Portal Wartungsaufwand ohne nennenswerten Nutzen.
Portal-Optionen im Vergleich
Backstage (CNCF Incubating)
Was: Open-Source-Servicekatalog plus Plugin-Ökosystem. Ursprünglich von Spotify entwickelt, heute bei der CNCF.
Stärken: Ausgereift, breites Plugin-Ökosystem, anpassbar, starke Community.
Schwächen: Die Betriebskosten sind real — Backstage zu betreiben heißt, Plugins zu pflegen, interne Tools anzubinden und mit dem Release-Rhythmus von Backstage Schritt zu halten. Viele Anwender unterschätzen das.
Am besten für: Mittlere bis große Engineering-Organisationen (200+ Engineers) mit genug Kapazität im Plattformteam, um Backstage als Produkt zu pflegen.
Port (port.io)
Was: SaaS-Internal-Developer-Portal.
Stärken: Kein Selbstbetrieb; schneller ausgerollt als Backstage; mit klaren Vorgaben.
Schwächen: Abhängigkeit von SaaS (mit Folgen für die Souveränität); weniger anpassbar als Backstage.
Am besten für: Mittelgroße Organisationen, die SaaS nutzen wollen und sich die Betriebskosten von Backstage sparen möchten.
Cortex / Compass / Eigenbauvarianten
Verwandte Optionen mit anderen Abwägungen. Cortex konzentriert sich auf Engineering-Effektivität; Compass ist Atlassian-nativ; Eigenbau heißt „selbst bauen“.
Kein Portal
Was: IaC-Repository plus Markdown-Dokumentation plus GitOps-Schnittstelle.
Stärken: Keine Betriebskosten über Git hinaus. Kein portalspezifischer Wartungsaufwand.
Schwächen: Die Auffindbarkeit skaliert ab 30–50 Services schlecht.
Am besten für: Kleinere Organisationen (unter ~100 Engineers), in denen die Kosten eines Portals seinen Nutzen übersteigen würden.
Wo Backstage tatsächlich am besten passt
Backstage funktioniert gut, wenn:
- es 200+ Engineers und 100+ Services gibt
- das Plattformteam 5+ Engineers hat, die Zeit für die Pflege aufbringen können
- das Plugin-Ökosystem zu Ihrem Tooling passt
- Anpassbarkeit eine Priorität ist (Sie werden Plugins schreiben oder erweitern)
Trifft das nicht zu, übersteigen die Betriebskosten den Nutzen, und eine leichtgewichtigere Option passt besser.
CNOE — die Open-Source-Referenz für Platform Engineering
Die Brancheninitiative CNOE (Cloud Native Operational Excellence) verdient Erwähnung. Es ist eine Referenzarchitektur mit klaren Vorgaben, die Backstage, Argo CD, Crossplane, External Secrets und weitere CNCF-Tools zu einem stimmigen Plattformmuster verbindet. Für Organisationen, die eine „Plattform aus der Box“ aus CNCF-Projekten wollen, ist CNOE der strukturierte Ausgangspunkt.
CNOE ergänzt Cozystack: CNOE konzentriert sich auf das Developer Portal und die Tooling-Ebene; Cozystack auf die darunterliegende mandantenfähige, Kubernetes-native Plattform mit Virtualisierung. Beide können nebeneinander bestehen.
Wie Sie entscheiden
Ein praktischer Entscheidungsbaum:
- Haben Sie darunter eine funktionierende Plattform? Wenn nein, bauen Sie zuerst diese. Die Adoption eines Portals setzt voraus, dass es eine Plattform gibt.
- Mehr als 50 Services? Mehr als 100 Engineers? Wenn ja, hilft ein Portal. Wenn nein, ist ein Portal Over-Engineering.
- Sind die Betriebskosten von Backstage realistisch tragbar? Wenn ja (großes Team, Plugin-freundliche Kultur), Backstage. Wenn nein, Port oder Cortex.
- Ist SaaS akzeptabel? Wenn ja, Port oder Cortex. Wenn nein, Backstage oder Eigenbau.
- Werden Sie tatsächlich anpassen? Wenn ja, Backstage. Wenn nein, Port.
Die Entscheidung ist kleiner, als Hersteller sie darstellen. Die größere Architekturentscheidung ist die Plattform darunter.
Wissens-Check: Portal vs. Plattform (und Backstage)
5 questions · ~2 min
