© Ion Chiosea, 123RF

Pulumi verspricht Admins und Entwicklern eine einheitliche Schnittstelle und Oberfläche für die Orchestrierung verschiedener Clouds und von Kubernetes.

Unter dem Begriff Cloud fassen Admins und Entwickler mittlerweile eine ganze Reihe von technischen Ansätzen und Konzepten zusammen, die ursprünglich nicht zur Definition der Cloud gehörten. Anfangs verstand man unter einer Cloud klassische Virtualisierung, verbunden mit einer On-demand-API, die Selbstbedienung ermöglichte. Mittlerweile ist die Industrie aber schon viel weiter. Zur Cloud gehört heute nach allgemeiner Definition auch die Möglichkeit, die eigenen Ressourcen darin zentral und schnell zu verwalten. Das ist nur folgerichtig: Wenn ein großer IT-Trend die Cloud ist und ein anderer großer Trend ein stetig steigendes Level an Automation anstrebt, ist klar, dass die beiden Faktoren irgendwann zusammenwachsen.

Im Kontext der Cloud erscheint das Zusammengehen zudem sehr sinnvoll. Wer eine virtuelle Umgebung aus einem Netzwerk, einem Load-Balancer, mehreren Applikationsservern, einer Datenbank, öffentlichen IP-Adressen und den passenden Firewall-Regeln braucht, der kann sich all diese Dienste entweder über die zuständigen APIs händisch zusammenkonfigurieren, oder er setzt auf Orchestrierung und beschreibt den Wunschzustand seines Setups in einer Template-Datei. Die verfüttert er anschließend an den Orchestrierungsdienst der jeweiligen Cloud, der die benötigten Ressourcen flugs einrichtet. Ein einzelner Befehl genügt, um die virtuelle Umgebung vollständig aus dem Boden zu stampfen. Das kommt gerade denen zugute, die ähnliche Setups regelmäßig anlegen müssen, etwa Entwicklern.

Viele Standards

Nun ist das Schöne an Standards bekanntlich, dass es so viele davon gibt. Das Thema Orchestrierung in der Cloud macht da keine Ausnahme. AWS hat einen eigenen Dienst namens CloudFormation für diese Aufgabe. Auch Azure von Microsoft oder Googles Cloud-Dienste lassen sich orchestrieren. Kommen private Clouds wie OpenStack ins Spiel, gibt es hier ebenfalls entsprechende Schnittstellen. Dann ist da auch noch Kubernetes: Wer entsprechende Workloads in AWS betreiben will, der muss sich erst die AWS-Ressourcen zusammenbasteln und anschließend das daraus entstandene Kubernetes mit der passenden Konfiguration betreiben. Interfaces gibt es also genug.

Die Idee, sämtliche Clouds mit denselben Templates zu bespielen, bleibt bislang ein schöner Traum. Zwar bieten manche Dienste eine Kompatibilitätsschnittstelle für Templates von AWS, weil das der Branchenprimus ist. Verlassen sollte man sich darauf jedoch nach der Erfahrung des Autors nicht. So steht der Admin vor dem großen Dilemma, dass er theoretisch lernen müsste, die Orchestrierung von diversen Clouds zu verwenden und jeweils eigene Templates zu pflegen. Werkzeuge wie Terraform (Abbildung 1) treten mit dem Versprechen an, genau das zu vermeiden. Ein relativ junger Player auf dem Feld dieser Werkzeuge ist Pulumi. Es unterscheidet sich deutlich von anderen Werkzeugen, indem es auf bekannte Programmiersprachen setzt statt auf eine eigene deklarative Syntax. Wie funktioniert das, und was hat der Admin davon?

Abbildung 1: Terraform gilt als Platzhirsch in Sachen Orchestrierung, kommt aber mit einer eigenen Skriptsprache daher. Pulumi setzt hingegen auf Skriptsprachen, die viele Admins schon kennen.

Infrastruktur als Code

Das zentrale Versprechen von Pulumi ist jenes der Infrastruktur als Code. Der Admin soll seine virtuelle Infrastruktur also in Form von Code beisteuern, und Pulumi kümmert sich darum, dass die virtuellen Ressourcen in der Zielplattform danach wie angefordert laufen. Das ist an und für sich erst einmal kein bahnbrechendes Feature, denn das können andere Multi-Cloud-Orchestrierer wie Terraform auch. Pulumi hebt als eigenes Killer-Feature jedoch heraus, dass es keine eigene Skriptsprache erfunden hat, sondern stattdessen auf bewährte Programmiersprachen setzt. Was genau darf der Admin sich darunter vorstellen?

