IT-Administrator: Früher reichten vCenter und Putty – heute fallen Begriffe wie GitOps, YAML und Terraform. Wie viel Programmierer muss ein klassischer Infrastruktur-Admin heute sein, um Software-definierte Infrastrukturen – SDI – bedienen zu können?

Jens Müller: Die Frage hängt von Art und Umfang der erforderlichen Anpassungen ab, die im Rahmen eines SDI-Projekts erfolgen. Die meisten SD-Infrastrukturen liefern bereits sehr umfangreiche Funktionen als Bordmittel. Diese Funktionen können "off-the-shelf" von Administratoren genutzt werden, um die Basisfunktionen der Umgebung − die unter Umständen sehr mächtig sein können − umzusetzen. Im Einzelfall kann dies durchaus ausreichen, um die Infrastruktur ohne zusätzliche Programmierkenntnisse zu implementieren und zu betreiben. Sollen zudem allerdings Automatisierungen erfolgen, beispielsweise zur effektiveren Betriebsführung oder Kopplungen zur Anbindung an Fremdsysteme, ist es notwendig, über die Basisfunktionen hinaus Systemanpassungen vorzunehmen. Diese Automatisierungen erstellen IT-Verantwortliche heute mit Werkzeugen, die für unterschiedliche Komponenten wie Netzwerk, Security oder Data Center als Standard gelten. Mit diesen Tools lassen sich nicht nur einzelne Systeme parametrisieren und automatisieren, sondern eine Vielzahl unterschiedlicher Systeme zeitgleich. SDI verspricht Vereinfachung durch Abstraktion, verlagert die Komplexität aber oft nur in die Softwareschicht.

Wie verhindert ein Admin, dass er am Ende vor einer unüberschaubaren Blackbox steht, wenn die Fehlersuche ansteht?

Der Einsatz von Automatisierung entbindet den Infrastruktur-Admin nicht von der Anforderung, das Wissen über die Funktionen, das Troubleshooting und die systemspezifischen Hintergründe der Software-definierten Infrastruktur beizubehalten. Eine komplette Abstrahierung ist nicht zielführend. So etwas ist maximal in größeren Infrastrukturteams mit starker Arbeitsteilung sinnvoll. Ein intensiver Austausch im Team zwischen Automatisierern und Infrastrukturbetrieb bleibt aber nach wie vor erforderlich, um Systemspezifika zu beachten und beim Troubleshooting Details der Umgebung einbringen zu können. Software-defined-Infrastrukturen liefern hier ein weiteres Hilfsmittel, das die Betriebsführung und das Troubleshooting auch bei hoch automatisierten Infrastrukturen erleichtert.

Wenn sich die Infrastruktur dynamisch per Code auf- und abbaut – wie gelingt dem Admin die Dokumentation?

Hierzu sind Tools und Verfahren hilfreich und erforderlich, die im Bereich der Softwareentwicklung zum Standardrepertoire gehören. CI/CD-Prozesse sowie Pipelines reduzieren Fehler und erhöhen die Sicherheit der Software. Dieser Ansatz sollte auch bei der SDI-Automatisierung zum Einsatz kommen. Darüber hinaus stellen moderne SD-Systeme die Abbildung der Infrastrukturen als "Digitaler Zwilling" von Haus aus zur Verfügung. Dieser dient dazu, das System bei Änderungen, Fehlerfällen und bei Betriebsanpassungen im Vorfeld der eigentlichen Systemanpassungen zu simulieren, sodass Fehlkonfigurationen ohne Betriebsimpakt bleiben. Nach den VMware-Preissprüngen suchen viele nach Software-definierten Alternativen wie OpenStack oder Proxmox.

Wie schmerzhaft ist so ein Plattformwechsel auf SDI-Ebene in der Praxis wirklich?

