Schlagwort: Developer Experience

Veröffentlicht am

Internal Developer Portals: Backstage, Port.io und der Weg zur Self-Service-Plattform

Platform Engineering: Der Megatrend 2026

Die Zeiten, in denen Entwickler Tickets schreiben und tagelang auf Infrastruktur warten mussten, sind vorbei. Internal Developer Portals (IDPs) sind das Herzstück moderner Platform Engineering Teams — sie ermöglichen Self-Service bei gleichzeitiger Governance.

Die Kandidaten im Vergleich

Backstage (Spotify)

Das Open-Source-Schwergewicht von Spotify hat sich als De-facto-Standard etabliert:

  • Software Catalog — Zentrale Übersicht aller Services, APIs und Ressourcen
  • Tech Docs — Dokumentation direkt im Portal
  • Templates — Golden Paths für neue Services
  • Plugins — Erweiterbar durch große Community

Stärke: Flexibilität und Community. Schwäche: Hoher Aufwand für Setup und Maintenance.

Port.io

Die SaaS-Alternative für Teams, die schnell produktiv sein wollen:

  • No-Code Builder — Portal ohne Entwicklungsaufwand
  • Self-Service Actions — Day-2 Operations automatisiert
  • Scorecards — Production Readiness auf einen Blick
  • RBAC — Enterprise-ready Zugriffskontrolle

Stärke: Time-to-Value. Schwäche: Weniger Flexibilität als Open Source.

Cortex

Der Fokus liegt auf Service Ownership und Reliability:

  • Service Scorecards — Qualitätsstandards durchsetzen
  • Ownership — Klare Verantwortlichkeiten
  • Integrations — Tiefe Anbindung an Monitoring-Tools

Stärke: Reliability Engineering. Schwäche: Weniger Developer Experience Fokus.

Software Catalogs: Das Fundament

Ein IDP steht und fällt mit seinem Catalog. Die Kernfragen:

  • Was haben wir? — Services, APIs, Datenbanken, Infrastruktur
  • Wem gehört es? — Service Ownership muss klar sein
  • Was hängt wovon ab? — Dependency Mapping für Impact Analysis
  • Wie gesund ist es? — Scorecards für Qualitätsstandards

Production Readiness Scorecards

Statt „das sollte man eigentlich haben“ zu sagen, machen Scorecards Standards messbar:

Service: payment-api
━━━━━━━━━━━━━━━━━━━━
✅ Documentation    [100%]
✅ Monitoring       [100%]
⚠️  On-Call Rotation [ 80%]
❌ Disaster Recovery [ 20%]
━━━━━━━━━━━━━━━━━━━━
Overall: 75% - Bronze

Teams sehen auf einen Blick, wo Handlungsbedarf besteht — ohne dass jemand mit dem Finger zeigen muss.

Integration ist alles

Ein IDP ist nur so gut wie seine Integrationen:

  • CI/CD — GitHub Actions, GitLab CI, ArgoCD
  • Monitoring — Datadog, Prometheus, Grafana
  • IaC — Terraform, Crossplane, Pulumi
  • Ticketing — Jira, Linear, ServiceNow
  • Cloud — AWS, GCP, Azure native Services

Der kulturelle Shift

Die größte Herausforderung ist nicht technisch — es ist der Wandel von Gatekeeping zu Enablement:

Alt (Gatekeeping) Neu (Enablement)
„Schreib ein Ticket“ „Nutz das Portal“
„Wir prüfen das“ „Policies sind automatisiert“
„Dauert 2 Wochen“ „In 5 Minuten ready“
„Nur wir dürfen das“ „Du kannst, wir helfen“

Getting Started

Der pragmatische Weg zum IDP:

  1. Start small — Ein Software Catalog ist schon wertvoll
  2. Pick your battles — Nicht alles auf einmal automatisieren
  3. Measure adoption — Portal-Nutzung tracken
  4. Iterate — Feedback der Entwickler ernst nehmen

Platform Engineering ist kein Produkt, das man kauft — es ist eine Capability, die man aufbaut. IDPs sind dabei das sichtbare Interface zu dieser Capability.