Infrastruktur als Code auf Azure: Bicep vs. Terraform vs. Pulumi

Auf Azure sind drei der offensichtlichsten Optionen für Infrastructure as Code(IaC) Bicep, Terraform und Pulumi. Bicep ist Microsofts eigene domänenspezifische Sprache, wohingegen Terraform das Open-Source-Tool ist, das nicht an die Cloud gebunden ist. Während Bicep und Terraform beide ihre eigene Sprache haben, können Sie mit Pulumi Ihre Infrastructure as Code in Ihrer Lieblingssprache wie C#, Python oder Go schreiben.

Ziel dieses Artikels ist es, die drei Tools miteinander zu vergleichen und Ihnen ein ausreichendes Verständnis für jedes dieser Tools zu vermitteln, damit Sie eine gute Wahl treffen können, wenn es um ein Infrastructure as Code-Tool für Ihr nächstes Projekt geht. Wir werden natürlich über die Funktionen jedes dieser Tools sprechen, aber was noch wichtiger ist, wir werden auch die Erfahrungen der Entwickler mit jedem dieser Tools vergleichen. Lassen Sie uns eintauchen und sehen, wer als letzter noch steht und wer als erster das Handtuch wirft.

Einführung

Bevor wir mit dem Vergleich der drei Kandidaten von heute beginnen, sollten sie sich alle erst einmal richtig vorstellen.

Bizeps

Bicep ist eine domänenspezifische Sprache (DSL), die von Microsoft entwickelt wurde. Es ist ihre Antwort auf die Probleme, die wir mit ihrem Vorgänger, den ARM-Vorlagen, hatten. ARM-Vorlagen gibt es schon seit vielen, vielen Jahren. Die Beschreibung Ihrer IaC in ARM-Vorlagen erfolgte mit JSON. Dadurch wurden ARM-Vorlagen sehr umfangreich, schwer zu lesen und noch schwerer zu pflegen. Die Aufteilung einer Vorlage in mehrere kleinere, wiederverwendbare Komponenten war viel zu schwierig. Bicep ist hier, um diese Probleme zu lösen, und es macht uns das Leben wirklich leichter. Im Gegensatz zu den beiden anderen Tools in diesem Wettbewerb kann Bicep nur für die Konfiguration von Ressourcen auf Azure verwendet werden. Dazu später mehr. Eine sehr einfache Bicep-Vorlage sieht wie folgt aus:

Das obige Beispiel stellt ein Speicherkonto auf Azure bereit. Es erhält einige Eingaben, gibt die Ressource an und liefert eine Ausgabe, die von anderen Vorlagen oder Skripten verwendet werden kann.

Terraform

Terraform ist ein Open Source IaC-Tool von HashiCorp. Es wurde 2014 entwickelt und ist, wie Bicep, eine DSL. Ein großer Unterschied zwischen Bicep und Terraform ist, dass Terraform Infrastrukturen auf allen großen Cloud-Plattformen und anderen Diensten verwalten kann. Was wir in Terraform 'Provider' nennen, ermöglicht es Terraform, mit praktisch jeder Plattform oder jedem Dienst mit einer zugänglichen API zu arbeiten. Diese Provider werden oft von den Eigentümern der jeweiligen Plattform erstellt, aber es gibt auch zahlreiche Provider, die von der Community erstellt wurden. Die meisten von ihnen sind Open Source. Bei Bedarf können Sie sogar Ihren eigenen erstellen. Das folgende Beispiel erstellt ein Speicherkonto mit Terraform.

Wie Sie sehen können, ist diese Konfiguration etwas komplexer als die Bicep-Version, die das gleiche Ergebnis liefert. In Terraform müssen Sie zunächst einen Provider konfigurieren, da Sie mit einem oder mehreren Providern arbeiten können. Ein Provider kann eine bestimmte Konfiguration haben, daher der Provider-Block 'azurerm'. Das Definieren einer Variable ist etwas ausführlicher. Sie können sie, anders als in Bicep, in eine andere Datei verschieben, was die Lesbarkeit erhöhen könnte. Das Gleiche gilt für Ausgaben, den Terraform-Block oder die Provider-Konfiguration.

