Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Lesedauer 3 Min.

Terraform braucht eine Strategie – sonst rächt es sich

Florian Lenz weiß aus eigener Erfahrung, wie es endet, wenn man mit Terraform einfach drauflosprogrammiert: mit einem Änderungs-Rattenschwanz, den niemand mehr versteht. Auf der DWX 2026 zeigt er, wie man es besser macht.

Terraform ist nicht kompliziert. Eine Definitionssprache, mit der sich Ressourcen bei Cloud-Providern wie Azure, AWS oder Google Cloud beschreiben lassen – deklarativ, versionierbar, reproduzierbar. Wer damit anfängt, hat nach einer Stunde die ersten Ressourcen deployed. Das Problem kommt später.

Florian Lenz hat diesen Weg selbst durchlaufen. „Anfangs war es relativ einfach, einfach mal zu starten", sagt er. Bis das System größer wurde. Bis plötzlich jede kleine Änderung einen Rattenschwanz weiterer Änderungen nach sich zog. Bis niemand mehr genau wusste, was eigentlich die eigentliche Änderung war und was schlicht Unschärfen im System.

Das Kernproblem: ein monolithischer State, in dem alles steckt. Wer Terraform ohne Struktur einsetzt, landet früher oder später genau dort. Florian plädiert deswegen für State Isolation – also die saubere Aufteilung des States nach Services oder Teams. Das klingt nach mehr Aufwand am Anfang. Ist es auch. Zahlt sich aber aus, sobald das System eine gewisse Größe erreicht.

Ein weiterer Aspekt, den Florian in seinen Sessions adressiert: Terraform als Werkzeug für Standards. Wer in Azure einen Storage Account anlegt, kann sicherstellen, dass Verschlüsselung, Backup-Strategie und Zugriffsrichtlinien automatisch korrekt konfiguriert sind – über ein Modul, das diese Anforderungen einmal definiert und dann immer wieder verwendet wird. „Wenn wir das zehnmal manuell mit fünf unterschiedlichen Leuten machen, ist die Wahrscheinlichkeit sehr hoch, dass nicht alle Accounts den gleichen Anforderungen entsprechen", so Lenz. Automatisierung ist hier weniger eine Frage des Komforts als der Verlässlichkeit.

Terraform hat aber auch Grenzen – und Florian verschweigt sie nicht. Weil das Tool im Wesentlichen eine Abstraktionsschicht über das Azure-API ist, kommt es bei Preview-Features regelmäßig an seine Grenzen. Die dann übliche Lösung: auf einen anderen Provider zurückgreifen, der ARM-Templates in Terraform ermöglicht. Das funktioniert. Fühlt sich aber seltsam an, wenn man plötzlich ARM-Templates schreibt, obwohl man eigentlich Terraform wollte. Auch Remote States können zu einem echten Schmerzpunkt werden.

Trotzdem bleibt Florians Fazit positiv: Mit der richtigen Strategie lässt sich Terraform auch in komplexen Umgebungen skalieren. Und genau diese Strategie – von der Grundstruktur bis zu den Grenzen des Tools – ist das Thema seiner zwei Sessions auf der DWX 2026.

DWX 2026, 29. Juni bis 2. Juli 2026, Mannheim. https://www.developer-world.de/dwx

 

Florian Lenz ist Microsoft MVP und Experte für Cloud-native- und Serverless-Lösungen in Azure. Er unterstützt Unternehmen dabei, ihre Cloud-Landschaften zu optimieren und Architekturen aufzubauen, die nachhaltigen Erfolg garantieren. Dabei vermittelt er nicht nur technisches Know-how, sondern begleitet seine Kunden auch strategisch, um langfristige Ziele zu erreichen und innovative Lösungen nahtlos in bestehende Prozesse zu integrieren.

Als Consultant, Trainer und Autor teilt er sein umfangreiches Wissen zu Serverless- und Cloud-Technologien und spricht auf internationalen Konferenzen. Sein Wissen gibt er außerdem über Meetups sowie einen YouTube-Kanal zu Azure, Cloud-Infrastruktur und Terraform weiter.

Neueste Beiträge

Flexible Templates ohne Wiederholung - Infrastructure as Code mit Azure Bicep, Teil 2
Wie Bicep-Parameter typisiert, eingeschränkt und mit sinnvollen Standardwerten versehen werden und wie Variablen sich nutzen lassen, um aus Parametern abgeleitete Werte zu berechnen, etwa für Namenskonventionen oder umgebungsabhängige SKUs.
5 Minuten
Wenn Software autonom wird - KI-Agenten verändern die Spielregeln der IT-Infrastruktur
Agentische KI-Systeme übernehmen mehrstufige Arbeitsabläufe und bestimmen dafür innerhalb eines vorgegebenen Rahmens nötige Schritte, führen sie aus und passen ihr Vorgehen an. Dieses Maß an Autonomie bringt bestehende Infrastrukturen schnell an ihre Grenzen.
6 Minuten
2. Nov 2026
Game-Boy-Emulation in C# – ROM-Dumping - Retro-Hardware mit .NET in Software nachbilden, Teil 1
Ohne Spiele kein Emulator – wie man echte Cartridges mit einem Arduino und etwas C# zum Reden bringt.
7 Minuten
4. Nov 2026

Das könnte Dich auch interessieren

GitLab CI mit Testreports einrichten - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 3
GitLab liefert die Shard-Nummern direkt an Meziantou.ShardedTest. Für aussagekräftige Ergebnisse im Merge Request braucht es zusätzlich passende Reports. Bei Integrationstests entscheidet die Trennung der Testdaten über zuverlässige Parallelläufe.
6 Minuten
GitHub Actions umstellen - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 2
Eine Jobmatrix bringt die lokale Testaufteilung auf mehrere Runner. Damit daraus ein verlässlicher CI-Lauf entsteht, müssen Shard-Nummern, Fehlerstatus und Ergebnisdateien zusammenpassen. Der Workflow zeigt die nötigen Schritte.
6 Minuten
Laufzeitgewinn messen - Schnellere .NET-CI-Pipelines mit Test Sharding, Teil 4
Mehr Shards können das Feedback beschleunigen, aber auch zugleich die CI-Kosten erhöhen. Ein Vergleich mit zwei Referenzläufen zeigt, wo sich zusätzliche Runner lohnen. Ebenso wichtig ist der Nachweis, dass weiterhin alle vorgesehenen Tests laufen.
6 Minuten
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige