Umschulung für die Zukunft: Warum Entwickler und Infrastrukturprofis ihre Komfortzone verlassen müssen

Matthew Finio: Wie verändert sich die Beziehung zwischen Entwicklern und Infrastrukturexperten?

Miha Kralj: Mit dem Aufkommen von „Software-defined Everything“ – Software-defined Networking, Software-defined Storage, Software-defined Computing – hat sich die gesamte Entwicklungsbranche verändert.

In der Vergangenheit hatten wir die Leute für die Infrastruktur auf der linken Seite und die Leute für die Softwareentwicklung auf der rechten Seite und sie sprachen kaum miteinander. Eine war für die Versorgung aller zugrundeliegenden Asset und Anlagen zuständig, und die andere war für die gesamte Codierung zuständig, um „Träume wahr werden zu lassen“.

Jetzt bricht all das zusammen. Keine der beiden Seiten ist auf das Zeitalter vorbereitet, in dem wir jetzt leben. Und keiner von beiden versteht etwas von Sicherheit, also können wir auch das mit einbeziehen. Sie müssen anfangen, voneinander zu lernen, und das ist für beide Seiten schwierig.

Es ist wie in dem Buch Who Moved My Cheese – keine der beiden Seiten fühlt sich wohl, wenn sie aus der alten traditionellen Welt kommen. Die jüngeren Generationen, die mit Google Mail und YouTube aufgewachsen sind, leben in dieser neuen, kombinierten Welt. Aber Leute, die von der traditionellen Infrastruktur- oder Entwicklungsseite kommen, haben es schwer, weil sie die andere Seite in den ersten Jahren ihrer Karriere nicht kennengelernt haben.

MF: Also sollten sowohl Entwickler als auch Infrastrukturverantwortliche ihre Stellenbeschreibungen überdenken?

MK: Genau. Entwickler sollten nicht länger denken, dass sie nur Anwendungsentwickler sind. Infrastrukturmitarbeiter sollten nicht länger denken, dass sie nur für den Betrieb zuständig sind. Hier kommen die modernen Teaming-Konstrukte von Produktentwicklungsumgebungen zum Tragen, in denen jeder bei Bedarf die Arbeit eines anderen erledigen kann. Es gibt immer noch Spezialisierungen, aber ein Entwickler muss bei Bedarf in der Lage sein, ein Terraform-Skript zu schreiben, was traditionell eine sehr infrastrukturorientierte Aufgabe wäre.

Wenn Sie also jemanden fragen, was sein Job ist, sollte er nicht sagen: „Ich bin ein Softwareentwickler“ oder „Ich bin ein Infrastruktur-/Betriebsmensch“. Sie alle bauen ein Produkt auf oder helfen bei der Entwicklung eines Dienstes, und dieser wird niemals auf den Markt kommen, wenn nicht all diese Teile richtig zusammengefügt sind. Jeder muss die gesamte Kette verstehen, den gesamten Lebenszyklus, alles von unten nach oben.

MF: Sie haben Terraform angesprochen. Welche anderen Infrastrukturkonzepte müssen Entwickler erlernen?

MK: Entwickler verstehen oft nicht genau, wie die zugrunde liegende Infrastruktur wirklich funktioniert und was dauerhaft und was kurzlebig sein kann.

Wenn Sie beispielsweise eine Änderung am Host oder Container oder an der serverlosen Komponente vornehmen, auf der etwas ausgeführt wird, bleibt diese Änderung dann bestehen, wenn diese Komponente, diese virtuelle Maschine woanders hin springt? Das Konzept von Systemen, die ihre Zustände an einem anderen Ort speichern, zustandslose Systeme, ist also einer der Vorläufer, den Entwickler verstehen können. Wie macht man es unbegrenzt skalierbar? Wie stellt man sehr langlebige und elastische Systeme her? All diese architektonischen Konzepte werden in Software implementiert, basieren aber tatsächlich auf Infrastrukturmustern.

Außerdem lohnt es sich, alle Sicherheitsmuster zu verstehen, wie man eine minimale Oberfläche im Code schafft, die die geringste Angriffsmöglichkeit bietet. Und wie man richtig mit einem Fernservice kommuniziert. Werden Sie einen kleinen Plauderdienst schreiben, der jede Sekunde hundert kleine Plauderfragen über die Leitung schickt? Oder möchten Sie alle Anfragen bündeln und sie in größeren Paketen und seltener senden?

