Woher die Infrastruktur kommt

Wenn ein Team mit dem Bau einer Anwendung beginnt, drehen sich die ersten Fragen fast immer um Code: welche Sprache, wie die Verzeichnisse strukturiert werden, wie man die Anwendung lokal ausführt. Fragen zur Infrastruktur kommen meist später – manchmal erst dann, wenn die App irgendwo laufen muss, wo andere Leute darauf zugreifen können.

Hier wird es spannend. Infrastruktur entsteht nicht von selbst. Server, Datenbanken, Netzwerke, Load Balancer – all das muss erstellt, konfiguriert und verbunden werden. Der einfachste Ansatz ist die manuelle Erstellung: ins Cloud-Dashboard einloggen, Buttons klicken, um einen Server zu erstellen, die Spezifikationen auswählen, warten, bis er bereit ist. Das funktioniert für einen Server gut. Aber es bricht auseinander, wenn man mehrere Server hat, wenn man Staging- und Produktionsumgebungen braucht oder wenn etwas kaputtgeht und man alles von Grund auf neu aufbauen muss.

Das Problem ist nicht nur die Zeit. Wenn Infrastruktur manuell erstellt wird, gibt es keine verlässliche Aufzeichnung dessen, was tatsächlich gebaut wurde. Entwickler A erstellt vielleicht einen Server mit bestimmten Spezifikationen, während Entwickler B einen anderen Server mit leicht abweichenden Einstellungen erstellt – vielleicht aus Versehen, vielleicht weil sich die Oberfläche des Cloud-Dashboards geändert hat. Diese kleinen Unterschiede können zu schwer auffindbaren Fehlern führen: Die Anwendung läuft im Staging einwandfrei, scheitert aber in der Produktion, obwohl der Code identisch ist.

Manuelle Infrastruktur ist auch schwer reproduzierbar. Wenn das Team eine neue Umgebung braucht – etwa für QA-Tests oder eine Kundendemo – muss der gesamte Prozess von vorne wiederholt werden. Jedes Mal besteht das Risiko, einen Schritt auszulassen oder einen Parameter falsch zu konfigurieren. Je größer die Infrastruktur wird, desto größer wird die Lücke zwischen dem, was beabsichtigt war, und dem, was tatsächlich erstellt wird.

Infrastruktur wie Code behandeln

Ein besserer Ansatz ist es, Infrastruktur genauso zu behandeln wie Anwendungscode. Schreibt sie in Textdateien, die Menschen lesen können, speichert diese Dateien in einem Repository und verwaltet sie mit denselben Prozessen, die ihr für normalen Code verwendet. Diese Dateien definieren den sogenannten gewünschten Zustand – den idealen Zustand, den ihr für eure Infrastruktur haben wollt, komplett mit Serverspezifikationen, Festplattengrößen, Firewall-Regeln und Datenbankverbindungen.

Mit diesem Ansatz muss sich niemand manuelle Schritte merken oder auf das Gedächtnis eines anderen verlassen. Jede Infrastrukturdefinition lebt in Dateien, die jedes Teammitglied einsehen, überprüfen und ändern kann. Änderungen an der Infrastruktur durchlaufen dieselbe Pipeline wie Codeänderungen: schreiben, von Teammitgliedern überprüfen und nach Genehmigung anwenden.

So sieht eine einfache Infrastrukturdefinition in Terraform aus:

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServer"
  }
}

Dieses Konzept nennt sich Infrastructure as Code (IaC). Die Idee ist einfach: Infrastruktur ist nichts, das man einmal konfiguriert und dann vergisst. Es ist etwas, das man über die gesamte Lebensdauer der Anwendung definiert, versioniert und verwaltet. So könnt ihr sicher sein, dass Staging- und Produktionsumgebungen identisch sind, dass jede Änderung nachvollziehbar ist und dass ihr jederzeit neue Umgebungen hochziehen könnt, ohne euch Sorgen um vergessene Schritte machen zu müssen.

Warum manuelle Infrastruktur in großem Maßstab scheitert

Machen wir das konkret. Stellt euch vor, euer Team verwaltet zehn Server manuell. Eines Tages stürzt ein Server ab. Ihr müsst ihn ersetzen. Ihr loggt euch ins Dashboard ein, erstellt einen neuen Server und versucht euch zu erinnern, welche Einstellungen der alte hatte. War es derselbe Instanztyp? Hatte er dieselben Sicherheitsgruppenregeln? War die Festplattengröße gleich? Vielleicht macht ihr es richtig, vielleicht auch nicht. Und selbst wenn, gibt es keine Möglichkeit, es zu beweisen.

Stellt euch nun vor, ihr müsst eine völlig neue Umgebung erstellen – vielleicht für ein Team, das Leistungstests durchführt. Ihr müsst jeden manuellen Schritt von Grund auf wiederholen. Wenn eure Infrastruktur inzwischen Datenbanken, Load Balancer, Caching-Layer und Message Queues umfasst, wird der manuelle Prozess zu einer Checkliste, die Stunden dauert und bei jedem Schritt anfällig für menschliche Fehler ist.