Wirft man einen Blick auf andere Lösungen wie Terraform, merkt man schnell, dass sie eine sogenannte deklarative Skriptsprache nutzen. Auf Basis einer Markup-Sprache wie YAML oder JSON definiert der Admin üblicherweise Ressourcen in einer einzelnen Datei und gibt diese anschließend an den Orchestrierer weiter. Der wertet die DSL-Datei aus und interpretiert sie entsprechend. Der Nachteil aus Sicht des Admins: Er muss die deklarative Skriptsprache erlernen und verstehen, um mit dem Programm arbeiten zu können.

Pulumi geht einen anderen Weg und setzt stattdessen auf die Syntax existierender Skriptsprachen. Beherrscht der Admin also beispielsweise Python (Abbildung 2), kann er seine Infrastruktur in ein Python-Skript verpacken. Pulumi liefert die passenden Klassen für die unterschiedlichen Cloud-Anbieter, die sich wie üblich importieren lassen. Wer mit Python nichts anfangen kann, hat alternativ die Wahl zwischen Typescript, Javascript, Go (Abbildung 3) oder C#. Pulumi unterstützt sämtliche Programmiersprachen des .NET-Frameworks, also auch VB oder F#. Die meisten Entwickler finden in diesem Potpourri eine Sprache, die ihrem Geschmack entspricht.

Abbildung 2: Eine Ressourcen-Deklaration für Pulumi lässt sich, wie hier im Beispiel, in Python schreiben, um einen Storage-Account in Azure anzulegen.

Abbildung 3: Das Beispiel erledigt dieselbe Aufgabe wie das Python-Beispiel in Abbildung 2, ist jedoch in Go verfasst.

Die eigentliche Arbeit mit Pulumi läuft dann so, wie man es sich anhand der Beschreibung vorstellen würde: Der Admin lädt in einem Infrastructure-as-Code-Dokument die einzelnen Module von Pulumi, wie in der gerade gewählten Skriptsprache üblich. Pulumi nötigt den Admin dabei übrigens nicht dazu, eine besondere Umgebung für seine Entwicklung zu verwenden. Zum Einsatz kommt stattdessen der normale Editor oder die normale Entwicklungsumgebung mit allen Features, die dem Entwickler auch sonst zur Verfügung stehen.

Nichtsdestotrotz handelt es sich bei Pulumi um ein deklaratives Werkzeug: Hat der Admin seinen Code verfasst, ruft er auf der Kommandozeile »pulumi up« auf, um die beschriebene Infrastruktur in der gewünschten Umgebung zu starten. Praktisch versucht Pulumi also den Spagat zwischen der deklarativen Herangehensweise klassischer Tools wie Terraform und der bekannten Syntax gängiger Programmiersprachen.

Programm, Projekt, Stack

Wer sich erstmals mit Pulumi beschäftigt, der macht sich am besten zunächst mit dessen Programmiermodell vertraut. Hier fallen drei Begriffe ins Auge, die der näheren Klärung bedürfen: das Programm, das Projekt und der Stack. Jedes dieser drei Elemente hat innerhalb des Pulumi-Universums eine eigene Aufgabe.

Unter einem Programm subsummieren die Entwickler etwa alle Dateien, die in einer spezifischen Programmiersprache verfasst sind und zusammen eine logische Einheit bilden. Schreibt ein Entwickler für seinen Pulumi-Code beispielsweise eine eigene Python-Klasse, wäre diese im Pulumi-Sprech Teil des Programms.

Etwas größer aufgestellt ist das Projekt: Es enthält einerseits ein Programm und andererseits die für Pulumi benötigten Metadaten. Der Schritt »pulumi up« setzt nämlich voraus, dass funktionierende Metadaten für das jeweilige Programm vorliegen, sodass Pulumi weiß, was zu tun ist.

Der Stack ist schließlich eine konkrete Inkarnation eines Projekts auf einer Cloud-Plattform. Der Zustand Stack ist also erreicht, wenn der Admin per Pulumi definierte Infrastruktur auf einer Cloud-Plattform erfolgreich gestartet hat und im Anschluss nutzen kann.

Die Arbeit mit Pulumi