Das sind superwichtige Entscheidungen, die jeder Softwareentwickler treffen muss, aber sie werden nicht verstehen, warum sie sie treffen, wenn sie nicht verstehen, was unter der Haube passiert – wie die Systeme tatsächlich funktionieren. Dieses Verständnis des Systems von unten nach oben ist entscheidend. Der Entwickler muss guten, sauberen Code schreiben, der das System nicht blockiert, der die Datenbank nicht sperrt und der keine schlechten Dinge tut.

Wenn Sie 20 oder 30 Jahre zurückgehen, gab es einen speziellen Beruf, der sich mit der Optimierung von Datenbankabfragen für die minimale Anzahl von CPU-Zyklen und das minimale Sperren von Daten beschäftigte. Viel von diesem geheimnisvollen Wissen ist verloren gegangen. Aber es ist immer noch super wichtig zu verstehen, wie man ein Hochleistungssystem und ein kostenoptimiertes System erstellt. All diese Lektionen sollten nicht vergessen werden.

Sie denken: „Oh, hey, wir sind im Jahr 2025, alter Mann, setzen Sie sich! Die moderne Welt ist völlig anders. Sie haben keine Ahnung!“ Nun, wir haben diese moderne Welt aufgebaut, und wir sind hier, um den neuen Entwicklern und den neuen Mitarbeitern der Infrastruktur zu helfen, sie so effizient wie möglich zu nutzen.

MF: Können Sie beschreiben, wie Entwickler Infrastruktur-als-Code-Tools nutzen können, um ihren Workflow zu verbessern?

MK: Ja. Ein gutes Beispiel wäre, wie ein Entwickler einen geeigneten Workflow erstellen kann, damit sein eigener Code automatisch getestet und dann kompiliert und verpackt wird, wenn er einen Code erstellt und ihn in ein Repository überträgt. Die Entwickler sollten nicht darauf angewiesen sein, dass irgendjemand aus der Infrastruktur das für sie erledigt. Die Erstellung eines ansprechenden YAML-Skripts auf GitHub ist eine Infrastruktur-als-Code-Aufgabe, die jeder Entwickler optimieren kann, um diesen Prozess so effizient wie möglich zu gestalten.

So braucht ein Entwickler beispielsweise keine vollständige Paketierung, keine vollständige Validierung und keine vollständigen Tests, wenn er nur auf dem Entwicklungszweig sitzt. Dieser Entwickler wird sagen: „Hey, ich bin im Entwicklungszweig, ich kann all diese 20 Aufgaben ignorieren, die nur für den Produktionszweig bestimmt sind.“

Aber wenn Sie in der Produktion arbeiten, müssen Sie eine ganze Reihe von Automatisierungen durchführen und die Maschine hochfahren, die vollständige Sicherheitsüberprüfung und Validierung des Codes durchführt und so weiter. All diese kleinen Entscheidungen, die sich darauf auswirken, wie schnell Sie kompilieren können und wie schnell Sie die Ergebnisse sehen, nachdem Sie den Code übergeben haben – jeder Entwickler sollte in der Lage sein, die Infrastruktur in Form von Code-Skripten zu ändern und sie an seinen eigenen Arbeitsablauf anzupassen.

Es ist so, als würden dieselben Entwickler gerne ihre eigene integrierte Entwicklungsumgebung einer Feinabstimmung unterziehen. Sie bevorzugen ihre eigenen Schriftarten und Farben und Tastaturkürzel und all das. Sie sollten auch in der Lage sein, ihre eigenen Workflows zu konfigurieren, d. h. was passiert, nachdem Sie den Code übernommen haben. Das ist alles Wissen, das von IaC – Infrastructure as Code – stammt.

MF: Was sollten Infrastrukturexperten heute über die App-Entwicklung wissen?

MK: Infrastructure as Code – IaC – bedeutet wörtlich, dass Infrastrukturleute zu Programmierern werden. Infrastruktur wird durch Skripte, mit Daten und Code definiert. Das bedeutet, dass das Infrastrukturskript oder der Code denselben Softwareentwicklungszyklus durchlaufen muss wie der gesamte Code, den Entwickler schreiben:

• Er muss ordnungsgemäß dokumentiert werden.
• Er muss ordnungsgemäß in einem Repository gespeichert werden.
• Er muss ordnungsgemäß versioniert sein.

Er muss genauso behandelt werden. Herkömmliche Mitarbeiter im Bereich Infrastruktur haben das nicht verstanden oder waren nicht in der Lage, es zu verstehen. Die Mitarbeiter der Infrastruktur können Dinge konfigurieren, per Mausklick, und vielleicht können sie auch ein paar Bash-Skripte oder ähnliches schreiben.