Die VMware-Preissprünge sind für viele Unternehmen ein ernstes wirtschaftliches Problem. Aus Sicht eines erfahrenen IT-Dienstleisters und Managed Service Providers wie Controlware ist die ehrliche Antwort: Der Schmerz ist real, aber kalkulierbar – wenn der IT-Verantwortliche ihn strukturiert angeht. Die eigentliche VM-Migration ist dank moderner Tools heute technisch deutlich einfacher als noch vor wenigen Jahren. Dennoch gilt: Was oberflächlich wie eine reine Hypervisor-Ablösung aussieht, ist in Wirklichkeit ein Eingriff in den gesamten Software-defined-Stack. Ebenso ist der zeitliche Migrationsaufwand zu planen. Dieser ist abhängig von der Komplexität und der Größe der Infrastrukturen, die umzustellen sind. Hier muss mit einigen Wochen bei kleineren Installationen bis hin zu mehreren Monaten oder gar Jahren ausgegangen werden. Zusätzlich ist neben der technischen Migration und dem zeitlichen Aufwand auch eine Betrachtung der Gesamtkosten erforderlich. Diese sollten zusätzlich zu den Infrastrukturkosten auch den Beratungs- und Schulungsaufwand und gegebenenfalls die Kosten für die externe Betreuung der neuen Infrastrukturen enthalten, falls ein betriebliches Outsourcen der Infrastruktur für die Unternehmen relevant ist. Der eigentliche Schmerz eines Plattformwechsels auf SDI-Ebene betrifft nicht die Technik – es sind die blinden Flecken bei Abhängigkeiten, Betrieb und Governance. Im Mittelstand gibt es immer die eine, 15 Jahre alte Legacy-Applikation, die nicht Cloud-nativ ist.

Wie fängt eine moderne Software-definierte Umgebung solche "Oldtimer" ab?

Oldtimer in Software-defined-Umgebungen sind beileibe kein Nischenproblem. Vielmehr ist es der Normalzustand in deutschen Unternehmen. Die Legacy-Instanz auf Windows-Servern, die Fertigungssteuerung auf einem proprietären Datenbanksystem, das branchenspezifische Tool ohne Webservice-API – all das existiert in fast jedem Betrieb. Die entscheidende Frage lautet daher nicht: "Sollen wir den Oldtimer loswerden?", sondern: "Wie integrieren wir den Oldtimer sicher und kontrolliert in eine moderne SDI-Umgebung?". Gerade diese Infrastrukturen bieten die perfekte Möglichkeit und den Werkzeugkasten, Bestandsapplikationen strukturiert in die neue Zeit zu führen. Den Beginn macht verständlicherweise ein Assessment der Legacy-Applikationen und deren jeweiligen infrastrukturellen Abhängigkeiten. Anschließend gilt es, die Bestandsapplikation so von der SD-Infrastruktur zu einkapseln, damit einerseits die Applikation weiterhin betrieben werden kann und andererseits ihr Sicherheitszustand − der üblicherweise durch ausbleibende Security-Patches geprägt ist − die Gesamtinfrastruktur nicht beeinflusst. Hier ist es wichtig, Guardrails zu etablieren, die nur explizit erlaubten Prozessen die Ausführung genehmigen und die Grundabsicherung für jeden ungepatchten Workload festlegen.

Wenn die Software alles steuert – reicht es für den Admin künftig, einfach die billigste "White-Box"-Standardhardware zu kaufen, oder lauern hier versteckte Inkompatibilitäten im Kleingedruckten?

Die Nutzung von "White-Box"-Stand-ardhardware erscheint vielen IT-Organisationen als erstrebenswert und mit SD-Infrastrukturen in naher Zukunft erreichbar. Hier sind die Hyperscaler mit ihren riesigen Infrastrukturen, die oftmals als Greenfield-Ansatz geplant werden, sicherlich die Vorreiter. Aus Erfahrung sind allerdings die Anforderungen jedes Unternehmens oder jeder Organisation, die auf gewachsenen Infrastrukturen aufsetzen, zumindest in Details unterschiedlich, so dass eine genaue Betrachtung erforderlich ist, ob ein White-Boxing der Infrastruktur möglich ist. In der Praxis stellen darüber hinaus nicht nur die Hardwareinfrastrukturen eine relevante Größe dar, die es zu berücksichtigen gilt. Auch die Skills der Administratoren und die operativen Abläufe im Unternehmen müssen bei einem Wechsel von einer Infrastruktur auf eine neue in Betracht gezogen werden. Wichtig ist dabei ein gesamtheitlicher Ansatz: Neue Tools, die die SD-Infrastrukturen bereitstellen und die Möglichkeit, diese über teilweise sehr abstrakte Programmierschnittstellen zu parametrisieren, zu monitoren und zu betreiben, versetzen Administratoren in die Lage, deutlich agiler im Tagesgeschäft zu agieren.

