Compute-Abstraktion: Environments statt Raw Cluster

Lernziele

Nach dieser Lektion kannst du erklären, warum Entwickler Environments statt roher Cluster-Konzepte sehen sollten, wie eine Compute-Abstraktion in einer IDP technisch und organisatorisch aussieht und welche Trade-offs zwischen Golden Path und Escape Hatch du bewusst setzt. Du kannst die Abgrenzung zwischen Plattform-Verantwortung und Stream-Team-Autonomie benennen und typische Anti-Patterns bei der Einführung erkennen.

Das Problem: Kubernetes ist kein Developer-Interface

Ein Entwickler will eine Anwendung deployen — nicht Namespace-Quotas verstehen, nicht über Node-Pools diskutieren und nicht wissen, welcher Cluster für Staging zuständig ist. Gibst du ihm direkten Zugang zu kubectl und einer kubeconfig, passiert vorhersehbar Folgendes: Jemand deployt in den falschen Namespace, ein Team bucht sich versehentlich die gesamte Node-Kapazität, und bei jedem Cluster-Upgrade musst du erklären, warum sich API-Versionen geändert haben.

Das ist kein Kompetenzproblem der Entwickler, sondern ein Interface-Problem der Plattform. Kubernetes ist eine Infrastruktur-API, keine Developer Experience. Eine interne Developer Platform braucht deshalb eine Compute-Abstraktion: Entwickler sprechen über Environments (dev, staging, prod), Ressourcen-Tiers (small, medium, large) und Services — die Plattform übersetzt das in Namespaces, Quotas, NetworkPolicies und den richtigen Cluster.

Der Effekt ist messbar: Weniger Cognitive Load beim Onboarding, schnellere Time-to-Production und weniger Tickets beim Platform-Team, weil die häufigsten Fehlkonfigurationen schon in der Abstraktion verhindert sind.

Was die Abstraktionsschicht leisten muss

Eine brauchbare Compute-Abstraktion hat vier Eigenschaften, die du in Interviews und Architektur-Reviews nennen solltest.

Semantische API statt Infrastruktur-API. Der Entwickler sagt environment: staging und tier: medium — nicht namespace: team-checkout-stg mit requests.cpu: 500m. Die Mapping-Tabelle liegt beim Plattform-Team und kann sich ändern, ohne dass hundert Teams ihre Manifeste anfassen.

Self-Service mit Guardrails. Das Environment wird per Portal, CLI oder Scaffolder angefordert — nicht per Ticket. Gleichzeitig greifen Policy-as-Code, Quotas und Security-by-Default: kein privileged, kein hostPath, Netzwerk-Isolation zwischen Tenants. Die Abstraktion ist schnell und kontrolliert.

Multi-Cluster-Transparenz. In größeren Organisationen laufen Staging und Produktion auf verschiedenen Clustern oder Cloud-Accounts. Die Abstraktion versteckt das: prod ist immer prod, egal ob dahinter ein EKS-Cluster in eu-central-1 oder ein On-Prem-Cluster steht. Der Entwickler braucht keine Cluster-Liste.

Escape Hatch. Manche Teams brauchen GPU-Nodes, spezielle Taints oder direkten API-Zugang. Ein dokumentierter Ausweg — mit Genehmigung und Audit — verhindert, dass die Abstraktion zum Gefängnis wird. Ohne Escape Hatch migrieren Power-User heimlich weg; mit zu vielen Ausnahmen hast du keine Abstraktion mehr.

Plattform-Team vs. Stream-Team: Wer macht was?

Die Grenze muss schriftlich festliegen, sonst eskaliert jedes Incident in ein Zuständigkeitsstreit.

Das Plattform-Team besitzt die Compute-Schicht: Cluster-Lifecycle, Node-Pools, die Environment-Definitionen, Quota-Modelle, Netzwerk-Topologie und das Provisioning (Crossplane, Cluster API, Terraform — das Werkzeug ist sekundär). Es garantiert, dass ein angefordertes Environment in definierter Zeit existiert und die eingebauten Policies greifen.

Das Stream-Team besitzt den Workload: Container-Image, Replikas, Environment-Variablen, Ingress-Hostnamen innerhalb der erlaubten Konvention. Es wählt ein Tier, nicht die CPU-Milliwert-Zuordnung. Wenn die App nicht startet, liegt die Ursache meist beim Team; wenn das Environment nicht provisioniert wird, liegt sie bei der Plattform.

Ein praktisches Trennungskriterium: Kann das Stream-Team die Remediation ohne Cluster-Admin-Rechte ausführen? Wenn nein, ist es Plattform-Arbeit.

Golden Path und die 80-Prozent-Regel