Aber jetzt wird völlig erwartet, dass Infrastrukturleute tatsächlich Programmierer für die Infrastruktur sind. Sie müssen Git verstehen. Sie müssen wissen, wie sie ihre Infrastruktur als Code-Assets auf Sicherheit prüfen können. Ihre Assets müssen ordnungsgemäß versioniert und von Kollegen geprüft werden, und sie müssen verstehen, was ein Pull Request ist. Dies sind alles Standardbegriffe und Aktivitäten, die jeder Softwareentwickler standardmäßig kennt.

Die Infrastrukturmitarbeiter müssen „Full Stack“ werden. Und Full-Stack-Ingenieure sind schwer aufzubauen und zu finden. Es gibt einen Mangel an Leuten, die alles von Grund auf verstehen – wie die Pakete fließen, wie das Netzwerk funktioniert und wie der Kernel des Betriebssystems funktioniert – bis hin zur obersten Führungsebene. Wie verfasse ich zum Beispiel mehrere Softwareabhängigkeiten? Verwenden Sie Pakete, die entweder Open-Source- oder interne Pakete sind? Wie schreibe ich asynchronen Code? Alle Fragen der reinen Softwareentwicklung. Zwei riesige Domains sind zu einer einzigen zusammengefasst worden. Es gibt kein Change Management und keine Umschulung und Weiterbildung für Talente.

MF: Wenn die Umschulung und Weiterbildung eine so große Herausforderung ist, wie sollten sich Infrastrukturfachleute dann über Entwicklungstrends und Technologien auf dem Laufenden halten?

MK: Nun, es gibt keine infrastrukturspezifischen Mitarbeiter und keine entwicklungsspezifischen Mitarbeiter mehr, alles ist in einem einzigen Bereich zusammengefasst. Sie alle lernen diese neuen Trends kennen – Veränderungen im Lebenszyklus der Softwareentwicklung und vor allem jetzt Veränderungen durch KI.

Da wir uns auf eine KI-native Art der Entwicklung konzentrieren, müssen sowohl Infrastrukturmitarbeiter als auch Anwendungsentwickler diese erlernen. Jeder leidet unter dem FOMO-Effekt und denkt, dass er bereits im Rückstand ist. Sie haben gerade gelernt, wie man Prompt-Engineering betreibt, und jetzt wird ihnen gesagt, dass sie lernen müssen, wie man Agenten für den Semantic Kernel oder ähnliches programmiert.

Die Menschen müssen sich gegenseitig helfen, sie müssen die richtige Balance finden. Wie viel Zeit müssen Sie aufwenden, um auf dem neuesten Stand zu bleiben und zu wissen, dass Sie immer noch die Nase vorn haben? Früher waren es 5 %, jetzt sind es 10 %. Generative KI unterstützt Sie dabei. Aber das Verhältnis zwischen der Zeit, die Sie zum Lernen benötigen, und der Zeit, in der Sie das Gelernte anwenden und etwas schaffen, das einen geschäftlichen oder IT-Wert darstellt, verschiebt sich mehr und mehr in Richtung Lernen.

MF: Und bevor wir zum Schluss kommen, was sind die wichtigsten Dinge, die Entwickler und Infrastrukturexperten bei modernen Anwendungen beachten sollten?

MK: Es gibt keine getrennten Aufgaben mehr. Moderne Anwendungen haben eine fast eingebaute Infrastruktur. Ein Beispiel: Ein moderner Entwickler schreibt einen Code und möchte einen Container erstellen. Es gibt keine Infrastruktur, die einen Container für sie herstellt. Einige Jobs erfordern eher infrastrukturorientierte Arbeit, aber auch Entwicklung. Und einige Jobs erfordern mehr Softwareentwicklung, aber auch Infrastrukturwissen und Zugang.

Infrastrukturfachleute sollten sich also überlegen, ob sie Softwareentwickler werden wollen. Und das Gleiche gilt für Softwareentwickler: Sie müssen zu Infrastrukturprofis werden.

Diese Rollen sind nicht getrennt, sie verschmelzen miteinander. Es ist wie vor einem Jahrzehnt oder mehr, als jeder professionelle Softwareentwicklungsbetrieb Entwickler und Tester hatte. Niemand spricht mehr von Testern, weil diese beiden Rollen verschmolzen sind. Die gleiche Art der Zusammenlegung und Verschmelzung von Rollen – diesmal zwischen Entwicklern und Infrastrukturmitarbeitern – findet jetzt statt.