Terraform oder doch lieber OpenTofu - Kommt die IaC-Revolution?

Sechs Monate nach der Veröffentlichung von OpenTofu untersuchen wir, ob ein Wechsel weg von Terraform sinnvoll oder sogar notwendig ist.


  •  Daniel Lohausen
  •  
  • DevOps

In diesem Artikel blicken wir kurz auf die Gründe und Auswirkungen der Lizenzwechsels von Terraform zurück, schauen was seit dem passiert ist und geben eine Prognose für die Zukunft - Terraform oder OpenTofu?

Was ist OpenTofu und wie entstand es?

Vor sechs Monaten ging ein Raunen durch du DevOps Community – HashiCorp änderte die Lizenz ihrer populärsten Software “Terraform”. Terraform ist DAS Werkzeug zur Verwaltung von Infrastrukturkomponenten via Code (Infrastructure as Code oder IaC).

Bis Version 1.5 war Terraform unter der Mozilla Public License (MPL) lizensiert, die im Wesentlichen erlaubt den frei verfügbaren Quellcode von Terraform zu nutzen, wie man möchte. Die neue Business Source License (BUSL) ist da restriktiver und verbietet die Nutzung des Codes für kommerzielle Anwendungen, die mit Produkten von HashiCorp in Konkurrenz stehen. Diese Änderung richtete sich explizit an die Anbieter von kommerziellen IaC-SaaS Diensten wie Gruntwork oder env0, die Terraform unter der Haube nutzen um in direkter Konkurrenz zu HashiCorps eigenem kommerziellen Angebot „Terraform Cloud" stehen. Für Endanwender von Terraform hat diese Änderung von Terraform keine Auswirkungen, wie HashiCorp in ihrem FAQ klarstellt.

Die Reaktion der Wettbewerber war drastisch: Man warf HashiCorp vor Terraform mit diesem Schritt zu vergiften („Poison pill for Terraform“) und kopierte den kompletten Source-Code – Mit der damals noch gültigen MPL Lizenz ist das erlaubt. Auf diesem Code-Stand („Fork“) soll eigenständig weiterentwickelt werden. Als Name wurde „OpenTofu“ gewählt und viele Personenjahre Support versprochen.

Wo stehen wir nun, sechs Monate später?

Aktueller Stand

Organisation

OpenTofu ist mittlerweile Teil der LinuxFoundation, die Open-Source Entwicklung fördert und standardisiert (aber von Unternehmen finanziert wird.). Dieser Schritt ist logisch, denn hier wird der rechtliche Rahmen vor der Lizenzumstellung von Terraform (Der Code kann frei verwendet werden, daher können verschiedene Anbieter darauf kommerzielle Produkte aufbauen.) für OpenTofu für die Zukunft zementiert.

Kommerziellen Support für OpenTofu gibt es (noch) nicht.

Am 10.01. wurde die erste offizielle Version von OpenTofu veröffentlicht. Neben einem Test-Feature (s.u.) wurde eine eigene Verwaltung der Terraform-Provider für die verschiedenen Cloud- und SaaS Dienste (AWS, Azure, GCP) aufgebaut. Was war nochmal mit Providern?

Provider

Provider sind die eigentliche Schnittstelle zu dem Cloud-Dienst, der mit Terraform bzw. Tofu verwaltet werden soll. Hier ist die Logik programmiert um Cloud-Resourcen zu erstellen, den Zustand auszulesen, sie zu modifizieren und zu löschen (CRUD). Provider gibt es natürlich für die großen Cloud-Anbieter wie AWS, Azure und GCP, aber auch für spezifischere SaaS-Dienste aus unterschiedlichen Bereichen wie z.B. Jira, Pingdom, Github, LogzIO und viele mehr. Ein großer Vorteil von Terraform ist das HashiCorp mit den großen Cloud-Anbietern eng zusammen arbeitet, so das neue Funktionen sehr zeitnah mittels der Provider in Terrafom nutzbar sind. Und neue Funktionen gibt es dort ja wöchentlich.

Wie sieht es denn bei OpenTofu aus? Genauso. Der Source-Code der Provider ist nämlich nach wie vor unter MPL lizensiert und wird von OpenTofu auch eingesetzt. Es gibt zwar eine eigene Registry, aber mit gleichen Inhalt.