Die wahren Kosten sind nicht die Zeit, die mit dem Klicken von Buttons verbracht wird. Es ist die Unsicherheit. Wenn in der Produktion etwas schiefgeht, könnt ihr nicht schnell Fragen beantworten wie: „Was hat sich an der Infrastruktur geändert?“ oder „Ist diese Umgebung genau wie das Staging konfiguriert?“ Ohne Infrastructure as Code sind diese Fragen nur schwer mit Sicherheit zu beantworten.

Der Terraform-Workflow beginnt hier

Hier beginnt der Terraform-Workflow. Bevor irgendwelche Befehle ausgeführt werden, schreibt das Team Infrastrukturdefinitionen in Konfigurationsdateien. Diese Dateien werden zur einzigen Quelle der Wahrheit – nicht das Cloud-Dashboard, nicht persönliche Notizen, nicht das Gedächtnis von jemandem.

Der Workflow folgt einem einfachen Kreislauf:

  1. Schreiben – Definiert eure Infrastruktur in Konfigurationsdateien. Beschreibt die Server, Netzwerke, Datenbanken und anderen Ressourcen, die ihr braucht.

  2. Planen – Lasst euch von Terraform zeigen, was sich ändern wird, bevor ihr es anwendet. Das gibt euch die Möglichkeit, Fehler zu überprüfen und zu erkennen.

  3. Anwenden – Führt die Änderungen aus. Terraform vergleicht eure Konfiguration mit dem aktuellen Zustand eurer Infrastruktur und nimmt nur die Änderungen vor, die nötig sind, um den gewünschten Zustand zu erreichen.

Dieser Kreislauf spiegelt wider, wie ihr mit Anwendungscode arbeitet. Ihr schreibt Code, überprüft ihn und stellt ihn dann bereit. Der Unterschied ist, dass ihr statt Anwendungslogik Infrastrukturdefinitionen bereitstellt. Und genau wie Anwendungscode leben diese Definitionen in der Versionskontrolle, durchlaufen Code-Reviews und werden getestet, bevor sie in die Produktion gelangen.

Was Infrastructure as Code verändert

Wenn ihr Infrastructure as Code einführt, verschieben sich mehrere Dinge in der Arbeitsweise eures Teams:

Auditierbarkeit wird automatisch. Jede Änderung an der Infrastruktur wird in eurem Versionskontrollverlauf aufgezeichnet. Ihr könnt sehen, wer was wann und warum geändert hat. Wenn ein Produktionsproblem auftritt, könnt ihr prüfen, ob Infrastrukturänderungen mit dem Problem zusammenhängen.

Konsistenz wird erreichbar. Dieselbe Konfigurationsdatei kann identische Umgebungen für Entwicklung, Staging und Produktion erstellen. Unterschiede zwischen Umgebungen werden beabsichtigt und dokumentiert, nicht zufällig.

Wiederherstellung wird wiederholbar. Wenn eine Umgebung beschädigt wird oder neu aufgebaut werden muss, müsst ihr euch nicht an manuelle Schritte erinnern. Ihr führt dieselben Konfigurationsdateien aus, und die Infrastruktur wird exakt wie definiert neu erstellt.

Zusammenarbeit wird möglich. Infrastrukturdefinitionen können wie Code überprüft werden. Teammitglieder mit weniger Erfahrung können durch das Lesen vorhandener Konfigurationen lernen. Erfahrene Teammitglieder können Fehler erkennen, bevor sie in die Produktion gelangen.

Ein praktischer Ausgangspunkt

Wenn ihr neu bei Infrastructure as Code seid, hier eine einfache Checkliste für den Einstieg:

  • Wählt ein kleines Stück Infrastruktur aus, das ihr derzeit manuell verwaltet – vielleicht einen einzelnen Server oder eine Datenbankinstanz.
  • Schreibt dessen Konfiguration in Terraform oder eurem bevorzugten IaC-Tool.
  • Führt einen Plan aus, um zu sehen, was Terraform ändern würde.
  • Wendet die Konfiguration an und überprüft, ob das Ergebnis euren Erwartungen entspricht.
  • Übernehmt die Konfigurationsdateien in euer Repository.
  • Löscht die manuelle Ressource und erstellt sie nur mit euren Konfigurationsdateien neu.

Diese Übung beweist euch selbst und eurem Team, dass der Ansatz funktioniert. Habt ihr es einmal gemacht, werdet ihr anfangen, andere Teile eurer Infrastruktur zu sehen, die genauso verwaltet werden sollten.

Das Fazit

Infrastruktur entsteht nicht durch Magie, und sie sollte nicht durch Gedächtnis verwaltet werden. Infrastructure as Code zu schreiben, verwandelt einen fehleranfälligen manuellen Prozess in einen wiederholbaren, überprüfbaren und auditierbaren Workflow. Der Terraform-Workflow – schreiben, planen, anwenden – ist nur eine praktische Umsetzung dieser Idee. Bevor ihr einen Befehl ausführt, definiert zunächst, was ihr wollt. Diese Definition, in der Versionskontrolle gespeichert, wird zur einzigen Quelle der Wahrheit für eure Infrastruktur. Alles andere folgt daraus.