Warum Infrastructure as Code Unsinn ist

Und was wirklich funktioniert, wenn Ops-Teams ihre Infrastruktur automatisieren wollen

Wer in der IT unterwegs ist, kennt das Versprechen von Infrastructure as Code (IaC). Alles wird durch Code beschrieben. Code ist versionierbar, reproduzierbar, automatisierbar. Klingt gut, scheitert in der Praxis aber trotzdem regelmäßig, weil das Konzept einen grundlegenden Denkfehler hat. Und weil es eine bessere Alternative gibt: IaCC – Infrastructure as Code and Configuration.

Tomate mit Schweizer Taschenmesser an Rechner

Das eigentliche Problem: Niemand weiß, was passiert ist

Infrastruktur wird in vielen Unternehmen noch immer händisch zusammengeklickt, besonders in Deutschland, wo man gerne klassisch unterwegs ist. VM hier, Netzwerk-Regel da, irgendwas in der Konsole getippt, Ticket geschlossen. Läuft.

Bis es eben nicht mehr läuft. Und dann weiß niemand mehr, was eigentlich passiert ist. Keine Ahnung, was genau konfiguriert wurde, welche Seiteneffekte es gab, was noch alles mitverändert wurde. Es gibt keine Dokumentation, keine Reproduzierbarkeit, keinen Rollback. Das kennen alle, die mal einen Windows Server in der Hand hatten.

Dieses Problem ist real, weit verbreitet und kostspielig. Infrastructure as Code klingt da nach der logischen Antwort.

Wobei sich vorher eine ehrliche Frage lohnt: Braucht man hier überhaupt Automatisierung? Für kleinere Themen, für Dinge, die man nur einmal braucht, ist eine saubere Dokumentation oft der bessere Ansatz. Automatisierung ist kein Selbstzweck.

Warum Infrastructure as Code trotzdem Unsinn ist

Infrastructure as a Code ist Unsinn. Starke These, ja. Aber sie hat einen Grund.

Die Idee hinter IaC ist nachvollziehbar: Was ich sonst mit der Hand klicke, schreibe ich als Code. Das ist ein bekanntes Pattern und in aller Munde. Es gibt immerhin zig Zertifikate und Schulungen dafür. Und trotzdem sagen wir: Es ist der falsche Ansatz. Warum?

Ops-Teams sind keine Entwickler

Terraform, Pulumi, Ansible sind Werkzeuge, die Entwickler-Denken voraussetzen. Aber die Leute, die operativ tätig sind, sind meist keine Entwickler. Das ist ein bisschen so, als ob man dem Architekten die Maurerkelle in die Hand drückt. Er weiß zwar, was eine Wand ist, ist aber deswegen trotzdem noch kein guter Maurer. Er sollte sich lieber auf das konzentrieren, was er kann und täglich tut.

Umgekehrt gilt dasselbe: Entwickler, die in den Ops-Bereich kommen, bringen selten Erfahrung im Betrieb von Infrastruktur mit. Beide Welten treffen aufeinander, ohne dass eine von beiden wirklich fit für die Aufgabe der anderen ist. Das ist die Krux an DevOps – zumindest so, wie es meistens gelebt wird.

Code hat Seiteneffekte

Man kann Code durchlesen, sich denken, dass er plausible klingt und tut, was er soll. Aber ob er unter allen Umständen genau das tut – und nur das – weiß vorher niemand. Externe Abhängigkeiten, implizite Bedingungen und versteckte Wechselwirkungen machen es extrem schwierig, Infrastruktur-Code sauber für den Produktivbetrieb abzubilden.

Ein Beispiel: Man liest seinen Code ein und bekommt das eine Mal eine virtuelle Maschine und das andere Mal drei. Irgendeine Bedingung war anders, irgendeine Abhängigkeit hat gegriffen, ein kleiner Fehler hat sich eingeschlichen. Bei Code kann das passieren. Bei Konfiguration nicht.