Theoretisch klingt die Idee hinter Pulumi erst einmal großartig. Statt eine komplexe deklarative Skriptsprache zu erlernen, nutzt der Admin die Skills, die er vom Umgang mit anderen Programmiersprachen bereits besitzt. Das ist in der Tat ein Vorteil von Pulumi gegenüber anderen Lösungen wie etwa Terraform. Allzu hoch hängen sollte man diesen Vorteil aus Sicht des Admins oder Entwicklers allerdings nicht: Auch wenn Pulumi die Nutzung bekannter Programmier- und Skriptsprachen ermöglicht, wird der Admin kaum darum herumkommen, viel Dokumentation zu wälzen.

Die Möglichkeit, bekannte Skriptsprachen zu nutzen, erleichtert dem Admin ja zunächst mal die Arbeit nur insofern, als dass er mit einer gewohnten Syntax arbeiten kann. Aus einem Python-Programm heraus, das in AWS eine Instanz starten soll, muss er zugleich allerdings die passenden Funktionen hierfür aufrufen. Pulumi abstrahiert die Cloud-APIs vom Programm an dieser Stelle nicht so radikal, dass es einheitliche Befehle für verschiedene Cloud-Plattformen gäbe.

Konkret bedeutet das: Will der Admin beispielsweise eine neue Instanz in AWS starten, kann er das zwar in Go, Java oder einer der anderen unterstützten Skriptsprachen tun. Er muss sich aber damit beschäftigen, wie sich die vorliegende Aufgabe mit den Pulumi-Modulen für die diversen Clouds lösen lässt. Dazu muss er verstehen, wie das Python-Modul pulumi_aws funktioniert, das die entsprechenden Funktionen bietet. Und weil pulumi_aws Pulumi-spezifisch ist, muss sich der Admin mit dessen Syntax befassen. Das gilt umso mehr, wenn verschiedene Workloads direkt aus Pulumi heraus in unterschiedlichen Umgebungen landen sollen. Denn dann muss der Admin nicht nur verstehen, wie die AWS-Module von Pulumi funktionieren, sondern auch, wie die Module für die anderen Clouds zu benutzen sind.

Um Missverständnissen vorzubeugen: Pulumis Feature-Set orientiert sich hier klar an den Standards des Markts. Auch andere Lösungen wie Terraform abstrahieren die jeweilige Cloud-Plattform nicht weg, sondern besitzen unterschiedliche Module für unterschiedliche Umgebungen. Die hat der Admin beim Festlegen der Ressourcen ebenso zu verwenden wie in Pulumi. Der Unterschied besteht lediglich darin, dass der Admin in Pulumi eine Syntax nutzen kann, die er aus seiner vorherigen Arbeit bereits kennt. Ob das vor dem beschriebenen Hintergrund wirklich so viel Zeit spart, wie die Entwickler in ihrer Dokumentation behaupten, scheint wenigstens fragwürdig.

Vom Programm zum Projekt

Wie gestaltet sich die Arbeit mit Pulumi aus Sicht des Administrators? Zunächst steht die Pulumi-Installation auf dem Programm. Die ist allerdings nicht kompliziert: Für Linux-Systeme bietet der Hersteller ein Shell-Skript an, das der Admin aus dem Netz herunterlädt [1] und lokal aufruft. Das einzige nötige Binary, »pulumi«, liegt anschließend im privaten Verzeichnis des Nutzers. Das Skript erweitert die »PATH«-Variable automatisch so, dass sie den Ablageort der Binärdatei enthält.

Ähnlich entspannt verläuft die Installation des Programms auf anderen Systemen. Pulumi ist keineswegs Linux-spezifisch, es lässt sich ebenso auf MacOS oder Windows nutzen. Auf MacOS gehört es zur Homebrew-Kollektion [2]. Das zuvor erwähnte Skript für die Installation unter Linux funktioniert jedoch ebenso. Für Windows steht ein eigener Installationsassistent zur Verfügung, der Pulumi auf das System holt.

Der Pulumi-Service

Damit ist Pulumi fast schon für die Nutzung bereit, aber eben nur fast: Nun beschäftigt sich der Admin mit einem Dienst, der im ersten Augenblick etwas seltsam anmutet, dem sogenannten Pulumi-Service. Der heißt »app.pulumi.com« und ist ein zentral von Pulumi betriebenes Verzeichnis für Pulumi-Stacks einzelner Nutzer (Abbildung 4). Der Hersteller beschreibt den Pulumi-Service als eine Art Unterstützung des Admins beim Management seiner ausgerollten Setups: Von hier aus lassen sich diverse Parameter der Stacks verändern oder untersuchen.