Pulumi

Pulumi ist unser dritter Kandidat für heute. Es wurde nach dem Unternehmen benannt, das es 2018 entwickelt hat. Das Besondere an Pulumi ist, dass Sie Ihre Infrastruktur als Code in Ihrer Lieblingssprache schreiben können: TypeScript, JavaScript, Python, Go, .NET, Java und YAML. Wie Terraform ermöglicht es Ihnen die Verwaltung von Infrastrukturen bei praktisch jedem Cloud- oder Service-Anbieter. Selbst wenn es nicht standardmäßig unterstützt wird, können Sie immer leicht Ihren eigenen Code erstellen, um mit der API eines Service Providers zu interagieren. Das folgende Beispiel erstellt ein Speicherkonto in Azure mit C# und Pulumi.

Als erstes müssen Sie sich das Nuget-Paket für Azure besorgen. Von dort aus wird jede Ressource erstellt, indem eine Instanz einer bestimmten Klasse instanziiert und ein paar Parameter übergeben werden.

Sie fragen sich vielleicht, ob es nicht auch eine Version von Terraform gibt, in der ich eine Programmiersprache verwenden kann? Ja, das ist richtig! Sie heißt Terraform CDK (Cloud Development Kit). Ich habe es aus einigen Gründen weggelassen. Der wichtigste Grund ist, dass ich es einfach noch nie benutzt habe. Ich persönlich sehe es nicht oft in freier Wildbahn eingesetzt. Das könnte daran liegen, dass das Produkt noch nicht die Version 1.0 erreicht hat und Terraform selbst vor bahnbrechenden Änderungen warnt. Außerdem unterstützt es im Vergleich zu Pulumi ein paar weniger Sprachen.

Single oder Multi Cloud Unterstützung?

Eine wichtige Überlegung bei der Auswahl eines dieser Tools ist die Frage, auf welchen Plattformen Sie bereitstellen wollen. Zwei der drei Tools, die wir hier besprechen, Terraform und Pulumi, bieten Multi-Cloud-Unterstützung. Das bedeutet, dass sie mit mehreren Cloud-Anbietern und -Diensten interagieren können. Sie können zum Beispiel einen App Service in Azure erstellen und diese URL dann an Cloudflare weitergeben, um sie im DNS zu registrieren. Wie Sie sehen, ist das nicht nur auf die drei großen Cloud-Anbieter beschränkt, sondern schließt auch Monitoring-Tools, DNS-Anbieter, GitHub, Azure DevOps und vieles mehr ein. Ein Nachteil kann sein, dass diese Tools nicht immer alle Funktionen eines Cloud-Anbieters unterstützen oder eine neue Funktion am Tag der Einführung nicht unterstützen. Diese Dienste sind oft auf die Community angewiesen, um Funktionen zu implementieren. Bei Terraform müssen Sie darauf warten, dass der Anbieter aktualisiert wird. Da es sich meist um Open Source handelt, können Sie das natürlich auch selbst tun. Pulumi verwendet zwei Arten von Providern: "Bridged"-Provider, die Terraform-Provider verwenden, um die verschiedenen Funktionen abzubilden, die für jede API des Cloud Providers verfügbar sind, oder "native" Provider, die die Funktionen direkt von der API des Cloud Providers abbilden. Mit den überbrückten Providern haben Sie natürlich die gleichen Probleme wie mit den nativen Terraform-Providern. Beim Azure-Anbieter ist das nicht der Fall, da er ein nativer Anbieter ist. Er wird jede Nacht automatisch aktualisiert, indem er anhand der Azure-APIs neu erstellt wird.

Um Ihnen eine Vorstellung davon zu geben, wie eine Multi-Cloud-Implementierung in diesen Tools aussehen könnte, beginnen wir mit einem Beispiel in Terraform. Der folgende Code erstellt einen Azure App Service und konfiguriert eine benutzerdefinierte Domain dafür. Die Domain ist bei Cloudflare registriert.