Code lässt sich nicht vollständig auf Korrektheit prüfen

Wenn ein Ops-Mitarbeiter eine Zeile in einem Terraform-Template ändert, kann das Konsequenzen haben, die er selbst nicht überblickt und die auch kein Tooling zuverlässig vorher erkennt. Das ist kein Mangel eines bestimmten Werkzeugs, sondern ein mathematisches Grundproblem: das sogenannte Halteproblem. Es lässt sich formal beweisen, dass kein Programm für alle möglichen Eingaben im Voraus garantieren kann, was passiert.

Für erfahrene Entwickler ist das durch Tests, Reviews und jahrelange Praxis beherrschbar. Für Ops-Teams ist es eine Einladung zu Fehlern, die schwer zu finden und teuer zu beheben sind.

Hinzu kommt:  Der Code läuft in der Regel nie vollständig gekapselt, sondern hängt zusätzlich von Eingaben ab wie Namen, geografischen Standorten, IP-Bereichen oder VM-Typen. Werden diese Informationen ebenfalls händisch bereitgestellt, sind Tippfehler, Copy-Paste-Fehler oder uneinheitliche Benennungen fast vorprogrammiert.

Auch die Reproduzierbarkeit ist dahin. Von vollständiger Testbarkeit ganz zu schweigen. Und selbst wenn die Eingaben validiert sind, verschwinden die Ausgaben, etwa resultierende öffentliche oder private IP-Adressen, häufig im Daten-Nirwana, statt automatisch in einer CMDB dokumentiert zu werden.

In diesem Fall ist die Automatisierung so hilfreich wie ein Schnellboot in der Wüste – Ziel verfehlt.

IaCC: Die Trennung, die den Unterschied macht

Was ist IaCC? IaCC – Infrastructure as Code and Configuration – bezeichnet einen Ansatz, bei dem eine stabile, von Experten entwickelte Codebasis durch wechselnde, validierbare Konfiguration gesteuert wird, anstatt Infrastrukturlogik direkt im Code zu ändern. Es ist ein Ansatz, den wir bei Cloutomate entwickelt haben. Das Konzept gibt es so nicht als Standard. Manche nutzen ähnliche Ideen, aber ohne sie so zu nennen. Wir haben dem Kind einen Namen gegeben, damit es greifbar wird. Die Grundidee klingt simpel, hat aber weitreichende Konsequenzen:

Der Code bleibt stabil. Die Konfiguration ändert sich.

Der Code-Anteil – die eigentliche Automatisierungslogik – wird einmalig von Experten entwickelt und getestet. Von Entwicklern mit tiefem Fachwissen im jeweiligen Bereich. Diese Codebasis bleibt dann unverändert. Sie kann erweitert werden, wenn neue Funktionen gebraucht werden, wird aber in der Regel nicht angefasst. Sie ist der geprüfte, stabile Unterbau.

Die Konfiguration ist das, was sich ändert. Welche VM soll provisioniert werden? Welche Größe? Welches Netzwerk? Welche Berechtigungen? Das sind Parameter – keine Programmlogik. Und Parameter haben entscheidende Vorteile:

  • Sie sind seiteneffektfrei. Konfiguration ist deterministisch. Die gleiche Eingabe führt immer zum gleichen Ergebnis.
  • Sie sind validierbar. Falsche Eingaben werden sofort erkannt, bevor irgendetwas provisioniert wird. Das System gibt direktes Feedback: Diese Eingabe ist nicht valide, diese Kombination nicht verfügbar, dieser Wert ergibt in diesem Kontext keinen Sinn.
  • Sie sind verständlich. Ops-Teams müssen nicht programmieren lernen. Sie lernen, mit einer Konfiguration zu arbeiten, die direktes Feedback gibt.

Das ist der Unterschied zwischen einem System, das ein Ops-Team eigenständig betreiben kann, und einem, das permanent Entwickler-Expertise voraussetzt.

