Platform Engineering und Internal Developer Platforms

Ein Entwickler tritt einem neuen Team bei.
Bevor er eine einzige Zeile Produktcode schreibt, verbringt er zwei Wochen damit, seine lokale Umgebung einzurichten, Zugang zu den notwendigen Systemen zu sichern, zu verstehen, wie Tests ausgeführt werden, herauszufinden, wie man in Staging deployed, und zu lernen, welchen Slack‑Kanal man nutzen soll, wenn etwas schief geht.
Diese zweitägige Verzögerung ist kein Schulungsproblem, sondern ein Plattform‑Problem, weil die dafür benötigten Werkzeuge und Zugriffswege nicht automatisiert, sondern manuell bereitgestellt werden – ein Prozess, der leicht zu Fehlkonfigurationen führt.

Platform Engineering umfasst den Aufbau und Betrieb der internen Infrastruktur, der Werkzeuge und der Abläufe, die Produktteams befähigen, Software zuverlässig zu liefern, ohne selbst zu Infrastruktur‑Experten zu werden.
Die von Platform‑Engineering‑Teams geschaffene Lösung nennt man Internal Developer Platform (IDP).

Was eine IDP tatsächlich ist

Eine IDP ist kein einzelnes Tool.
Es ist eine kurierte Sammlung von Fähigkeiten wie Provisionierung, CI/CD, Secrets‑Management, Observability und Deployment, die über eine Self‑Service‑Schnittstelle zugänglich sind, die Produktteams ohne Tickets oder Wartezeiten nutzen können, weil sie damit eigenständig Ressourcen anlegen können, ohne auf das Plattform‑Team warten zu müssen.

Das Schlüsselkonzept hier ist Self‑Service. Wenn eine Plattform ein Ticket erfordert, um einen neuen Dienst zu provisionieren, ist es keine Plattform – es ist ein verwalteter Dienst mit zusätzlichen Schritten.
Eine echte Plattform ermöglicht es Entwicklern, einen neuen Dienst zu provisionieren, CI/CD‑Pipelines zu einrichten, Secrets zu konfigurieren und in nur 30 Minuten in Staging zu deployen, wodurch der Release‑Zyklus merklich beschleunigt wird.

IDP-Fähigkeiten (typisch):

Self-Service-Portal (Backstage)
    ├── Dienst-Katalog        - Entdeckung bestehender Dienste, APIs, Dokumentation
    ├── Software-Templates    - Scaffolden neuer Dienste mit goldenen-Pfad-Standardwerten
    ├── Umgebungs-Provisionierung - Erstellen von Dev/Staging-Umgebungen auf Anfrage
    └── Deployment-UI          - Deployment, Rollback, Anzeigen von Logs

CI/CD (GitHub Actions + Argo CD)
    ├── Build-Pipelines        - Lint, Testen, Bauen, Scannen, Image-Pushen
    ├── GitOps-Deployment      - Argo CD synchronisiert Cluster-Zustand aus Git
    └── Progressive Delivery   - Canary, Blue/Green über Argo Rollouts

Infrastruktur (Terraform + Crossplane)
    ├── Cloud-Ressourcen       - Datenbanken, Queues, Speicher via Self-Service
    └── Kubernetes-Namespaces  - Isolierte Umgebungen pro Team/Dienst

Observability (OpenTelemetry + Grafana)
    ├── Auto-Instrumentierung  - Traces und Metriken ohne Team-Aufwand
    └── Basisk-Dashboards      - RED-Metriken für jeden Dienst standardmäßig

Sicherheit (eingebaut, nicht nachgerüstet)
    ├── Image-Scanning         - Trivy in jeder Pipeline
    ├── Secret-Management      - Vault oder AWS Secrets Manager, keine Umgebungsvariablen
    └── Policy-Durchsetzung    - OPA/Kyverno Admission-Controller

Der Golden Path

Der „Golden Path“ ist der vordefinierte und vorkonfigurierte Weg durch die Plattform, der für die meisten Teams in der Mehrheit der Fälle funktioniert.
Es ist nicht der einzige Weg – Teams können abweichen, wenn sie einen guten Grund dafür haben – aber es ist der Weg, der gepflegt, dokumentiert und unterstützt wird, weil er standardisierte Best Practices verkörpert und Fehlkonfigurationen reduziert.

Ein Golden Path für einen neuen Dienst könnte beinhalten:

• ein Service‑Template, das das Repository mit der richtigen Struktur, CI‑Pipeline, Dockerfile und Helm‑Chart scaffoldet;
• eine CI‑Pipeline, die automatisch Lint, Tests, Sicherheits‑Scanning und SBOM‑Generierung ausführt;
• ein GitOps‑Deployment, das Argo CD verwendet, um das Helm‑Chart mit dem Cluster zu synchronisieren;
• Auto‑Instrumentierung für OpenTelemetry‑Traces und ‑Metriken; und
• ein automatisch provisioniertes Basisk‑Dashboard.

Der Entwickler konzentriert sich ausschließlich auf die Geschäftslogik; die Plattform übernimmt das Einrichten, Testen, Scannen und Bereitstellen automatisch.

# Backstage Software-Template: neuen Node.js-Dienst scaffolden
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: nodejs-service
  title: Node.js Microservice
spec:
  parameters:
    - title: Dienst-Details
      properties:
        name:
          type: string
          description: Dienstname (kebab-case)
        owner:
          type: string
          description: Team, das diesen Dienst besitzt

  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}

    - id: publish
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}&owner=myorg

    - id: register
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

Backstage: Der Dienst‑Katalog