Abbildung 4: Der Pulumi-Service ist eine zentrale Komponente im Pulumi-Stack und fungiert auch als grafisches Kontrollzentrum. Quelle: Pulumi

Für die Open-Source-Version von Pulumi geht der Hersteller von der Annahme aus, dass die App zentral vom Anbieter betrieben wird und für die persönliche Nutzung durch den Anwender kostenlos bleibt. Soll der Pulumi-Service kommerziell zum Einsatz kommen, fallen Lizenzkosten an, auf die der Artikel später noch im Detail eingeht. In der Enterprise-Version besteht obendrein die Möglichkeit, eine eigene Instanz des Pulumi-Services lokal zu betreiben. Das ist besonders dann eine gute Alternative, wenn man bestimmte Informationen – etwa über die eigenen Stacks und wo diese ausgerollt sind – nicht an dritte Parteien weitergeben möchte.

Für den weiteren Verlauf geht dieser Artikel von der privaten Nutzung aus, für die Pulumi nichts in Rechnung stellt. Der Admin muss sich jedoch anfänglich einen Account anlegen, denn beim ersten Aufruf von »pulumi new« will das CLI-Tool sich mit dem Service verbinden und dort einen entsprechenden Eintrag anlegen. Beim gehosteten App-Service von Pulumi funktioniert SSO über eine Vielzahl von Anbietern, etwa mittels Github-Account. Ist der Pulumi-Account angelegt, geht es mit dem eigentlichen Projekt weiter.

Das erste eigene Projekt

In einem frisch angelegten Verzeichnis führt der Admin den Befehl »pulumi new Projekt« aus. Nach der Abfrage der Login-Credentials für den App-Service von Pulumi startet ein Assistent, der den Nutzer durch die wichtigsten Schritte der Einrichtung begleitet und verschiedene Parameter abfragt. Hier kann der Admin etwa festlegen, ob es sich um ein Projekt für AWS handelt, wie die Credentials für den AWS-Account lauten oder in welcher AWS-Region der Rollout denn stattfinden soll. Dann geht es an die eigentliche Programmierung: Mittels seiner bevorzugten Skriptsprache definiert der Admin seine gewünschte virtuelle Umgebung so, dass sie alle nötigen Komponenten enthält.

Sobald das Projekt dann den Vorstellungen des Admins entspricht, steht das Deployment auf dem Plan. Der Befehl »pulumi up« wickelt im Hintergrund sämtliche nötigen Schritte ab. Hier wird auch deutlich, dass der Pulumi-Service viel mächtiger ist, als es im ersten Augenblick scheint: Die Kommunikation mit den jeweiligen Cloud-Diensten im Hintergrund etwa übernimmt der App-Service, nicht etwa das Pulumi-Binary auf dem Host des Entwicklers. Das verdeutlicht, dass der Umweg über die Pulumi-App durchaus auch Vorteile hat: Ändert ein Cloud-Anbieter etwas an seinen APIs, müssen Endanwender nicht zwingend ihre Binaries aktualisieren, damit sie die neuen Features verwenden können.

Sobald das Deployment eines Stacks aus einem Projekt heraus abgeschlossen ist, zeigt Pulumi ihn als aktiv an, und man kann ihn nutzen. Hat der Entwickler einen Fehler gemacht oder etwas vergessen, lässt sich der Stack mittels »pulumi destroy« im Ordner des Projekts auch wieder ins Nirvana befördern. In Summe erweist sich der Pulumi-Service als hilfreiches Werkzeug im Entwicklungsalltag.

Unterstützte Zielplattformen

Wie Pulumi Applikationen auf Clouds bringt, hat dieser Artikel damit hinreichend ausführlich erläutert. Doch welche Clouds befeuert der Admin bei Bedarf mit Pulumi eigentlich? Dass die großen Hyperscaler im Bunde nicht fehlen, ist klar: AWS, Azure und Googles Compute Platform unterstützt Pulumi nicht nur, sondern sogar mit der höchsten Abdeckung einzelner Funktionen. AWS beispielsweise bezeichnet ja nur ein Dach, unter dem mittlerweile Hunderte von Dienste logieren. Pulumi kann nicht jeden davon ansprechen, doch im normalen Arbeitsalltag mit AWS dürfte der Admin kaum auf fehlende Funktionalität stoßen. Dasselbe gilt für Microsofts Azure und Googles Cloud.

