Oliver Weise: Im Kern des Konzepts von Infrastructure-as-Code – kurz IaC – geht es um eine Automatisierung, die deklarativ arbeitet und deren Ziel es ist, eine Infrastruktur aufzubauen. Früher setzten Admins Infrastrukturkomponenten wie Netzwerk, Speicher oder Computing-Ressourcen manuell auf und führten dann dort entsprechende Tasks aus. Bei IaC entfällt der manuelle Teil, stattdessen schreibt der Admin zunächst eine Definition der Komponenten und deren Spezifikation in so etwas wie Programmcode. Dieser lässt sich an ein IaC-Werkzeug übergeben, das dann selbstständig und automatisch die Infrastruktur erzeugt. Diese Technik ist nicht nur für das Deployment geeignet, sondern kann auch zum Modifizieren oder Löschen bestehender Landschaften dienen. Grundlage und Zielplattformen für IaC sind Clouds, die ja ebenfalls Software-defined und virtualisiert sind – klassische Hardware als Ziel tut sich da schwer.

Der erste Vorteil ergibt sich aus der Automatisierung selbst, IaC sorgt für Wiederholbarkeit mit minimalen Ressourcen. Alles, was einmal als Code vorliegt, lässt sich ohne nennenswerten Zusatzaufwand beliebig oft einsetzen. Zum Beispiel, um mehrere identische Umgebungen aufzubauen. Diese sind dann – bis auf gewollte Unterschiede – absolut gleich, was meist nicht klappt, wenn eine Person mehrfach von Hand die gleiche Infrastruktur aufbaut. Denn bei aller Präzision kommt es bei manueller Arbeit doch immer wieder zu subtilen Abweichungen. Viele der Tools erlauben dann auch, solche Umgebungen wieder abzuräumen, egal, wie komplex diese ist. Das ist zum Beispiel für Testumgebungen sehr praktisch. Der zweite große Vorteil ist darin zu sehen, dass Code, der eine Infrastruktur beschreibt, de facto schon eine Art der Dokumentation ist. Ein Blick in den Code reicht dann aus, um zu wissen, wie bestimmte Systeme ausschauen.

Ja, es lassen sich auch Vorteile von IaC gegenüber klassischer Automatisierung aufzählen. Diese ist nämlich meistens eher imperativ und beschreibt, was getan werden soll, während IaC das Endergebnis darstellt. Solch deklarativer Code ist sowohl einfacher zu schreiben als auch leichter zu verstehen. Bei der IaC-Automatisierung mit deklarativem Code nimmt die entsprechende Software ferner dem Admin die Arbeit ab herauszufinden, wie das beschriebene Ziel inklusive der IT-Ressourcen und deren Abhängigkeiten zustandekommt. Ich möchte allerdings nicht verschweigen, dass dies in der Praxis auch zu Problemen führen kann, wenn die IaC-Software ihre Aufgabe nicht erledigen kann und der Admin dann den Fehler suchen muss. Dabei hat er dann weniger Anhaltspunkte, was die konkreten IT-Ressourcen angeht. Ein weiterer wichtiger Vorteil von IaC ist im Changemanagement zu finden. Die Software kennt den aktuellen Ist-Zustand und kann diesen gegen einen Soll-Zustand abgleichen. So erfährt der IT-Verantwortliche ganz genau, was passiert, wenn die geplanten Änderungen zur Anwendung kommen. Potenziell kritische Änderungen lassen sich so leicht erkennen.

Grundsätzlich möchte ich nochmal darauf hinweisen, dass IaC nur in Softwaredefinierten Umgebungen sinnvoll ist, also in Public Clouds, in Container-Orchestrierungsplattformen – überall da, wo eine virtualisierte Infrastruktur vorliegt. Dort halte ich es aber immer für sinnvoll, auf IaC zu setzen, selbst wenn dies anfänglich einen erhöhten Aufwand nach sich zieht. In Sachen Organisation der IT kann IaC dabei helfen, den Wildwuchs von Automatisierung in den Griff zu bekommen. Gerade in großen Unternehmen, deren IT an verschiedenen Stellen automatisiert ist, geht oft der Überblick verloren. Sind Automatisierungsprojekte nicht verzahnt, können auch keine Synergien entstehen. An dieser Stelle kann IaC helfen.