Backstage, ein Open‑Source‑Projekt, das ursprünglich von Spotify entwickelt und inzwischen Teil der Cloud Native Computing Foundation (CNCF) ist, bildet die am weitesten verbreitete Basis für IDPs.
Es stellt einen Dienst‑Katalog, Software‑Templates und ein Plugin‑Ökosystem bereit.

Der Dienst‑Katalog ist die unmittelbar wertvollste Komponente. Er beantwortet die Frage, die jeder Ingenieur in einer großen Organisation irgendwann stellt: „Welche Dienste existieren, wer besitzt sie, wo ist die Dokumentation, und wovon hängt dieser Dienst ab?“
Indem er diese Informationen zentral sichtbar macht, spart er langes Suchen und ermöglicht schnelle Fehlersuche.

# catalog-info.yaml - jeder Dienst registriert sich selbst
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-service
  description: Verwaltet Bestellungserstellung, -änderung und -stornierung
  annotations:
    github.com/project-slug: myorg/order-service
    grafana/dashboard-selector: "service=order-service"
spec:
  type: service
  lifecycle: production
  owner: team-commerce
  system: commerce-platform
  dependsOn:
    - component:inventory-service
    - resource:orders-database
  providesApis:
    - order-api

Sobald ein Dienst im Katalog registriert ist, kann ein neuer Ingenieur das gesamte System entdecken, Verbindungen zwischen den Diensten verstehen, Runbooks finden und das besitzende Team erreichen – ohne jemanden fragen zu müssen.

GitOps mit Argo CD

GitOps ist die Praxis, Git als einzige Quelle der Wahrheit für Infrastruktur‑ und Anwendungszustand zu verwenden.
Argo CD ist ein Kubernetes‑nativer GitOps‑Controller, der den Cluster‑Zustand kontinuierlich mit dem in Git deklarierten Sollzustand abgleicht, wodurch jede Änderung nachvollziehbar und automatisiert rückgängig machbar wird.

Entwickler pusht zu main
    ↓
CI-Pipeline: testen → bauen → Image-Pushen → Helm-Werte in Git aktualisieren
    ↓
Argo CD erkennt Git-Änderung
    ↓
Argo CD wendet Helm-Chart auf Cluster an
    ↓
Cluster-Zustand entspricht Git-Zustand

Der Vorteil ist offensichtlich: Auditierbarkeit und Rollback. Jedes Deployment ist ein Git‑Commit. Zurückrollen ist ein Git‑Revert. Der Cluster‑Zustand ist immer in Git inspizierbar, nicht nur im Cluster.

# Argo CD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service
  namespace: argocd
spec:
  project: commerce
  source:
    repoURL: https://github.com/myorg/gitops-config
    targetRevision: HEAD
    path: services/order-service/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: commerce-production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Die „Wie viel Plattform ist genug?“-Debatte

Platform Engineering hat einen Fehlermodus: Über‑Engineering. Ein Plattform‑Team, das eine ausgefeilte IDP baut, die Produktteams nicht verwenden, hat erheblichen Aufwand verschwendet.
Die Plattform muss echte Probleme lösen, die Produktteams tatsächlich haben, nicht Probleme, die das Plattform‑Team interessant findet, weil nur dann messbare Produktivitätsgewinne entstehen.

Der praktische Test ist Adoption. Wenn Produktteams den Golden Path freiwillig verwenden – nicht weil sie dazu verpflichtet sind – liefert die Plattform Werte. Wenn Teams die Plattform umgehen, hat die Plattform ein Usability‑Problem.

Häufige Fehlermodi:

• Zu viel Abstraktion: Die Plattform verbirgt so viel, dass Teams Probleme nicht debuggen können, wenn die Abstraktion undicht wird.
• Zu langsame Weiterentwicklung: Die Plattform wird zum Engpass, weil das Hinzufügen neuer Fähigkeiten ein Ticket an das Plattform‑Team erfordert.
• Die Plattform nicht als Produkt behandeln: Das Plattform‑Team baut, was es denkt, dass Teams brauchen, nicht was Teams tatsächlich anfragen. Produktmanagement‑Disziplin gilt auch für interne Plattformen.

Die richtige Menge an Plattform ist das Minimum, das Produktteams zuverlässig ausliefern lässt, ohne Infrastruktur‑Experten zu werden. Dieses Minimum liegt höher als in den meisten Organisationen heute vorhanden, aber niedriger als das, was manche Plattform‑Teams anstreben.

Warum freiwillige Adoption das einzige zuverlässige Signal ist

Plattform‑Teams messen Erfolg oft an der Anzahl onboardeter Dienste oder ausgelieferter Features. Keines davon ist ein zuverlässiges Signal, weil ein Team durch Richtlinien gezwungen werden kann, eine Plattform zu nutzen, sie aber für kritische Aufgaben umgeht, und weil Features gebaut werden können, die niemand nutzt.
Deshalb ist das freiwillige Nutzen das einzige unverfälschte Barometer.

Freiwillige Adoption ist das einzige Signal, das nicht manipuliert werden kann. Wenn ein Team den Golden Path wählt, weil er schneller und weniger schmerzhaft ist als die Alternative, funktioniert die Plattform. Wenn Teams sie umgehen – eigene CI‑Skripte, eigenes Deployment‑Tooling, eigene Dashboards pflegen – hat die Plattform ein Produktproblem, nicht ein Kommunikationsproblem. Die Lösung ist, mit diesen Teams zu sprechen, zu verstehen, was fehlt, und über einen iterativen Feedback‑Loop die Lücken zu schließen, nicht Adoption zu erzwingen.

Deshalb borgt sich Platform Engineering vom Produktmanagement: Nutzerforschung, Feedback‑Schleifen und Priorisierung basierend auf tatsächlichen Schmerzpunkten statt angenommenen.