Zunächst werden der App-Serviceplan und die Web-App selbst erstellt. Als nächstes erstellen wir die beiden Datensätze in Cloudflare. Sie können die beiden Anbieter, die wir verwenden, anhand des Namens des Typs, den wir erstellen, unterscheiden. Die Einträge für Azure beginnen mit 'azurerm', die Einträge für Cloudflare mit 'cloudflare'. Der letzte Schritt besteht darin, die Domäne für den App Service festzulegen, wenn sie in Cloudflare vorhanden ist. Mit Pulumi und C# lässt sich die gleiche Funktionalität mit folgendem Code erreichen:

Unser letzter Kandidat, Bicep, ist immer auf Augenhöhe mit jeder Funktion, die am Einführungstag in der Azure-Cloud verfügbar ist. Für Bicep ist das sehr viel einfacher, da es ein einzelnes Cloud-Tool ist, das von Microsoft selbst entwickelt und gepflegt wird. Ein großer Nachteil dieses einzigen Cloud-Tools ist, dass Sie auf die Verwaltung Ihrer Azure-Infrastruktur beschränkt sind. Genauer gesagt können Sie nur mit dem interagieren, was wir die Azure-Kontrollebene nennen. Die Azure-Operationen lassen sich in zwei Kategorien unterteilen - Control Plane und Data Plane. Einfach ausgedrückt, verwenden Sie die Steuerebene, um Ressourcen in Ihrem Abonnement zu verwalten, und die Datenebene, um die Interna einer Ressource zu verwalten. Mit Bicep können Sie zum Beispiel eine SQL-Datenbank erstellen, aber keinen Benutzer in dieser Datenbank anlegen. Bicep ermöglicht Ihnen auch keine Interaktion mit Active Directory. Die Erstellung einer Unternehmensanwendung und deren Verwendung in Ihrem IaC ist keine leichte Aufgabe. Hier gibt es hauptsächlich zwei alternative Ansätze: Sie können einen Code in Ihrer CI/CD-Pipeline ausführen und das Ergebnis beim Deployment in Bicep einspeisen oder die Ressource DeploymentScripts verwenden. Die DeploymentScripts-Ressource ermöglicht es Ihnen, ein Azure CLI- oder PowerShell-Skript während der Ausführung von Bicep auszuführen. Damit könnten wir das Beispiel mit Cloudflare durchführen, das wir in Terraform und Pulumi gesehen haben. Was unter der Haube passiert, wenn Sie eine DeploymentScripts-Ressource verwenden, ist, dass eine Azure Container-Instanz erstellt wird und ein Container zur Ausführung Ihres Skripts bereitgestellt wird. Dies ist langsam und unterstützt keine Unternehmensfunktionen wie die Netzwerkintegration. Dies schränkt die Nutzung dieser Ressource oft ein.

Die Erstellung des App-Dienstes und der Datensätze in Cloudflare mit Bicep würde wie folgt aussehen:

Wie Sie sehen, benötigen wir ein langwieriges PowerShell-Skript, das wir selbst schreiben mussten, um das zu erreichen, was die anderen Tools für uns abstrahiert haben. Sie müssen auch eine andere Sprache und ein anderes Tool beherrschen, um das gleiche Ergebnis zu erzielen.

Erfahrung als Entwickler

Ein wichtiger Unterschied zwischen diesen drei Tools ist die Sprache, die sie Ihnen zur Verfügung stellen, um Ihre Infrastruktur als Code zu schreiben. Sowohl Terraform als auch Bicep sind das, was wir eine domänenspezifische Sprache (DSL) nennen. Eine DSL ist das, was Sie sich darunter vorstellen: eine Sprache, die für einen ganz bestimmten Bereich entwickelt wurde. Im Allgemeinen sind diese DSLs im Vergleich zu einer Programmiersprache etwas leichter zu erlernen (wir werden später noch über Programmiersprachen sprechen). Das liegt zum Teil daran, dass sie weniger vollständig sind und Sie mehr in eine bestimmte Richtung leiten, in der Sie etwas tun können. Das heißt aber nicht, dass sie einfach sind. Sie müssen immer noch wissen, wie Sie die Dinge richtig strukturieren müssen, damit Ihr IaC nicht zu einem großen Durcheinander wird.

