Platform Engineering mit Backstage: Aufbau von Internal Developer Portals

Platform Engineering ist die Disziplin des Aufbaus interner Entwicklerplattformen (Internal Developer Platforms, IDPs), die die kognitive Belastung von Entwicklungsteams reduzieren und gleichzeitig organisatorische Standards für Sicherheit, Compliance und Betrieb aufrechterhalten. Im Jahr 2026 hat sich Backstage – ursprünglich von Spotify entwickelt und mittlerweile ein CNCF-graduated Projekt – zum De-facto-Standard für den Aufbau von IDPs entwickelt.

Dieser Leitfaden behandelt die Architektur, die Implementierung und die operationalen Muster für den Betrieb von Backstage in der Produktion.

Warum Platform Engineering

Das zentrale Problem, das Platform Engineering löst, ist die wachsende Komplexität der modernen Software-Delivery-Infrastruktur. Ein typisches Entwicklungsteam interagiert im Jahr 2026 mit Kubernetes, CI/CD-Pipelines, Observability-Stacks, Secret-Management, Feature-Flags, Datenbank-Provisionierung, Service-Meshes und Cloud-SDKs. Jedes dieser Tools hat seine eigene Benutzeroberfläche, API und Konfigurationsmodelle.

Eine IDP abstrahiert diese Komplexität hinter einer konsistenten Schnittstelle. Entwickler interagieren mit einem einzigen Portal, um Services zu erstellen, Änderungen bereitzustellen, den Produktionsstatus einzusehen, Secrets zu verwalten und auf Dokumentationen zuzugreifen. Das Platform-Team wartet die zugrunde liegende Infrastruktur und setzt die organisatorischen Standards durch.

Backstage-Architektur

Die Architektur von Backstage basiert auf drei Kernkonzepten:

Software Catalog

Der Katalog ist das zentrale Inventar von Backstage für alle Softwarekomponenten: Services, Bibliotheken, Websites, Pipelines, Datenbanken und Infrastruktur. Jede Entität wird durch einen YAML-Deskriptor (catalog-info.yaml) beschrieben, der zusammen mit dem Quellcode gespeichert wird:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: my-service
  description: User-facing API service
  annotations:
    backstage.io/techdocs-ref: dir:.
    github.com/project-slug: org/my-service
spec:
  type: service
  lifecycle: production
  owner: team-backend
  system: user-platform
  dependsOn:
    - component:postgres-primary
    - resource:redis-cluster

Software Templates

Templates automatisieren die Erstellung von Services unter Anwendung integrierter Best Practices. Ein Entwickler füllt ein Formular aus, und Backstage generiert das Repository mit vorkonfiguriertem CI/CD, Monitoring und Dokumentation:

apiVersion: backstage.io/v1beta1
template: true
metadata:
  name: production-service-template
  title: Production Go Service
  description: Go HTTP service with OpenTelemetry, structured logging, and Kubernetes deployment
spec:
  parameters:
    - title: Service Details
      properties:
        name:
          title: Service Name
          type: string
        owner:
          title: Team
          type: string
  steps:
    - id: template
      name: Scaffold Repository
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}
    - id: register
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}/catalog-info.yaml

TechDocs

TechDocs generiert Dokumentationen aus Markdown-Dateien im Repository, die in Backstage mit Suche, Navigation und Versionsverfolgung gerendert werden. Dies löst das Problem des „Documentation Drift“: Die Dokumentation lebt zusammen mit dem Code und wird bei jeder Änderung neu generiert.

Production Deployment

Ein produktives Backstage-Deployment erfordert:

• PostgreSQL für den Zustand von Katalog und Templates
• Redis für Caching und Session-Management
• Elasticsearch für die Suchindizierung von TechDocs
• CI/CD-Integration mit GitHub/GitLab für die Ausführung von Templates
• Authentifizierung via OAuth2, OIDC oder SAML

Operational Patterns

Golden Paths

Definieren Sie Golden-Path-Templates für gängige Service-Typen: Go HTTP-Service, Python-Datenpipeline, React-Frontend, Node.js-API. Jeder Golden Path kodiert organisatorische Standards für Logging, Metriken, Tracing, Health-Checks und Deployment.

Service Ownership

Jede Komponente im Katalog muss einen Eigentümer haben. Wenn der Katalog eine komponentenlose Komponente erkennt, wird das Platform-Team benachrichtigt. Ownership ist essenziell für die Incident-Response – der On-Call-Engineer muss wissen, wen er benachrichtigen muss.

Scorecards

Scorecards messen die Reife von Services über Dimensionen wie Dokumentationsabdeckung, Testabdeckung, Deployment-Frequenz und Sicherheitsstatus. Teams können ihren Score im Verhältnis zu den organisatorischen Zielen sehen.

Produktionsstatistiken

Organisationen, die Platform Engineering mit Backstage implementieren, berichten von:

• 40-60 % Reduzierung der Time-to-Production für neue Services
• 3- bis 5-facher Steigerung der Developer-Satisfaction-Scores
• 80 % Reduzierung von Configuration Drift
• Zentralisierter Sichtbarkeit über alle Services und Teams hinweg

Erste Schritte

Deployen Sie Backstage via Helm auf Kubernetes:

helm repo add backstage https://backstage.github.io/charts
helm install backstage backstage/backstage \
  --set postgresql.enabled=true \
  --set appConfig.backend.database.client=pg \
  --set appConfig.organization.name=MyOrg

Die Ersteinrichtung nimmt einen Tag in Anspruch. Die laufenden Investitionen fließen in die Kuration von Templates, die Katalogpflege und die Weiterentwicklung der Plattform – ein dediziertes Plattform-Team von 3 bis 5 Engineers unterstützt in der Regel 50 bis 200 Entwickler.