Platform Engineering einführen: ab wann sich ein Plattformteam lohnt

# Wie lange liegen Infrastrukturanfragen im Ticketsystem?
glab api "projects/:id/issues?labels=infra&state=closed&per_page=100" \
  | jq -r '.[] | [.iid, .created_at, .closed_at] | @tsv'

# Wie oft liefern die Teams aus, und wie lange dauert ein Lauf?
gh api repos/acme/order-api/actions/runs --paginate \
  | jq -r '.workflow_runs[] | [.created_at, .conclusion] | @tsv' | head -50

# Wie viele Workflow-Dateien gibt es, und wie viele Varianten stecken darin?
gh search code 'runs-on' --owner acme --extension yml --json repository,path --limit 200

Vier Zahlen reichen für den Anfang: mittlere Liegezeit einer Infrastrukturanfrage, Anzahl der Auslieferungen pro Team und Monat, Zeit von der ersten Zeile bis zur laufenden Umgebung und Anzahl der Pipeline-Varianten. Diese vier Werte sind später auch der Nachweis, dass die Plattform wirkt.

Aus den Antworten entsteht die erste Version, und die fällt fast immer kleiner aus als geplant. In der Regel lösen zwei Dinge den größten Teil der Reibung: ein neuer Dienst ohne Ticket und ein einheitlicher Weg von Git in die Umgebung. Welcher Auslieferungsweg dabei passt, behandelt Argo CD oder Flux.

npx @backstage/create-app@latest --path internal-portal
cd internal-portal
yarn install
yarn start   # Oberfläche auf Port 3000, Backend auf Port 7007

Die erzeugte Anwendung ist ein eigenes Repository, kein fertiges Produkt. Authentifizierung, Katalogquellen und Plugins kommen von dir. Plane das als laufende Arbeit ein, nicht als einmalige Einrichtung, sonst steht nach einem halben Jahr ein veraltetes Portal ohne Pflege.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-api
  description: Bestellannahme für den Shop
  annotations:
    github.com/project-slug: acme/order-api
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-orders
  system: shop

Das Feld owner ist das wichtigste der Datei. Ein Katalog ohne verbindliche Eigentümerschaft beantwortet genau die Frage nicht, die im Zwischenfall wirklich gestellt wird, nämlich wen man um drei Uhr nachts erreicht.

helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
helm install crossplane crossplane-stable/crossplane \
  --namespace crossplane-system --create-namespace

kubectl get pods -n crossplane-system
kubectl get providers
kubectl get compositions
kubectl get managed          # alle vom Cluster verwalteten Ressourcen

Crossplane verlagert die Infrastrukturbeschreibung in den Cluster. Der Gewinn ist ein einheitlicher Weg für Anwendung und Infrastruktur, der Preis ist, dass der Cluster damit deutlich kritischer wird als vorher. Wer Terraform bereits sauber im Griff hat, gewinnt durch den Wechsel wenig.

Welches Werkzeug den Unterbau bildet, ist eine eigene Entscheidung mit langer Bindung. Die Abwägung zwischen Terraform, OpenTofu und den anbietereigenen Sprachen steht unter Infrastructure as Code im Vergleich, und wie sich Terraform und Ansible die Arbeit teilen, zeigt Terraform oder Ansible. Wenn die Plattform auf einem Cluster aufsetzt, gehört vorher die Frage geklärt, ob dieser Cluster überhaupt nötig ist: Brauche ich Kubernetes?

# Wie viele Dienste laufen über den gemeinsamen Auslieferungsweg?
kubectl get deployments -A \
  -l app.kubernetes.io/managed-by=Helm \
  --no-headers -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name | wc -l

# Wie viele Katalogeinträge haben keinen Eigentümer?
curl -s -H "Authorization: Bearer $PORTAL_TOKEN" \
  https://portal.intern.example/api/catalog/entities \
  | jq '[.[] | select(.spec.owner == null)] | length'

Beide Werte gehören auf ein Dashboard, das auch die Produktteams sehen. Sichtbarkeit wirkt hier stärker als jede Vorgabe: Sobald eine Liste zeigt, welche Dienste ohne Eigentümer laufen, trägt sich der Großteil innerhalb weniger Wochen von selbst ein.