Wenn eine einzige kompromittierte API-Schnittstelle das gesamte Rechenzentrum umkonfigurieren oder löschen kann – wie sichern Admins diesen zentralen Hebel ab?

Das Management-API einer SD-Umgebung ist auf Grund der Möglichkeiten, die diese bietet, Infrastrukturen zu kreieren, zu parametrisieren und gegebenenfalls zu löschen, sicherlich eine der zentralen Ressourcen in der IT-Organisation, die es zu schützen gilt. Auf der anderen Seite sind die Maßnahmen, die dazu ergriffen werden müssen, nicht außergewöhnlich und entsprechen dem Best-Practices-Security-Ansatz, dem alle zentralen IT-Ressourcen eines Unternehmens unterliegen. Starke Authentifizierung, Nutzung von Privileged Access Management, Netzwerksegmentierung insbesondere der Managementpläne sowie eine Anomalieerkennung sind State-of-the Art-Werkzeuge, die hier Anwendung finden und bereits in der Designphase konzeptionell geplant werden müssen.

Wenn Entwickler sich per Self-Service eigene SDI-Ressourcen klicken können – wie behält die IT-Abteilung die Hoheit über Schatten-IT und schleichende Konfigurationsfehler?

Auch hier sind Werkzeuge erforderlich, die wir bereits seit vielen Jahren aus der Softwareentwicklung kennen. Die Umsetzung von CI/CD-Prozessen ist der richtige Weg, um auch die Entwicklung von SD-Infrastrukturen zu ermöglichen. Dies etabliert einen Automatisierungsprozess, der von den Entwicklungsanforderungen über das Coding und Testing bis hin zum Ausrollen der Anpassungen Regeln, Leitplanken und Freigabeprozesse beinhaltet, die unbeabsichtigte, fehlerhafte oder unvollständige Codeimplementierungen verhindern.

Viele Admins schwören aus Sicherheitsgründen auf physisch getrennte Netze. Lässt sich so eine strikte Trennung in einer rein Software-definierten Welt überhaupt noch glaubhaft und sicher abbilden?

Die Antwort ist ganz klar: Ja. Moderne SD-Umgebungen bieten alle notwendigen Mechanismen, um auch getrennte Infrastrukturen abzubilden. Hier ist eine physische Trennung bis hin zu einer virtuellen Segmentierung möglich. Letztendlich ist − wie in Legacy-Implementierungen − immer der Kosten- und Betriebsaufwand entscheidend, den es zu beachten gilt.

Macht sich der klassische Systemadministrator durch die vollständige Automatisierung einer SDI am Ende selbst überflüssig – oder wie verändert sich seine Rolle in den nächsten fünf Jahren?

Nein, im Gegenteil – der Admin wird unverzichtbarer als je zuvor. Die vollständige Automatisierung einer SDI schafft keine Überflüssigkeit, sondern Nachfrage nach einer neuen Qualität von Expertise. Die eigentliche Frage ist nicht ob, sondern wie tiefgreifend sich das Rollenbild verändert. Die Tätigkeiten des klassischen Systemadministrators, der Server per Hand konfiguriert, Patches einspielt und Dienste manuell startet, verlieren tatsächlich an Bedeutung. Was jedoch stark zunimmt, ist der Bedarf an Experten, die Automatisierung in Form von prozessorientierten Programmierungen entwerfen, überwachen und kontrollieren. Der Admin ist kein Auslaufmodell, sondern ein Infrastructure Engineer mit Programmierkenntnissen, Sicherheitsbewusstsein, Cloud-Native-Expertise und dem tiefen Betriebssystem-Fundament, das kein Tool ersetzen kann. Wer heute mit Infrastructure as Code, CI/CD-Security und Observability startet, sichert nicht nur seinen Arbeitsplatz – er definiert diesen neu.

Wir danken für das Gespräch.