Das Wichtigste in Kürze

• Terraform nutzt HCL (HashiCorp Configuration Language) — deklarativ und leicht lesbar.
• Pulumi nutzt echte Programmiersprachen (Python, TypeScript, Go) — volle IDE-Unterstützung.
• Terraform hat das größere Ökosystem mit über 3.000 Providern und der breitesten Community.
• Pulumi ermöglicht Schleifen, Conditionals und Abstractions nativ — ohne Workarounds.
• Die BSL-Lizenzänderung von Terraform hat OpenTofu als Fork hervorgebracht.

---

Infrastructure as Code ist unverhandelbar — die Frage ist nur, welches Tool. Terraform dominiert den Markt mit dem größten Ökosystem und der breitesten Adoption. Pulumi fordert den Platzhirsch mit echten Programmiersprachen und modernem Developer-Experience heraus. Beide haben klare Stärken — und die richtige Wahl hängt vom Team ab.

Terraform: Der Industriestandard

Terraform hat Infrastructure as Code populär gemacht. HCL (HashiCorp Configuration Language) ist deklarativ: Man beschreibt den gewünschten Zustand, Terraform berechnet den Plan und führt die Änderungen aus. Die Sprache ist bewusst limitiert — keine Schleifen, keine komplexen Conditionals, kein vollständiger Programmierfluss. Das Argument: IaC sollte lesbar und reviewbar sein, nicht programmiert.

Das Ökosystem ist Terraforms größte Stärke: Über 3.000 Provider (AWS, Azure, GCP, Kubernetes, Datadog, GitHub, Cloudflare — fast alles), die Terraform Registry als zentrale Modulbibliothek und eine Community, die Stackoverflow-Antworten für jedes Problem liefert.

State Management ist zentral: Terraform speichert den aktuellen Zustand in einer State-Datei. Remote State (S3, Terraform Cloud) ist Pflicht für Teams. State Locking verhindert parallele Änderungen.

Pulumi: Infrastructure als echte Software

Pulumi bricht mit der DSL-Tradition: Statt einer eigenen Konfigurationssprache nutzt man Python, TypeScript, Go, C# oder Java. Das bedeutet: volle IDE-Unterstützung (Autocomplete, Type Checking, Refactoring), echte Schleifen und Conditionals, Unit Tests mit Standard-Frameworks und Wiederverwendung über Packages statt Module.

Das ist besonders mächtig für komplexe Infrastruktur: Eine Schleife, die 50 ähnliche Ressourcen mit leichten Variationen erstellt, ist in Pulumi drei Zeilen Python. In Terraform erfordert es count oder for_each mit String-Interpolation — funktional, aber weniger elegant.

Pulumi unterstützt denselben Provider-Katalog wie Terraform (über Terraform Bridge) plus eigene native Provider. Der State wird wahlweise in Pulumi Cloud (SaaS) oder Self-Managed-Backends (S3, Azure Blob) gespeichert.

OpenTofu: Der Terraform-Fork

2023 änderte HashiCorp die Terraform-Lizenz von Open Source (MPL) zu Business Source License (BSL). Die Community reagierte mit OpenTofu — einem Fork, der unter der Linux Foundation als echtes Open-Source-Projekt weiterentwickelt wird.

OpenTofu ist zu 100% kompatibel mit Terraform 1.5.x und wird parallel weiterentwickelt. Neue Features (State Encryption, frühe Variable-Evaluation) differenzieren OpenTofu zunehmend. Für Unternehmen, denen Open-Source-Lizenzen wichtig sind, ist OpenTofu die direkte Terraform-Alternative ohne Migration.

Head-to-Head: Konkreter Vergleich

Lernkurve: Terraform/HCL ist in 2-3 Tagen erlernbar. Pulumi setzt Programmierkenntnisse voraus, die Einstiegshürde ist für Nicht-Entwickler höher, für Entwickler niedriger.

Testing: Terraform-Tests mit Terratest (Go) oder tftest sind möglich, aber nicht nativ. Pulumi nutzt Standard-Test-Frameworks (pytest, Jest, Go test) — Testing fühlt sich natürlich an.

Modularisierung: Terraform nutzt Module (HCL-Directories). Pulumi nutzt Packages (npm, pip, Go modules) — mit Versionierung, Dependency Management und dem vollen Package-Ökosystem.

State Management: Beide brauchen Remote State. Terraform State ist JSON und manuell editierbar (nicht empfohlen). Pulumi State ist verschlüsselt und nur über die CLI zugänglich.

Entscheidungshilfe: Wer sollte was nutzen?

Terraform/OpenTofu wenn: Das Team primär aus Ops/Infra-Engineers besteht, HCL-Lesbarkeit für Reviews wichtig ist, das Ökosystem (Module, Provider, Community) entscheidend ist, oder die Organisation bereits Terraform nutzt.

Pulumi wenn: Das Team primär aus Entwicklern besteht, komplexe Infrastruktur-Logik (Schleifen, Conditionals, Abstractions) nötig ist, Testing als First-Class-Feature gewünscht ist, oder das Team bereits Python/TypeScript/Go beherrscht.

Beide sind produktionsreif und Enterprise-fähig. Die Wahl ist eine Team-Entscheidung, keine Technologie-Entscheidung.

Frequently Asked Questions

Kann man von Terraform zu Pulumi migrieren?

Ja. Pulumi bietet tf2pulumi, das Terraform-Code automatisch in Pulumi-Code konvertiert. Der Terraform-State kann importiert werden. Die Migration ist inkrementell möglich — man muss nicht alles auf einmal konvertieren.

Ist OpenTofu ein vollwertiger Terraform-Ersatz?

Ja, für bestehenden Terraform-Code. OpenTofu ist ein Drop-in-Replacement: terraform init wird zu tofu init, alle Provider und Module funktionieren. Neue Features divergieren zunehmend, aber die Basis bleibt kompatibel.

Welches Tool für Kubernetes-Infrastruktur?

Beide funktionieren gut mit dem Kubernetes-Provider. Für reine Kubernetes-Manifeste ist aber weder Terraform noch Pulumi ideal — hier sind Helm, Kustomize und GitOps (ArgoCD/Flux) die besseren Tools. Terraform/Pulumi für die Cluster-Infrastruktur (VPC, EKS, Node Groups), GitOps für die Workloads.

Wie handhabt man Secrets in IaC?

Terraform: Sensitive-Markierung in Variables, aber State enthält Klartext-Werte. State-Verschlüsselung über das Backend (S3 mit KMS). Pulumi: Secrets werden nativ im State verschlüsselt — ein Security-Vorteil gegenüber Terraform.

Lohnt sich CDK (AWS) als Alternative?

AWS CDK ist nur für AWS relevant und synthetisiert CloudFormation. Für reine AWS-Shops eine gute Option. Für Multi-Cloud oder Provider-agnostische IaC nicht geeignet. CDKTF (CDK for Terraform) kombiniert CDK-Syntax mit Terraform-Providern — ein interessanter Hybrid.

Quelle des Titelbildes: Pexels / Markus Spiske