Infrastructure-as-Code ist die Praxis, die Infrastruktur — Server, Netzwerke, Datenbanken, Sicherheitsregeln — schriftlich zu beschreiben, anstatt sie durch manuelle Klicks in einer Konsole zu konfigurieren. Was sich technisch anhört, ist in seiner Wirkung eine Führungsentscheidung: Die Organisation entscheidet, dass Änderungen an der Infrastruktur dokumentiert, nachvollziehbar und überprüfbar sein müssen — wie jede andere wichtige Entscheidung.
Diese Entscheidung hat tiefgreifende organisatorische Konsequenzen. Infrastrukturdokumentation veraltet nicht mehr, da das System immer mit dem übereinstimmt, was geschrieben wurde. Neue Umgebungen — ein zweiter Standort, eine zusätzliche Testumgebung, Disaster Recovery — entstehen nicht durch tagelange Konfigurationsarbeit, sondern durch Wiederholung von bestehendem Code. Fehler werden abgefangen, bevor sie auftreten, da Änderungen explizit gemacht werden und überprüft werden können.
Bevor die erste Infrastrukturbeschreibungsdatei geschrieben wird, müssen drei organisatorische Fragen beantwortet werden. Sie bestimmen, ob IaC zu einem stabilen Betriebsmodell wird oder ein gut gemeinter Ansatz bleibt, der in der Praxis nicht gelebt wird.
Wer schreibt und pflegt die Infrastrukturbeschreibungen? Problematisch sind beide Extremantworten. Wenn nur das Plattform-Team Code schreibt, entsteht ein Engpass: Teams müssen auf Infrastruktur warten, anstatt eigenständig zu arbeiten. Wenn jedes Team völlig autonom ohne gemeinsame Standards agiert, entsteht ein unvereinbares Gewirr von Vorgehensweisen. Der methodisch richtige Weg liegt in der Mitte: Das Plattform-Team setzt Standards und stellt wiederverwendbare Bausteine bereit. Innerhalb dieser Grenzen arbeiten die Teams eigenverantwortlich.
Wie werden Änderungen an Produktivumgebungen freigegeben? Eine Infrastrukturänderung in der Produktion durch eine Person, ohne Prüfung, ohne Aufzeichnung — das ist das gleiche Risiko wie manuell in die Konsole zu klicken, nur schwerer rückgängig zu machen. Die sinnvolle Vorgabe ist, dass Änderungen in der Produktionsumgebung immer einen freigegebenen automatisierten Prozess durchlaufen, niemals direkt von Hand.
Wo wird der Systemzustand gespeichert? IaC-Tools verwalten den Zustand: Was ist aktuell deployt? Dieser Zustand ist entscheidend für das Funktionieren des gesamten Ansatzes. Er muss sicher, zentral und für das Team zugänglich aufbewahrt werden — niemals auf dem Laptop einer Person, niemals in einem öffentlich zugänglichen System.
Infrastructure-as-Code ändert die Anforderungen an Personen, die Infrastruktur verwalten. Dies ist nicht in erster Linie eine technische Herausforderung, sondern eine Lernkurve, die Zeit, Übung und eine fehlertolerante Lernumgebung erfordert.
Was sich ändert
Systemadministratoren, die über Jahre hinweg Infrastruktur über Konfigurationsoberflächen gemanagt haben, müssen ein anderes Denkmodell entwickeln: Statt „Ich klicke auf Erstellen“ denken sie „Ich beschreibe den gewünschten Zustand“. Diese Verschiebung ist lernbar, braucht aber Zeit und ist nicht zu unterschätzen.
Was bleibt
Das Infrastruktur-Wissen bleibt — und ist der größte Vorteil. Wer die Funktionsweise von Netzwerken, Security Groups und Datenbanken versteht, lernt die neue Beschreibungsform schnell. Technisches Wissen muss nicht neu aufgebaut werden, nur die Methode, es anzuwenden.
Was eine gute Lernumgebung braucht
Sandbox-Zugriff für folgenloses Experimentieren, Pairing mit erfahreneren Kolleginnen und Kollegen, keine Bestrafung von Fehlern in Testumgebungen. Wer beim Lernen Fehler macht, lernt. Wer Fehler macht und dafür kritisiert wird, hört auf zu lernen.
Die Rolle des Plattform-Teams
Das Plattform-Team ist in dieser Phase kein Kontrollorgan, sondern ein Enabler. Es stellt Lernmaterialien zur Verfügung, beantwortet Fragen, überprüft Code gemeinsam mit den Teams — nicht zum Bewerten, sondern zum Lehren.
Die Umstellung auf Infrastructure-as-Code ist kein Projekt mit Startdatum und Abschluss. Es handelt sich um eine Reifekurve, die sich über Monate und Jahre entfaltet. Wichtig ist, die aktuelle Position zu kennen und den nächsten sinnvollen Schritt zu gehen — nicht zu versuchen, sofort den höchsten Reifegrad zu erreichen.
Die erste Stufe ist die einfachste: Neue Ressourcen werden als Code beschrieben, bestehende Ressourcen bleiben vorerst manuell. Dies ist unvollständig, aber ein echter Anfang. Jedes neue Stück Infrastruktur, das als Code entsteht, ist eine Ressource, die das Team vollständig versteht, dokumentiert hat und wiederherstellen kann.
Die zweite Stufe bringt alle Produktionsressourcen unter Code-Kontrolle und führt einen zentralen Zustandsspeicher ein. Manuelle Änderungen an Produktivumgebungen werden zur Ausnahme, die dokumentiert werden muss.
Die dritte Stufe verbindet IaC mit automatisierten Qualitäts- und Compliance-Prüfungen. Änderungen werden nicht nur geprüft, sondern vor der Ausführung automatisch anhand von Sicherheits- und Governance-Anforderungen bewertet.
Infrastructure-as-Code ist nicht das Ziel, sondern das Mittel. Ziel ist eine Cloud-Umgebung, die nachvollziehbar, sicher, reproduzierbar und revisionssicher ist. IaC ist der effizienteste Weg dorthin.
Organisationen, die IaC einführen, melden in der Regel drei Auswirkungen nach sechs bis zwölf Monaten: Neue Umgebungen entstehen innerhalb von Stunden, nicht Tagen; Infrastruktur-Incidents werden schneller gelöst, da der Weg zurück in den Ausgangszustand bekannt ist; und Revisionsanfragen werden effizienter bearbeitet, da die Zustandsdokumentation automatisch erstellt wird.
Diese Effekte sind motivierender als jeder abstrakte Verweis auf Best Practices.
Startpunkt definieren: Mit welchem Teil der Infrastruktur beginnen? Neue Ressourcen in einer unkritischen Umgebung sind der risikoärmste Einstieg. Bestehende komplexe Produktionsinfrastruktur ist kein guter Ausgangspunkt.
Standards und Bausteine bereitstellen: Das Plattform-Team entwickelt wiederverwendbare Beschreibungen für gängige Infrastrukturkomponenten. Diese Bausteine sind der Hebel, mit dem Teams schnell starten können, ohne jeden Schritt neu erfinden zu müssen.
Die Weiterbildung begleiten: Teams erhalten Lernzeit, Sandbox-Zugriffe und Unterstützung. Dieser Schritt wird häufig unterschätzt — und ist der häufigste Grund für das Stocken von IaC-Einführungen.
Pilot abschließen und auswerten: Was hat funktioniert? Was war schwieriger als gedacht? Was muss angepasst werden? Diese Auswertung ist die Grundlage für den weiteren Rollout.
Inkrementell erweitern: Auf Basis der Piloterfahrung weitere Teams hinzuziehen, bis alle Produktionsressourcen unter Code-Kontrolle stehen.