Technik

Aktuell sind OpenTofu und Terraform noch komplett kompatibel. Die interne Repräsentation des Zustands der Infrastruktur (“State”) ist identisch, zumindest bei kleineren Projekten habe ich das überprüft. Die Syntax ist gleich und auch Konsolenausgaben noch identisch - bis auf den Namen.

Verglech von 'terraform apply' und 'tofu apply'

Wer findet die Unterschiede?

Zum Zeitpunkt des Forks war eine neue Funktionalität von Terraform im Alpha-Zustand - ‘Terraform test’ erlaubt das Verifizieren von Infrastruktur-Kompenten. (Anmerkung: Für mich ist der Wert dieser Funktion fragwürdig, da zum Verifizieren auch Terraform selbst benutzt wird. Terraform ist ja eine deklarative Sprache - Wenn ich also festlege, dass eine Datenbank mit dem Namen ‘Meine-Datenbank’ erstellt werden soll, wird das ja nach dem Erstellen schon jetzt geprüft. Was habe ich mit einem expliziten Test-Schritt gewonnen, der dieselbe Technologie nutzt? Eventuell kann es bei großen Projekten oder Modulen hilfreich sein. Ich selbst würde zum Verifizieren aber ein gesondertes Tool wählen.) Die Funktion ist nun sowohl in der aktuellen Terraform Version als auch in der aktuellen OpenTofu Version verfügbar. Auch hier funkionieren beide gleich - Allerdings ist die Dokumentation bei Terraform deutlich besser, was die Nutzung vereinfacht. Dies ist auch nicht verwunderlich, viele OSS-Projekte leiden unter knapper Dokumentation.

Fazit

Technisch sind Terraform und OpenTofu noch äquivalent. Aktuell ist mir nicht bekannt das ein End-Nutzer von Terraform nach OpenTofu gewechselt ist - Was ja kein Wunder ist, da der erste Release erst kürzlich erfolgt ist. Allerdings gibt es auch noch keinen Grund zu wechseln - Das wird erst interessant werden, falls OpenTofu ein USP anbieten kann, also ein Feature das Terraform nicht anbietet. Das ist aus meiner Sicht aktuell aber noch nicht zu erwarten - OpenTofu war bis zuletzt mit dem Aufsetzen der gesamten Infrastruktur (Provider-Registry) beschäftigt, und ich kann mir vorstellen das da noch einiges kommen wird (80%-Regel).

Irgendwann werden Terraform und OpenTofu divergieren. Als End-Nutzer solltest du dann Folgendes tun:

  1. Abwarten
  2. Nach 3-6 Monaten den Sachverhalt noch einmal prüfen. Dann sollte es besser einschätzbar sein, wie die Änderungen aufgenommen wurden. Werden sie überhaupt benutzt? Wo gibt es bessere Tutorials und schnellere Bugfixes? Vielleicht sind sie auch im konkreten Fall irrelevant (Stichwort: “terraform test”). Dann kann man einfach weiter abwarten. Man sollte erst dann entscheiden, wenn die Entscheidung nötig ist (und dann auch aktiv werden).

Ich glaube, dass Terraform die Nase vorne haben wird. Sie haben einfach die größere Erfahrung mit der Codebase und dem Ecosystem und eine enge Bindung an die Cloud-Provider, für die Terraform / OpenTofu ja hauptsächlich genutzt wird. Dann wird es vor allem spannend für Dienstleister wie Gruntwork, env0 und Co. und deren Kunden. Wollen Sie tatsächlich bei OpenTofu bleiben und Stück für Stück vom Standard wegdivergieren?

Dass OpenTofu der neue Standard wird, kann ich mir nicht vorstellen. Aber wenn es doch so passieren sollte, dann war der Lizenzwechsel tatsächlich der Sargnagel für HashiCorp.

Über den Autor

img/team/lohausen.jpg Daniel Lohausen

Daniel Lohausen

Als Cloud-Architekt und Prozess-Coach vereint Daniel Lohausen zwei Kernelemente erfolgreicher Softwareentwicklung in einem ganzheitlichen Beratungsansatz. Er ist überzeugt, dass sich technische und prozedurale Innovationen positiv beeinflussen und man die besten Ergebnisse erzielt, wenn man bei beide Aspekte konstant weiter entwickelt.