Der kognitive Aufwand von Terraform und Kubernetes für Anwendungsentwickler

Terraform und Kubernetes sind leistungsstarke Tools. Sie sind aber auch zwei der häufigsten Ursachen für Reibungspunkte zwischen Anwendungsteams und der Infrastruktur, auf die sie angewiesen sind.

Wenn sich die Bereitstellung verlangsamt oder Störungen auftreten, ist man schnell geneigt, das Problem als Qualifikationslücke darzustellen: Entwickler verstehen die Infrastruktur nicht gut genug. In der Praxis geht diese Sichtweise jedoch am Kern der Sache vorbei.

Das eigentliche Problem ist nicht mangelnde Kompetenz. Es ist eine Diskrepanz zwischen denjenigen, für die diese Tools entwickelt wurden, und denjenigen, von denen oft erwartet wird, dass sie sie nutzen. Diese Kluft zwischen dem, wofür Entwickler eingestellt werden, und dem, was von ihnen verlangt wird, verursacht eine kognitive Belastung. Sie verlangsamt die Bereitstellung, erhöht das Risiko und zehrt an der Energie.

Warum Infrastruktur-Tools den Entwicklern Zeit rauben

Die meisten Anwendungsentwickler wollen sich keine Gedanken über die Infrastruktur machen. Aus der Perspektive eines Entwicklers sollte die Infrastruktur einfach vorhersehbar, verfügbar und in allen Umgebungen konsistent sein. Wenn sie in den Hintergrund tritt, arbeiten Teams schneller. Wenn sie Aufmerksamkeit erfordert, lenkt sie den Fokus von der Produktarbeit ab, was sich wiederum auf das Kundenerlebnis auswirkt.

Doch wenn du die meisten Entwickler fragst, wofür sie ihre Zeit tatsächlich aufwenden, wirst du immer wieder dieselben Antworten hören:

• Behebung von fehlgeschlagenen Deploys, die gestern noch funktioniert haben
• Aktualisieren von Terraform-Dateien für kleine Konfigurationsänderungen
• IAM- oder Netzwerkfehler beheben, die sie nicht verursacht haben
• Entwicklungs-, Staging- und Produktionsumgebungen „nahe genug“ halten

Nichts davon trägt zum Produktwert bei. Dennoch erfordert es Konzentration, Kontextwechsel und ständiges Umlernen.

Terraform und Kubernetes verschlimmern dies noch, indem sie von Entwicklern verlangen, explizit über das Verhalten der Infrastruktur nachzudenken. Sie legen Konzepte wie Ressourcenlebenszyklen, Abhängigkeitsgraphen, Netzwerke, Berechtigungen und Fehlerdomänen offen. Nichts davon ist an sich schlecht, aber sie setzen ein mentales Modell voraus, mit dem die meisten Anwendungsentwickler im Alltag nicht arbeiten.

Warum es schwer ist, Terraform und Kubernetes ohne Infrastrukturkontext zu verstehen

Die Schwierigkeit liegt nicht in der Syntax. Es ist die Kausalität. Zu verstehen, was eine Konfigurationsänderung bewirkt, ist nicht dasselbe wie zu verstehen, wann sie gilt, wohin sie sich auswirkt oder was sie sonst noch beeinflussen könnte. Kleine Änderungen können nicht offensichtliche Nebenwirkungen haben, besonders wenn der Zustand über Umgebungen oder Teams hinweg geteilt wird.

Für jemanden, dessen primäres mentales Modell aus Anwendungslogik, Anfragen, Datenfluss und Geschäftsregeln besteht, ist diese Art des Denkens aufwendig. Es erfordert einen Kontextwechsel in einen völlig anderen Bereich, oft unter Zeitdruck.

Anwendungsentwickler haben selten die Zeit oder die Schulung, um diese Tiefe aufzubauen. Also arbeiten sie mit einem unvollständigen Verständnis. Dieses unvollständige Verständnis führt zu vorhersehbaren Ergebnissen:

