Begleitung zur IDP-Page.
Plattform vs Portal — kritische Unterscheidung
- Internal Developer Platform — die Capability-Schicht (Compute, Storage, Networking, Identity, Observability, Deployment-Automatisierung)
- Internal Developer Portal — die UI/Catalog-Schicht (Backstage, Port, Cortex)
Plattform ohne Portal funktioniert. Portal ohne Plattform ist nur Fassade.
Sechs IDP-Muster aus der Produktion
- Multi-Tenant Kubernetes-native Cloud-Plattform — Cozystack
- GitOps-First per-Team Kubernetes — vanilla K8s + Flux
- Service-Template + Golden-Path-Plattform
- PaaS-Lite auf Kubernetes
- Backstage-First mit Capability-Operatoren
- External-Services-as-Platform
Wie wählt man
Je nach Multi-Tenancy-Bedarf, Produkt-Team-Autonomie, Service-Erstellungsrate, Kubernetes-Vertrautheit.
Häufige Fehler
- Mit dem Portal anfangen
- Zu viele Meinungen, zu rigide
- Plattform-Team unterbesetzt
- Vendor-led „Plattform-in-a-Box“
- Für Engineering-Eleganz statt Adoption optimieren
Ænix ist das Team hinter Cozystack.
Wissens-Check: IDP ohne Backstage-Lock-in
5 questions · ~2 min
Question 1 / 5
Worin besteht der entscheidende Unterschied zwischen Plattform und Portal?
Why: Das Kürzel IDP ist überladen: Die Internal Developer Platform ist die Fähigkeitsschicht mit Compute, Storage, Networking, Identität, Observability und Deployment-Automatisierung. Das Internal Developer Portal ist die Oberflächen- und Katalogschicht (Backstage, Port, Cortex). Eine Plattform ohne Portal funktioniert; ein Portal ohne Plattform ist nur Fassade.
Question 2 / 5
Wie viele Produktionsmuster für IDPs beschreibt der Artikel?
Why: Sechs Muster: (1) Multi-Mandanten-Cloud-Plattform auf Kubernetes-Basis (Cozystack), (2) GitOps-First mit Kubernetes je Team, (3) Service-Templates plus Golden Paths, (4) PaaS-Lite auf Kubernetes, (5) Backstage-First mit Capability-Operatoren, (6) External Services as Platform.
Question 3 / 5
Welcher Fehler steht an erster Stelle der Fallstricke?
Why: Erster Fallstrick: mit dem Portal anfangen. Wer Backstage kauft, bevor die darunterliegenden Fähigkeiten wirklich self-service sind, bekommt einen schönen Katalog über demselben betrieblichen Chaos. Die Nutzung bleibt aus.
Question 4 / 5
Welches Muster empfiehlt der Artikel für Service-Provider und Multi-Mandanten-Cloud-Anbieter?
Why: Muster 1 auf Cozystack-Basis: ein Kubernetes-Cluster mit harter Mandantentrennung über das Tenant CRD, KubeVirt für virtuelle Maschinen, Container-Workloads und verwaltete Datenbanken. Die beste Wahl für Service-Provider und Multi-Mandanten-Umgebungen.
Question 5 / 5
Was passiert, wenn das Plattformteam unterbesetzt ist?
Why: Fallstrick 4: Plattformteams, die zugleich die Plattform bauen und die Rufbereitschaft für gemeinsame Dienste tragen, verbringen ihre Zeit mit Tickets. Die Kapazität für die Arbeit an den Golden Paths verschwindet, und die Funktion kommt zum Stillstand.
0 / 5