Wie das konkret aussieht

Ein Ops-Mitarbeiter soll eine neue Firewall-Regel anlegen. Er öffnet die Konfiguration und sieht sofort, welche Felder erwartet werden: Port, Range, Quelle, Ziel. Er bekommt Auswahlmöglichkeiten angezeigt, sieht den Kontext, in dem er sich bewegt, und erhält jederzeit Live-Feedback. Noch bevor ein Prozess angestoßen oder ein Approval eingeholt wird, weiß er: Das funktioniert – oder eben nicht.

Was IaCC in der Praxis ermöglicht

Weil Konfiguration strukturiert und prüfbar ist, lässt sie sich nahtlos in bestehende Enterprise-Workflows einbinden:

  • CMDB-Integration: Die Konfigurationsdaten können direkt aus der Configuration Management Database gezogen werden. Was dort steht, wird provisioniert – konsistent und nachvollziehbar.
  • ServiceNow-Workflows: Firewall-Regeln oder ähnliches lassen sich in einem formularbasierten, modellgetriebenen Prozess abbilden und direkt als Eingabe nutzen – kein Code, aber alle Vorteile.
  • GitOps-Ansätze: Konfigurationsänderungen landen im Repository, werden reviewed, getrackt, historisiert.
  • Nachvollziehbarkeit und Rollback: Jede Änderung ist dokumentiert. Sie lassen sich vergleichen, einzeln zurückrollen und gezielt von einer Umgebung auf die andere übertragen: von Dev auf Staging auf Prod.

Das Entscheidende dabei ist, dass diese Quellen nicht einzeln genutzt werden müssen. Sie können und sollten kombiniert werden. Die CMDB liefert Owner und Asset-Daten, das Ticket-System bildet den Change-Prozess ab, ServiceNow steuert Approvals bei. All das fließt zusammen als Konfiguration in den stabilen Code ein. Kein Mensch muss manuell etwas schreiben. Und trotzdem – oder gerade deswegen – entsteht kein unkontrollierter Code, sondern vollständig nachvollziehbare, auditierbare Infrastruktur.

Das macht IaCC zu mehr als einem technischen Ansatz: Es ist die Grundlage für eine Automatisierung, die sich in Governance-, Compliance- und Betriebsprozesse einfügt – in mittelgroßen IT-Abteilungen genauso wie in hochregulierten Enterprise-Umgebungen.

Wer profitiert von IaCC?

IaCC adressiert konkret den Ops-Alltag in mittelgroßen bis großen IT-Umgebungen:

  • IT-Operations-Teams, die Infrastruktur betreiben, aber nicht entwickeln wollen
  • DevOps-Umgebungen, in denen Stabilität des Unterbaus Voraussetzung für schnelle Deployment-Zyklen ist
  • Unternehmen mit Compliance-Anforderungen, die Nachvollziehbarkeit und Kontrolle brauchen
  • IT-Abteilungen mit Fachkräftemangel, die mit vorhandenem Personal mehr leisten müssen – ohne dass jeder Terraform-Experte sein muss

Es geht nicht um weniger Automatisierung, sondern um die Richtige

Infrastructure as Code scheitert nicht, weil die Idee falsch ist. Die Idee – Infrastruktur reproduzierbar, automatisiert und nachvollziehbar zu machen – ist richtig und wichtig. IaC scheitert, weil es das falsche Werkzeug für die falsche Zielgruppe ist.

Die Trennung von stabilem Code und wechselnder Konfiguration ist die saubere Lösung: Experten schreiben und pflegen den Code einmalig. Ops-Teams arbeiten mit Konfiguration. Alles bleibt sicher, validiert, verständlich – und vor allem: im Betrieb reproduzierbar.

Infrastructure as Code and Configuration (IaCC) ist eine Designentscheidung. Und sie macht den Unterschied zwischen Automatisierung, die auf dem Papier funktioniert und solcher, die im Betrieb funktioniert.