• Änderungen, die sicher aussehen, aber die Produktion lahmlegen
• Kopierte Konfigurationen, die sich mit der Zeit verschieben
• Angstgetriebene Arbeitsabläufe, bei denen nichts angerührt wird, es sei denn, es ist unbedingt notwendig

Die meisten Ausfälle, die auf diese Weise verursacht werden, sind nicht auf Nachlässigkeit zurückzuführen. Sie entstehen durch Tools, die Infrastruktur-Know-how erfordern, aber von Leuten genutzt werden, die für die Anwendungsentwicklung eingestellt wurden.

 Einen tieferen Einblick, wie sich die Komplexität von Kubernetes aufbaut, findest du unter „Die versteckten Kosten von ‚einfach nur Kubernetes nutzen‘“.

Die versteckten Kosten, wenn man Infrastruktur-Tools in App-Workflows zwingt

Wenn Anwendungsentwickler dazu gedrängt werden, auf der Ebene von Infrastruktur-Primitiven zu arbeiten, passieren ein paar vorhersehbare Dinge.

Teams werden langsamer, nicht weil die Arbeit schwieriger ist, sondern weil jede Änderung zusätzliche Validierung und Nachprüfung erfordert. Entwickler werden vorsichtig. Reviews konzentrieren sich auf Konfigurationsrisiken statt auf die Produktabsicht. Kleine Änderungen fühlen sich schwerer an, als sie sollten.

Mit der Zeit konzentriert sich das Infrastrukturwissen auf wenige Personen. Andere vermeiden es, sich damit zu befassen. Bus-Faktoren nehmen zu. Die Bereitstellung wird unregelmäßig.

Unvollständiges Verständnis führt zu instabilen Systemen

Viele Systemausfälle in der Praxis sind nicht auf unüberlegte Änderungen zurückzuführen. Meistens resultieren sie aus begrenztem Wissen.

Ein Entwickler nimmt eine vernünftige Änderung vor, basierend auf dem lokalen Kontext. Die Konfiguration wird validiert. Die Bereitstellung gelingt. Und doch verhält sich etwas weiter unten in der Kette unerwartet – eine Berechtigungsgrenze wird überschritten, ein Dienst wird neu geplant, eine Ressource wird neu erstellt statt aktualisiert.

Wenn Entwickler gebeten werden, Infrastruktur-Primitives zu verwalten, treten diese Fehlermuster ständig auf:

• Eine kleine Konfigurationsänderung löst eine umfangreiche Neubereitstellung aus
• Eine Umgebung unterscheidet sich geringfügig, aber gerade genug, um Fehler zu verursachen
• Eine Berechtigungskorrektur löst ein Problem und verursacht ein neues
• Eine Staging-Korrektur erreicht nie die Produktivumgebung

Von außen mag das wie Nachlässigkeit aussehen. Von innen ist es meist das Ergebnis subtiler Abstraktionen, die undicht werden.

Das tiefer liegende Problem ist, dass Entwickler gezwungen sind, über zu viele Dinge gleichzeitig nachzudenken. Logik für Features, Infrastruktur-Logik, Deployment-Logik und Umgebungsunterschiede konkurrieren alle um Aufmerksamkeit. Kognitive Überlastung erhöht die Fehlerquote. Das ist menschlich, nicht technisch.

Deshalb reagieren Teams oft auf Vorfälle, indem sie mehr Regeln, mehr Reviews oder mehr Prozesse hinzufügen, anstatt die zugrunde liegende Diskrepanz zu beheben. 

Was Entwickler übernehmen sollten und was nicht

Einige Infrastruktur-Anliegen wirken für Anwendungsteams mittlerweile veraltet:

• Manuelles Erstellen oder Bereinigen von Umgebungen
• Debugging von Konfigurationsabweichungen zwischen den Phasen
• YAML schreiben, um Laufzeitgrundlagen zu beschreiben
• Manuelles Nachbilden von Produktionsbedingungen

Diese Aufgaben bestehen meist nur aus Gewohnheit fort. Moderne Plattformen können sie automatisch bewältigen, mit Leitplanken statt Auswahlmöglichkeiten. Ein „langweiliger“ Workflow ist ein guter: vorhersehbar, wiederholbar und ereignislos.

