Platform Engineering: Cognitive Load, IDPs & Abstraktionen

In den letzten Jahren hat sich der DevOps-Gedanke (“You build it, you run it”) in vielen Unternehmen als eine gewaltige Herausforderung entpuppt. Entwickler sollen nicht mehr nur exzellenten Java- oder C#-Code schreiben, sondern gleichzeitig Kubernetes-Cluster verwalten, Terraform-Skripte schreiben, CI/CD-Pipelines pflegen und sich um Security-Zertifikate kümmern.

Das Resultat? Ein massiver Anstieg des Cognitive Load (der kognitiven Belastung). Genau hier setzt Platform Engineering an.

1. Das Problem: Cognitive Load

Jeder Mensch hat nur eine begrenzte Kapazität, Informationen im Arbeitsgedächtnis zu behalten. Wenn ein Entwickler-Team 40 % seiner Zeit damit verbringt, Infrastruktur-Fehler zu debuggen oder herauszufinden, wie man eine Datenbank provisioniert, fehlt diese Zeit für das eigentliche Ziel: Das Entwickeln von Business-Features.

Anstatt die Entwickler mit unzähligen Tools und Konzepten aus der Infrastruktur-Welt zu überfluten, muss die Komplexität gebündelt und reduziert werden.

2. Die Lösung: Internal Developer Platforms (IDP)

Platform Engineering löst dieses Problem durch den Aufbau einer Internal Developer Platform (IDP). Eine IDP ist eine intern gebaute, zentrale Plattform, die den Entwicklern als “Golden Path” (Paved Road) dient.

Das Platform-Team behandelt die anderen Entwickler-Teams wie Kunden. Die IDP wird wie ein echtes Produkt entwickelt. Anstatt einem Entwickler zu sagen: “Hier ist dein Kubernetes-Zugang, mach mal”, bietet die IDP Self-Service-Portale an: “Klicke hier, um eine standardisierte, sichere und überwachte PostgreSQL-Datenbank für deinen Microservice zu erhalten.”

3. Die goldene Regel: “Build abstractions, not illusions”

Wenn man eine solche Plattform baut, gibt es eine tödliche Falle: Man versucht, alles zu verstecken. Der renommierte Softwarearchitekt Gregor Hohpe (Autor von The Software Architect Elevator) hat diesen Fehler in einem berühmten Zitat zusammengefasst:

💡 “Build abstractions, not illusions” (Baue Abstraktionen, keine Illusionen).

Aber was genau ist der Unterschied?

❌ Die Illusion (Schlecht)

Eine Illusion versteckt die Komplexität durch reine “Magie”. Sie tut so, als ob schwierige Probleme in verteilten Systemen (wie Netzwerklatenzen, Ausfälle oder Zustandssynchronisation) überhaupt nicht existieren würden.

  • Die Falle: Alles sieht anfangs toll aus (ein “1-Klick-Deployment” für alles). Doch wenn tief unten in der Infrastruktur etwas kaputtgeht (z.B. ein Netzwerk-Timeout), bricht die Illusion in sich zusammen. Der Entwickler steht vor einer kryptischen Fehlermeldung, hat aber keine Ahnung, was unter der Haube passiert, und ist völlig hilflos.

✅ Die Abstraktion (Gut)

Eine Abstraktion versteckt nicht die Realität, sondern bietet ein neues, höherwertiges Vokabular an, um mit der Realität umzugehen.

  • Der Vorteil: Eine gute Abstraktion ist absichtlich “undicht” (leaky). Sie nimmt dem Entwickler zwar 90 % der Standardarbeit ab, erlaubt es ihm aber, bei Bedarf “unter die Haube” zu schauen, Logs zu prüfen und die Infrastruktur zu verstehen, wenn es brennt. Sie reduziert den Cognitive Load, ohne die Entwickler zu entmündigen.

4. Beispiel: Datenbank-Provisionierung

Wie sieht dieser Unterschied in der Praxis aus?

Die Illusion (Magic Platform): Ein Entwickler klickt in einem Web-UI auf “App starten”. Im Hintergrund wird magisch eine App und eine Datenbank erstellt. Der Entwickler hat keine Zugangsdaten zur Datenbank, weiss nicht, auf welchem Host sie läuft, und kann keine Indizes anpassen. Wenn die Datenbank zu langsam wird, muss er ein Ticket beim Platform-Team eröffnen und tagelang warten.

Die Abstraktion (Gute IDP): Der Entwickler nutzt ein zentrales Firmen-Template (z.B. via Backstage oder Terraform-Modul): create-database --size=medium. Die IDP übernimmt das Erstellen der Datenbank, das Setzen der Firewall-Regeln und das Einrichten der Backups (reduzierter Cognitive Load). Der Entwickler behält jedoch den administrativen Lesezugriff, sieht die Metriken in seinem eigenen Dashboard und versteht, dass es sich um eine PostgreSQL handelt. Er ist ermächtigt (empowered), Probleme selbst zu analysieren.

5. Fazit

Platform Engineering rettet Teams vor dem Burnout in der Cloud-Native-Welt. Das Ziel ist es, Entwicklern einen bequemen “Golden Path” anzubieten, von dem sie aber jederzeit abweichen können, wenn sie die Expertise dazu haben.

Eine grossartige Plattform baut auf robusten Abstraktionen auf, die das Leben leichter machen, hütet sich aber davor, durch “Magie” und Illusionen die Kontrolle zu entziehen.

📚 Weiterführende Links & Quellen