Schon deutlich weniger entspannt geht es bei privaten Lösungen zu. Für OpenStack gibt es einen Ressource Provider – so heißen die Plugins, die Pulumi um Support für bestimmte OpenStack-Features erweitern. Der Provider beherrscht aber längst nicht alle Funktionen, die moderne OpenStack-Installationen bieten. Er beschränkt sich auf eher grundlegenden Support, komplexere Aufgaben lassen sich per Pulumi nicht abwickeln. Das mag auch daran liegen, dass die meisten Nutzer Pulumi schlicht mit den großen Providern nutzen und sich bei der Nutzung von Pulumi mit privaten Clouds zusätzliche Probleme ergeben. Wer etwa eine private Cloud einsetzt, die sich über das Internet nicht erreichen lässt, braucht zwangsläufig die Pulumi-Enterprise-Version, damit er den Pulumi-Service lokal betreiben kann. Wer in die großen Public Clouds will, wird mit dem Programm keine Probleme bekommen; für private Clouds eignet es sich jedoch eher nicht.

Support auch für Kubernetes

Zusätzlich zu den echten IaaS-Angeboten bietet Pulumi mittlerweile auch starken Support für Kubernetes. Kein Wunder: Streng genommen ist Kubernetes ja auch nichts anderes als ein Flottenorchestrierer. Hier spielt sich die Magie allerdings eine Stufe höher ab als bei den klassischen Clouds. Kubernetes geht davon aus, dass es Zugriff auf lauffähige Systeme hat, auf denen es seine Komponenten installieren und Container betreiben kann. Ein Werkzeug wie Pulumi wäre gegenwärtig ohne Support für Kubernetes schwer vorstellbar. Es ergibt also Sinn, dass die Entwickler eben diese Funktion in ihre Software integrieren. Hier gilt freilich wieder die Einschränkung, dass der Pulumi-Service mit der Kubernetes-API kommunizieren können muss, damit das Deployment klappt. Lässt sich die Kubernetes-Instanz nur über eine lokale Verbindung erreichen, ist wieder ein lokaler Pulumi-Service nötig, der die Enterprise-Version des Produkts voraussetzt.

Policy as Code

Ein Feature in Sachen Sicherheit heben die Pulumi-Entwickler besonders hervor, und tatsächlich hat das Produkt hier eine Art Alleinstellungsmerkmal. Policy-as-Code steht beim Produkt Pulumi CrossGuard im Vordergrund.

Das Narrativ dahinter lautet ungefähr so: Einzelne Entwickler sollen nicht für jeden Kubernetes-Cluster, den sie starten wollen, um Ressourcen oder eine manuelle Freigabe beim Manager bitten müssen, weil das einen enormen administrativen Overhead produzieren würde. Jedoch sollen die Administratoren auch nicht auf sämtlichen Cloud-Accounts einer Firma tun und lassen können, wonach ihnen gerade der Sinn steht. Eine Amazon-AWS-Instanz zieht in der entsprechenden Konfiguration gern 1000 Euro und mehr pro Monat aus der Geldbörse. Läuft das Pulumi-Projekt eines Admins Amok und startet unbemerkt solche VMs, droht am Monatsende ein böses Erwachen in Form einer fetten Rechnung.

Auf der Pulumi-Ebene gibt es deshalb die Option, ein Regelwerk abzubilden, das für unterschiedliche Entwickler unterschiedliche Berechtigungen vorsieht. Das klappt allerdings nur mit der Enterprise-Variante, für die man Geld auf den Tisch legt. Tut ein Unternehmen das, ergibt sich jedoch eine Vielzahl an Möglichkeiten. Admins haben dann die Option, Policy Packs zu definieren (Abbildung 5). Diese enthalten ein Regelwerk oder mehrere, in Relation stehende Regelwerke, die unterschiedlichen Nutzern unterschiedliche Berechtigungen zuweisen.

Abbildung 5: Auch Policy-Regeln lassen sich in Pulumi in Python-Notation anlegen. Das setzt jedoch die Enterprise-Version der Lösung voraus, die es nur gegen Geld gibt.

In Policy Packs lassen sich auf der API-Ebene der einzelnen Cloud-Anbieter bis zum einzelnen API-Aufruf fein abgestufte Berechtigungen vergeben, sogar unter Einbeziehung der jeweiligen Parameter. Soll ein Administrator etwa nur Instanzen eines bestimmten Flavors auf AWS starten dürfen, bietet das Policy Pack dafür einen Schalter. Policy Packs liefern auf Wunsch auch Einschränkungen im Hinblick darauf, wo Admins bestimmte Workloads starten dürfen. Wer beispielsweise einen eher unwichtigen Workload zwar auf AWS fahren möchte, aber nur auf billigen Instanzen, verbietet für den Workload besser Amazons Edel-Rechenzentrum in Frankfurt.