Was Pulumi von den anderen beiden Tools unterscheidet, ist, dass Sie Ihre bevorzugte Programmiersprache verwenden können, um Ihren IaC zu schreiben. Sie können Java, Node, Python, .NET (F#, C#, VB) oder GO verwenden. Jede dieser Sprachen ist viel flexibler als eine DSL. Sie sind bei mehr Menschen bekannt, werden von einer Vielzahl von IDEs und anderen Werkzeugen gut unterstützt und die Gemeinschaften, die sich um sie herum bilden, sind in der Regel viel größer. Ein Nachteil könnte sein, dass eine Programmiersprache schwieriger zu erlernen ist. Sie müssen schon ein recht erfahrener Entwickler sein, um zum Beispiel wartbaren und testbaren Code zu schreiben. Die Leistung und Flexibilität, die Sie mit einer Programmiersprache erhalten, gibt Ihnen jedoch eine unbegrenzte Ausdruckskraft und Kontrolle, die weit über das hinausgeht, was Bicep und Terraform bieten können. Sie können verschiedene Tools wie Azure App Configuration verwenden, um Ihre Konfiguration zu speichern, Key Vault zum Speichern von Geheimnissen nutzen oder Feature Flags verwenden, um neue Infrastrukturen zu verbergen oder nur für einen bestimmten Kunden bereitzustellen. Es ist auch sehr einfach, Pulumi-Code in ein von Ihnen entwickeltes Tool einzubinden. Wenn Sie ein Plattformteam sind, das ein Self-Service-Portal entwickelt, könnte Pulumi integriert werden, um die Bereitstellung für verschiedene Dienste zu verwalten. Das Onboarding eines neuen Teams könnte ein einziger Klick auf eine Schaltfläche sein, die ein Repository in GitHub erstellt, ein Abonnement in Azure einrichtet, die Verbindung zwischen GitHub und Azure herstellt und die richtigen Berechtigungen für beide Umgebungen einrichtet.

IDE und andere Hilfsmittel

Ein großer Teil der Erfahrung eines Entwicklers ist die Verfügbarkeit einer angemessenen Unterstützung in Ihrer bevorzugten IDE und zusätzlicher Tools. In Bezug auf Bicep können wir sagen, dass die Unterstützung in VS Code nach der Installation der Erweiterung wirklich gut ist. Sie unterstützt Validierung, Intellisense, Snippets, Code-Navigation, Code-Vervollständigung, Formatierung und sogar ein paar Schnellkorrekturen, wenn Sie z.B. einen Tippfehler machen. Eine Funktion, die ich häufig verwende, ist die Vervollständigung einer Ressource mit der Option 'required-properties'. Diese wird Ihnen bei der Erstellung einer Ressource wie unten gezeigt angezeigt:

Wenn ich die Eingabetaste drücke, wird die vollständige Ressource erstellt, und ich kann die erforderlichen Felder ausfüllen. Es hilft mir dann auch, den richtigen Wert für Eigenschaften einzugeben, die eine definierte Liste zulässiger Werte haben, um zu verhindern, dass ich die falsche Option auswähle oder einen Tippfehler mache.

Eine weitere interessante Funktion ist die, die es Ihnen ermöglicht, eine vorhandene Azure-Ressource zu importieren. Sie geben die Kennung an, und die Bicep-Vorlage wird generiert. Das ist ein schneller Gewinn, wenn Sie Infrastruktur als Code für Ressourcen erstellen möchten, die in der Vergangenheit manuell erstellt wurden.

Die VS Code-Erweiterung für Terraform ist nicht so vollständig wie die für Bicep. Sie sollte Dinge wie Intellisense unterstützen, aber ich stelle regelmäßig fest, dass es daran mangelt. Sie unterstützt zwar Snippets, aber nur für eine begrenzte Anzahl von eingebauten Funktionen, wie z.B. die Verwendung eines for-each oder die Erstellung einer Variablen. Es gibt keine Snippets für bestimmte Ressourcen. Das macht natürlich Sinn, da es dann Snippets für viele, viele Anbieter unterstützen müsste. Es gibt zwar Erweiterungen dafür, aber Sie müssen sie selbst finden und installieren und zumindest für Azure-Ressourcen sind sie nicht so vollständig wie in Bicep. Etwas wie die Anzeige einer Liste von Optionen für einen bekannten Wert wie die Speicher-SKU im obigen Bicep-Beispiel ist in mindestens drei Erweiterungen, die ich ausprobiert habe, nicht verfügbar.

Die Entwicklererfahrung in der IDE für Pulumi ist völlig unterschiedlich. Es hängt von der Sprache ab, in der Sie Ihr IaC schreiben, und von dem Editor, den Sie verwenden. Die Erfahrung unterscheidet sich nicht von der, die Sie beim Schreiben einer beliebigen Anwendung mit diesem Tool und dieser IDE machen. Ich kann nur für C# in Kombination mit VS Code, Jetbrains Rider oder der Vollversion von Visual Studio sprechen. Meiner Meinung nach ist die Erfahrung der Entwickler viel besser als bei den anderen beiden Tools. Eine vollwertige IDE wie Rider oder Visual Studio in Kombination mit einer leistungsstarken Sprache ist einfach schwer zu schlagen.

Wenn wir einen Blick über die IDE hinaus auf zusätzliche Tools werfen, dann sehen wir, dass Terraform wirklich gute Arbeit leistet. Es gibt eine Menge zusätzlicher Tools, die Ihnen helfen, die Dinge überschaubar und sicher zu halten. Um nur einige zu nennen: TFLint (ein statisches Analysetool für Terraform-Code, das Ihnen hilft, Stilprobleme, Syntaxfehler und Verstöße gegen die Best Practices zu erkennen und zu beheben), TFSec (nutzt die statische Analyse Ihres Terraform-Codes, um potenzielle Fehlkonfigurationen zu erkennen), terratest (eine Go-Bibliothek, die Muster und Hilfsfunktionen für das Testen der Infrastruktur bereitstellt), checkov (Checkov ist ein statisches Code-Analysetool für Infrastruktur als Code) und terraform-docs(generiert die Dokumentation der Terraform-Module in verschiedenen Formaten). Alle diese Tools lassen sich gut mit git pre-commit integrieren, so dass Sie unerwünschten Code in Ihrem Hauptzweig verhindern können.

Bicep hinkt ein wenig hinterher, holt aber schnell auf. Vor kurzem wurde zum Beispiel die Unterstützung für checkov hinzugefügt. In Bicep selbst ist ein Linter integriert, der eine ganze Reihe von Regeln enthält, die automatisch überprüft werden. Für diejenigen, die mit ARM Templates gearbeitet haben, sind diese Regeln die gleichen wie im ARM Template Toolkit. Bicep wird auch von PSRule unterstützt, einem plattformübergreifenden PowerShell-Modul zur Validierung der Infrastruktur als Code. Es enthält derzeit über 250 Regeln für von Microsoft definierte Best Practices. PSRule ermöglicht es Ihnen auch, eigene Tests zu schreiben und ist somit erweiterbar. Da Bicep in eine ARM-Vorlage transpiliert wird (Transpilieren ist ein spezieller Begriff für die Umwandlung von Quellcode, der in einer Sprache geschrieben wurde, in eine andere Sprache, die ein ähnliches Abstraktionsniveau hat), wird jedes Tool, das dort unterstützt wird, auch für Bicep unterstützt, obwohl das nicht immer ideal ist, da Sie Ihre Ergebnisse dann auf einer generierten ARM-Vorlage statt auf Ihrer spezifischen Bicep-Vorlage erhalten.

Das Ökosystem für Pulumi scheint im Vergleich zu den anderen beiden Tools viel kleiner zu sein. Natürlich können Sie auch allgemeinere Tools verwenden, die mit der Sprache Ihrer Wahl funktionieren. Ein Test-Framework ist ein gutes Beispiel. Ich habe keinen Sicherheitsscanner wie TFSec oder SonarCloud gefunden, der Pulumi unterstützt. SonarCloud könnte zum Beispiel Ihren C#-Code scannen, aber es wird nicht darauf achten, wie Sie ein Speicherkonto speziell konfigurieren.

Entwicklerfluss

Die Erstellung einer Infrastruktur mit einem dieser Tools beginnt mit dem Schreiben des Codes. Wenn Sie diesen Code bereitstellen möchten, sieht die Sache ein wenig anders aus. Terraform und Pulumi nehmen beide den Standardweg, indem sie zuerst herausfinden, was geändert werden muss, Ihnen das Ergebnis zeigen, Sie fragen, ob es korrekt ist, und Ihnen dann die Möglichkeit geben, die Bereitstellung zu bestätigen oder abzubrechen. In Terraform verwenden Sie häufig den Befehl 'terraform plan', um herauszufinden, was geändert werden muss, und führen dann den Befehl 'terraform apply' aus, um die Änderungen anzuwenden. Pulumi hat eine ähnliche Funktionalität. Im Folgenden sehen Sie ein Beispiel dafür, was Pulumi uns präsentiert, wenn wir ein einfaches Speicherkonto einrichten, wie Sie es in der Einführung von Pulumi gesehen haben.

Pulumi und Terraform können Ihnen diese Funktionalität bieten, da sie jedes einzelne Detail der Infrastruktur, die Sie bereitstellen, in einer so genannten Statusdatei speichern. Dadurch können sie Ihre aktuellen Vorlagen mit dem vergleichen, was bereitgestellt werden soll und wie die Konfiguration in Ihrer Cloud oder Ihren Diensten aussieht. Das bedeutet allerdings, dass dieser Status irgendwo gespeichert werden muss. Beide Tools bieten einen SaaS-Service an, der dies für Sie übernimmt, wofür sie natürlich eine Gebühr verlangen. Sie können diese Statusdateien auch z.B. in einem Azure-Speicherkonto speichern. Sie müssen diese Dateien sicher aufbewahren, da sie, insbesondere bei Terraform, Plantext-Passwörter und Schlüssel enthalten.

Bicep kennt diesen Zustand nicht. Azure ist sein Zustand. Jedes Mal, wenn Sie eine Bereitstellung durchführen, werden Ihre Bicep-Vorlagen mit dem aktuellen Zustand in Azure verglichen und die Änderungen werden übernommen. Optional können Sie das Flag -what-if verwenden. Das zeigt Ihnen dann, welche Änderungen vorgenommen werden. Diese Funktion enthält jedoch noch einige Bugs und ist daher nicht so zuverlässig wie die beiden anderen Tools (1).

Ein weiterer Unterschied zu den anderen beiden Tools besteht darin, wo die Änderungen ausgeführt werden: serverseitig oder clientseitig. Bicep wird serverseitig ausgeführt. Ihre Bicep-Vorlagen werden in ARM umgewandelt und dann an den Azure Resource Manager gesendet. Die beiden anderen Tools führen Ihre Änderungen lokal mit ihren Engines aus, indem sie APIs aufrufen. Das hat ein paar Vorteile. Einer davon ist zum Beispiel, dass Terraform und Pulumi es Ihnen ermöglichen, zwischen der Bereitstellung von zwei Ressourcen eine bestimmte Zeit zu warten. Das kann manchmal praktisch sein, wenn Sie Berechtigungen zuweisen und ein paar Sekunden warten müssen, bis diese in Kraft treten. Bicep bietet eine solche Funktion nicht.

(1): WhatIfIssues

Wie beim Schreiben jeder Software werden Sie auch beim Schreiben Ihres IaC auf Probleme stoßen, Fehler finden, die Sie nicht erklären können, oder Fragen haben, wie Sie am besten vorgehen. Daher ist es wichtig, dass die Waffe Ihrer Wahl eine große und lebendige Community hat, die Sie erreichen können. Es ist etwas schwierig, "groß" und "lebendig" zu quantifizieren. Ich habe mir sowohl die Suchtrends bei Google als auch bei StackOverflow angesehen. Beginnen wir mit der ersten. Wenn wir uns die Anzahl der Fragen ansehen, die unter Verwendung eines bestimmten Tags gepostet wurden, sehen wir die folgenden Daten:

 

Was wir daraus lernen, ist, dass Terraform bei weitem die meisten Fragen und Aktivitäten auf der Plattform hat. Die Ergebnisse für Bicep und Pulumi sind recht ähnlich. Wir müssen an dieser Stelle allerdings darauf hinweisen, dass die Fragen für Bicep natürlich auch immer Azure-spezifisch sein werden. Das wird bei Pulumi nicht der Fall sein, so dass es dort möglicherweise weniger relative Fragen und Antworten gibt.

Die nächste Grafik zeigt die Google-Suchtrends für die folgenden drei Schlüsselwörter im letzten Jahr: azure bicep (wie Sie sich vorstellen können, liefert bicep eine Menge anderer Ergebnisse...), Terraform und Pulumi.

Rot: Terraform, Blau: Bizeps, Gelb: Pulumi

Auch hier sehen wir, dass Terraform bei weitem die meisten Suchanfragen bei Google erhält. Bicep und Pulumi liegen so weit zurück, dass wir aus dieser Grafik keine brauchbaren Zahlen für sie ableiten können. Die nächste Grafik zeigt nur Bicep und Pulumi für die letzten 5 Jahre.

Rot: Pulumi, Blau: Bizeps

Wir sehen hier, dass Pulumi im Vergleich zu Bicep auf den ersten Blick beliebter ist. Wenn man bedenkt, dass die Zielgruppe von Pulumi viel größer ist, könnte man argumentieren, dass Sie mit Bicep wahrscheinlich bessere Ergebnisse erzielen, da sie für Sie relevanter sind. Der Aufwärtstrend ist bei allen drei Tools recht ähnlich.

Also, welche?

Nun, da wir diese drei Tools aus verschiedenen Blickwinkeln betrachtet haben, ist es an der Zeit, den Sieger zu küren. Leider hängt das, wie immer, von verschiedenen Faktoren ab. Beginnen wir mit Bicep. Ich finde, es ist am einfachsten zu erlernen und anderen zu erklären. Das Tooling ist gut und es ist sehr einfach und schnell, Ihre erste Ressource bereitzustellen. Dass der Status nicht irgendwo gespeichert werden muss, ist ein kleines Plus. Es kann nur Elemente in der Azure-Cloud konfigurieren, was seine Einsatzmöglichkeiten stark einschränkt. Ich würde mich für Bicep entscheiden, wenn Sie mit einem unerfahrenen Team nur an kleinen Umgebungen in der Azure-Cloud arbeiten.

Terraform ist viel leistungsfähiger und daher eine gute Wahl für fortgeschrittene Umgebungen, die mehrere Cloud- oder Service-Anbieter umfassen. Mit Terraform können Sie auch die Interna einer Ressource konfigurieren (erinnern Sie sich an die Diskussion über die Kontrollebene im Vergleich zur Datenebene bei Bicep?), so dass Sie Ihre Infrastruktur wirklich durchgängig in einer einzigen Sprache konfigurieren können. Mit der Macht kommen Komplexität und Verantwortung. Da Sie den Status verwalten und lernen müssen, damit zu arbeiten, ist die Lernkurve von Terraform im Vergleich zu Bicep etwas steiler. Ich würde Terraform für jedes Projekt wählen, das nicht super einfach ist, es sei denn...

Pulumi ist bei weitem das mächtigste Werkzeug der drei. Die Ausdruckskraft, Macht und Freiheit, die eine Programmiersprache bietet, ist unvergleichlich. Wenn Sie mit einem kleineren Ökosystem leben können, das sich möglicherweise ändert, und Ingenieure haben, die wissen, wie man eine Programmiersprache benutzt, wäre Pulumi meine erste Wahl.

Den gesamten in diesem Artikel verwendeten Code finden Sie hier

Möchten Sie Ihr Wissen über Azure erweitern? Erfahren Sie mehr, buchen Sie ein Training