Infrastructure-as-Code ist eine Technik, deren erste Schritte sich im Prinzip nebenbei erlernen lassen. In einem kleinen Projekt zum Aufbau neuer Infrastruktur im Unternehmen können sich IT-Verantwortliche Gedanken machen und einen Eindruck gewinnen, wie das Projekt in IaC aussehen könnte. Das ist keineswegs ideal, aber wenn wir einmal ehrlich auf die Arbeit von Admins blicken, haben diese sonst auch kaum Zeit, um etwas Neues zu lernen. Aus meiner Sicht ist es besser, so zu starten, als gar nichts zu tun. So sind Quick Wins in der Automatisierung möglich, die aber auch Einblicke in strategische Überlegungen zur Nutzung von IaC gewähren. Es gibt ein gutes Beispiel aus meiner Arbeit: Ich kam zu einem Unternehmen, das regelmäßig Testumgebungen aufsetzen musste, um die Migration einer Software zu testen. Das nahm jedes Mal eine Woche in Anspruch, weil es null Automatisierung gab. Gemeinsam mit den Admins vor Ort haben wir dies automatisiert und der Vorgang benötigt jetzt nur noch ein bis zwei Stunden. Das zeigte den Admins, wie groß das Potenzial der Automatisierung für die Optimierung der IT ist.

Die Wahl des jeweils passenden Werkzeugs ist schon sehr wichtig. Abwägen muss der IT-Verantwortliche dabei zwischen Flexibilität und Komfort. So sind Tools, die beispielsweise für einen speziellen Cloudprovider entwickelt wurden, oft sehr gut mit diesen Plattformen verknüpft und bieten daher einen gewissen Komfort bei der Arbeit. Es fehlt aber die Flexibilität, da sich dieses Tool und das Wissen, das sich der Admin dazu aneignet, nirgendwo anders anwenden lässt. Das ist sozusagen ein Vendor-Lock-in. in Sachen Know-how. Daher würde ich immer Flexibilität bevorzugen. Und es gibt solche Tools, die sich für verschiedene Plattformen einsetzen lassen. Zu dieser Flexibilitäts-Grundregel gibt es aus meiner Sicht genau eine Ausnahme: Kubernetes. Dies setzt grundlegend auf IaC und unabhängig davon, wo es läuft – also etwa bei AWS, Azure oder GCP – ist das IaC-Know-how immer portabel.

Das ist, sind wir ehrlich, noch immer eine Herausforderung. Denn wenn ich dasselbe IaC auf drei Cloudprovider anwende, heißt das nicht, das auch dreimal der gleiche Code zum Einsatz kommt. Dennoch besteht der Vorteil, so das Tool kennenzulernen und mich einzuarbeiten. Dennoch, die Ressourcen sind unterschiedlich. Diesen Weg kann der Admin durchaus gehen und die Plattformen unterschiedlich behandeln oder er kann versuchen, einen sogenannten Mediator einzubauen – eine Plattform, die für alle Zielsysteme gleich ist. Eine Möglichkeit, die ich hierzu schon angesprochen habe, ist Kubernetes, das sich überall so gut wie identisch verhält. Andere Ansätze, Multiclouds zentral mit einer Codebasis zu bespielen, sind aber derzeit noch auf dem Stand individueller Lösungen für das jeweilige Unternehmen.

Nach meiner Erfahrung ist die Abneigung von Admins gegenüber Code gar nicht so groß. Sie beschäftigen sich doch recht viel mit Skripten – vielleicht, ohne dies als Coding wahrzunehmen. Reserviertheit sehe ich – wenn überhaupt – bei den Arbeitsprozessen aus der Softwareentwicklung, wie beispielsweise bei der Verwaltung von Code. Doch wenn ein Admin auf Code-getriebene Automatisierung setzen will, wird sich seine Arbeit der eines Software-Engineers annähern. Er hat dabei zwar dieselben Aufgaben wie früher, geht viele davon aber anders an. Dort sieht er dann unter Umständen den Code als Umweg an, den er geht, wo er früher hier oder da geklickt hätte. Ich hoffe aber, dass Admins, die diesen Weg einschlagen, dann auch den Zugewinn in Sachen Qualität und freigewordener Zeit irgendwann zu schätzen wissen und dadurch das Thema Code positiver sehen. Für den Erfolg einer solchen Umstellung ist aber ein gradueller Prozess entscheidend. Nicht alles von heute auf morgen umstellen, sondern Schritt für Schritt. Zudem sollte Code nicht Dogma werden: Im Notfall muss der Admin nach wie vor in der Lage sein, ein wichtiges System manuell zu troubleshooten und nicht dem Zwang unterliegen, dass er bei Problemen als Erstes seinen Code ändert.

Das kann ich verneinen, denn die Wahl der Sprache ist bei IaC nur ein Randaspekt. Denn zum einen arbeiten wir hier deklarativ, zum anderen bringen die meisten IaC-Tools proprietäre, eigene Sprache mit. Die Flexibilität des Tools ist wie angesprochen viel wichtiger und noch wichtiger ist das Verständnis der IT-Ressourcen, die der Code beschreibt – bei Storage, Netzwerk und Rechenleistung ist der Admin dann wieder in seinem Element.