Zusätzlich zu harten Verboten bieten Policy Packs auch Warnungen an. Nutzt der Admin also bestimmte Dienste in einer Public Cloud, kann Pulumi einen Hinweis für den jeweiligen Einzelfall anzeigen, der vor Gefahren finanzieller oder technischer Art warnt. Praktisch: Auch die Policies nutzen bekannte Programmiersprachen, sind also wie alle anderen Programme in Pulumi implementiert. Der Nachteil: Auch hier muss der Admin sich die entsprechenden Beschreibungen und Schlüsselwörter für die einzelnen Skriptsprachen aus der Dokumentation pulen und üben, bevor er Policy Packs sinnvoll erstellen und nutzen kann.

Unterschiede zu Terraform

Eine spannende Frage im Pulumi-Kontext ist, wie das Werkzeug sich gegen seinen direkten Konkurrenten (und Platzhirsch) Terraform schlägt, oder eher, wo die Gemeinsamkeiten und Unterschiede liegen.

Zum einen muss der Admin in Terraform eine deklarative Skriptsprache (HashiCorp HCL DSL) erlernen, zum anderen stehen ihm hier bestimmte Konstrukte wie Schleifen, Funktionen oder Klassen nicht zur Verfügung. Auch ein Pendant zum Pulumi-Service sucht man in Terraform vergeblich. Statt mit einem zentralen Dienst zu kommunizieren, legt Terraform lokale State-Dateien an, deren Management es dem Administrator überlässt.

Hinzu kommt, dass Pulumi verschiedene Automatismen bietet, die in Terraform zur Gänze fehlen. Wer etwa die Monitoring-Alarming-Trending-Lösung Prometheus nutzt, der bekommt eine basale Pulumi-Integration gleich dazu. Das Werkzeug integriert gestartete Stacks auf Wunsch in die Lösung.

Pulumi kommerziell

Wer Pulumi nicht als Einzelkämpfer nutzen will, sondern im Kontext eines Teams, der braucht eine Pulumi-Team-Lizenz. Die Starter-Lizenz ermöglicht drei Anwender und schlägt mit moderaten 50 US-Dollar zu Buche. Mit ihr lassen sich 20 Stacks starten. Die Pro-Version bietet für 75 US-Dollar Zugriff für bis zu 25 Mitglieder, Teams und Rollen, unlimitierte Stacks sowie Support während der Geschäftszeiten.

Greift man zum Enterprise-Paket, ist der Preis Verhandlungssache. Das Paket enthält dann 24×7-Support, Policies-as-Code sowie eine unlimitierte Anzahl von Mitgliedern in Teams. Zusätzlich lässt sich, wie erwähnt, der Pulumi-Service lokal betreiben, falls man ihm nicht in der Cloud stehen haben möchte. Eine ausführliche Liste der Funktionen, die mit jedem Level verbunden sind, liefert der Hersteller auf seiner Website [3].

Fazit

Die Idee hinter Pulumi gefällt. Wer schon einmal mit Terraform gearbeitet und sich durch dessen komplexe Syntax gewühlt hat, der dürfte sich manches Mal gewünscht haben, auf vorhandenes Wissen zurückgreifen zu können. Pulumi bietet diese Möglichkeit, auch wenn nicht der gesamte Lernaufwand wegfällt. Der Autor eines Projekts muss sich noch immer darauf einstellen, wie einzelne Klassen oder Funktionen in Pulumi aufzurufen sind.

Weniger erfreulich erscheint die relativ harte Bindung an den Pulumi-Service. Zwar lässt sich das Tool theoretisch auch ohne diesen Dienst verwenden, der praktische Nutzen eines solchen Setups bleibt dann allerdings recht übersichtlich. Im kommerziellen Einsatz bedeutet das aber auch, dass man für Pulumi bezahlt, weil es sich zwar um Open-Source-Software handelt, diese jedoch nur für den persönlichen Einsatz kostenlos ist.

Immerhin: Die Preise für Pulumi halten sich in Grenzen. Und weil die Einzelplatzlizenz nichts kostet, lässt sich die Lösung auf Herz und Nieren testen, bevor der Admin beim Hersteller Geld einwirft. Befindet man sich auf der Suche nach einem Werkzeug für Multi-Cloud-Orchestration, ist das Tool allemal einen Blick wert. (jcb/jlu)