Die Entlastung der Infrastruktur bedeutet nicht, die Infrastruktur zu ignorieren. Es bedeutet eine Verlagerung der Verantwortung.

Entwickler sollten verantwortlich sein für:

• Anwendungscode
• Laufzeitkonfiguration, die das Verhalten beeinflusst
• Datenmodelle und Migrationen
• Performance auf Code-Ebene

Die Plattform sollte verantwortlich sein für:

• Erstellung und Abbau der Umgebung
• Service-Verbindung und Netzwerk
• Skalierung, Routing und grundlegende Sicherheit
• Konsistenz zwischen Entwicklung, Staging und Produktion

Wenn Infrastruktur-Störgeräusche reduziert werden, ändert sich die Planung. Teams schätzen Features statt Bereitstellungsrisiken ein. Releases werden kleiner und häufiger.

Wie Upsun den kognitiven Aufwand beseitigt

Upsun beseitigt die Infrastrukturlast für Anwendungsentwickler. Anstatt Terraform-Zustände und Kubernetes-Manifeste zu verwalten, definieren Entwickler ihre Anwendung mithilfe von Upsun-Konfigurationsdateien, die zusammen mit ihrem Code gespeichert werden.

Jeder Git-Zweig wird automatisch zu einer vollständigen, isolierten Umgebung: ein vollständiger Klon der Anwendung und ihrer Dienste, einschließlich Konfiguration und Daten. So geht Upsun die spezifischen Probleme an, mit denen Entwickler konfrontiert sind:

• „Behebung fehlgeschlagener Deploys, die gestern noch funktioniert haben“ – Upsun garantiert Umgebungsparität. Die gleiche Konfiguration wird in Entwicklung, Staging und der Produktivumgebung bereitgestellt. Keine Abweichungen, keine Überraschungen. Wenn du eine Umgebung sicherst, erhältst du einen vollständig konsistenten Snapshot deiner gesamten Anwendung.
• „IAM- oder Netzwerkfehler jagen“ – Datenbanken, Caches und Suchmaschinen werden innerhalb des Clusters verwaltet, ohne externe Single Points of Failure. Gib in deiner Konfigurationsdatei an, was du brauchst. Keine IAM-Richtlinien, keine VPC-Konfiguration, keine Sicherheitsgruppenregeln, die du debuggen musst.
• „Entwicklung, Staging und Produktion nah genug beieinander halten“ – Sie sind nicht „nah genug“. Sie sind identisch. Gleiche YAML, gleiche Infrastruktur, gleiches Verhalten. Jede untergeordnete Umgebung kann Code und Daten von ihrer übergeordneten Umgebung synchronisieren, sodass du immer unter realen Bedingungen testest.
• „Angstgetriebene Workflows“ – Mit Sofort-Vorschau-Umgebungen kannst du jede Änderung vor dem Mergen anhand echter Daten aus der Produktivumgebung testen. Mach ruhig Fehler, dann lösch den Branch. Wenn das Experiment vorbei ist, wird durch das Löschen des Branches alles automatisch zurückgesetzt, was Rechenkosten und mentalen Aufwand spart.

Die Upsun-CLI fügt sich nahtlos in bestehende Workflows ein. Befehle wie „upsun push“ und „upsun branch“ erstellen Umgebungen und stellen Änderungen in Sekundenschnelle bereit. GitHub- und GitLab-Integrationen richten automatisch Umgebungen für Pull- und Merge-Anfragen ein. Wenn ein Zweig erstellt wird, entsteht eine Umgebung; wenn der Zweig zusammengeführt wird, wird die Umgebung entfernt.

Am wichtigsten ist vielleicht, dass die Upsun-Konfiguration über die Zeit hinweg stabil bleibt. Es gibt keine Syntaxänderungen zwischen den Versionen, die Umschreibungen oder das erneute Erlernen erfordern. Dein Infrastrukturwissen wächst, anstatt an Wert zu verlieren.

Dieser Wandel – vom Verwalten von Grundlagen hin zum Entwickeln von Produkten – ist es, was Plattformen wie Upsun ermöglichen.