Der Golden Path ist das vorkonfigurierte Environment-Template, das für die meisten Teams reicht: Namespace mit Quota, Standard-NetworkPolicy, vorkonfiguriertes ServiceAccount, Anbindung an die zentrale Observability und Secrets-Integration. Ein neues Team wählt im Portal „Web-Service, Staging, Medium” und bekommt in Minuten ein lauffähiges Ziel — inklusive Anbindung an das Workload-Chart aus Lektion 30.

Die 80-Prozent-Regel ist entscheidend: Das Template deckt die Standardfälle ab, nicht jeden Sonderfall. Wer versucht, die Abstraktion so flexibel zu machen, dass sie jeden Workload-Typ abbildet, baut ein zweites Kubernetes — nur langsamer und schwerer wartbar. Spezialfälle bekommen eigene Templates oder den Escape Hatch, nicht mehr Optionsfelder im Standard-Formular.

Praxis: Environment-Request durchspielen

Nimm ein konkretes Szenario: Team „Checkout” braucht ein Staging-Environment für einen neuen Microservice.

1. Request: Über Portal oder CLI — environment create --name checkout-api --tier medium --env staging.
2. Validierung: Policy prüft Team-Berechtigung, Quota-Budget, Naming-Konvention.
3. Provisioning: Controller legt Namespace an, setzt ResourceQuota, NetworkPolicy, RBAC und registriert das Environment im Service-Katalog.
4. Auslieferung: Team erhält Endpoint, Namespace-Name und eine Values-Vorlage für das Standard-Chart.
5. Deploy: GitOps-Pipeline deployt ins provisionierte Environment — der Entwickler hat keinen direkten Cluster-Zugang gebraucht.

Prüfe danach bewusst die Metriken: Wie lange dauerte Provisioning? Musste jemand manuell eingreifen? Würde ein Entwickler ohne Kubernetes-Erfahrung den Flow verstehen? Genau diese Fragen entscheiden, ob die Abstraktion trägt.

Typische Stolperfallen

Abstraktion ohne Observability: Wenn ein Environment „hängt”, sieht der Entwickler nur einen Spinner im Portal — ohne Events, ohne Status-API, ohne klare Fehlermeldung. Jede Abstraktion braucht eigene Metriken: Provisioning-Dauer, Fehlerrate, Queue-Länge.

Leaky Abstraction: Sobald Entwickler regelmäßig nach „dem echten Namespace-Namen” fragen oder Cluster-Kontexte wechseln müssen, ist die Abstraktion durchlässig. Das ist kein Edge Case, sondern ein Designfehler.

Ticket statt Self-Service: Ein Portal, das nur ein Ticket erzeugt, ist kein Self-Service — es ist ein Webformular für das Platform-Team. Der Unterschied zeigt sich in der Provisioning-Zeit und der Skalierung.

Escape Hatch ohne Governance: Direkter Cluster-Zugang für alle „Power-User” untergräbt Quotas und Policies. Jeder Ausweg braucht Genehmigung, Zeitlimit und Audit-Log.

Interview-Vorbereitung

Auf „Was ist Compute-Abstraktion?” antwortest du: Problem (Kubernetes-API ist kein Developer-Interface, Cognitive Load und Fehlkonfiguration skalieren mit Teamzahl) → Lösung (semantische Environment-API mit Self-Service und Guardrails) → Grenze (Golden Path für 80 %, dokumentierter Escape Hatch für den Rest) → Ownership (Plattform besitzt Compute, Teams besitzen Workloads).

Follow-ups:

• „Wie versteckst du Multi-Cluster?” — Environment-Namen als stabile API, Cluster-Mapping intern, Routing über DNS oder Service-Mesh.
• „Golden Path vs. Flexibilität?” — Standard-Template für Geschwindigkeit und Compliance; Ausnahmen genehmigt und begrenzt, nicht als Default.
• „Wie misst du Erfolg?” — Provisioning-Zeit, Self-Service-Adoption, Ticket-Reduktion, Developer-Satisfaction.

Zusammenfassung

Compute-Abstraktion übersetzt Kubernetes in eine Developer-API: Environments, Tiers und Self-Service statt Namespaces, Quotas und Cluster-Kontexte. Das Plattform-Team besitzt die Schicht und eingebaute Guardrails; Stream-Teams deployen Workloads ohne Infrastruktur-Expertise. Der Golden Path deckt die Standardfälle, ein kontrollierter Escape Hatch die Sonderfälle. Ohne Observability der Provisioning-Pipeline und klare Ownership-Grenzen wird die Abstraktion zum undurchsichtigen Bottleneck.

In der nächsten Lektion geht es darum, was passiert, wenn die Anwendung läuft, aber niemand sieht, wie sie läuft: Observability als Self-Service-Capability für jeden Tenant.