© Olga Yastremska / 123RF.com

Wenig Lernaufwand, volle Funktion – das verspricht Spacelift. Mit dem Infrastructure-as-Code-Werkzeug sollen Admins komplette Setups in kürzester Zeit in der Cloud ausrollen und immun gegen Ausfälle und Probleme machen können.

Die Begriffe Continuous Development und Continuous Integration (CI/CD) begegnen Administratoren häufig zuerst im Kontext von Container-basierten Setups mit Kubernetes. Mit im Boot sitzt dann oft auch das Prinzip der Infrastructure as Code (IaC). Dahinter verbirgt sich genau das, was der Name suggeriert: Die Idee, ein gesamtes Setup in einem standardisierten Format zu beschreiben. Eine spezielle Software liest diese Beschreibung im Anschluss aus und übersetzt sie in tatsächlich laufende Ressourcen, etwa virtuelle Instanzen oder stimmig konfigurierte Container.

Auf dem Markt tummeln sich mittlerweile zahlreiche entsprechende Werkzeuge, die sich zwar zum Teil kombinieren lassen, aber andererseits in vielerlei Hinsicht auch in Konkurrenz zueinander stehen. Spacelift [1] will dem Administrator hier unter die Arme greifen. Es bietet laut eigener Aussage nicht weniger als eine perfekte Integration verschiedener Tools, den benötigten Kleber in Form standardisierter APIs und das Deployment erster produktiver Ressourcen innerhalb von Minuten. Anders als bei anderen Werkzeugen soll der Administrator hier also nicht erst wochenlang Bücher und Anleitungen lesen müssen, um auch nur testen zu können.

Zu den unterstützten Werkzeugen zählen Klassiker wie Pulumi und Terraform sowie dessen Fork OpenTofu. An die Anbindung an die Cloud haben die Entwickler ebenfalls gedacht, sie ist praktisch das bevorzugte Deployment-Ziel der Software. Seine Beschreibungen kann Spacelift unter anderem aus Git, Azure DevOps oder Bitbucket auslesen. Zudem ergänzen allerlei große und kleine Helfer das Konstrukt, die es beispielsweise erlauben, bestimmte Sicherheitsregeln zu erzwingen oder ausgefuchstes Monitoring und die Überwachung ausgerollter Ressourcen zu bewerkstelligen. Das klingt wunderbar, aber klappt es in der Realität auch so? Wie aufwendig ist der Einstieg in Spacelift tatsächlich, und wie gut funktioniert der angekündigte Umfang an Integrationen?

Nur für Hyperscaler

Um Spacelift auf den Zahn zu fühlen, empfiehlt sich zunächst eine Beschreibung dessen, was Spacelift sein will und welche Feature Sets es gar nicht erst beherrschen möchte.

Wirft man einen Blick auf die Webseite des Werkzeugs, stellt sich zunächst der Eindruck ein, es könne auch in On-Premises-Installationen und mit echtem Blech zum Einsatz kommen. Doch der Schein trügt: Zwar umfassen die gängigen Definitionen von IaC mittlerweile durchaus auch On-Premises-Hardware und Bare-Metal-Setups. Es existieren zudem die passenden Werkzeuge, um physische Installationen anhand definierter Parameter automatisiert zu installieren: Werkzeuge wie Canonicals MaaS oder Foreman übernehmen das Lifecycle-Management für physische Server. Damit will Spacelift erklärtermaßen aber nichts zu tun haben.

Native Integration bietet man nur für die großen Hyperscaler, also AWS, Azure und GCP. Wer seine Setups nicht auf einer dieser Plattformen ausrollen möchte, kann Spacelift damit vergessen. Zwar gibt es über die unterstützten Werkzeuge für Deployment wie Pulumi oder Ansible die Option, Deployments auf anderen Plattformen auszurollen, etwa OpenStack. Das ist in Spacelift dann aber kein echter First Class Citizen mehr, was in vielen Fällen administrativen Mehraufwand verursacht. Obendrein dürfte der Support seitens des Herstellers bei solchen Konstrukten spärlich ausfallen. Gerade aus europäischer Sicht ist das ungünstig, denn nützlich ist Spacelift durchaus, wie dieser Artikel noch zeigen wird. Aber längst nicht jedes Unternehmen in Europa darf oder will seine Daten bei den Hyperscalern ablegen, Stichwort: digitale Souveränität.

Wer hingegen keine Berührungsängste zu AWS, Azure oder GCP hat, darf Spacelift in die nähere Auswahl für die Managementwerkzeuge seiner virtuellen Umgebung einbeziehen. Dann spielt auch der Umstand keine Rolle, dass Spacelift im Regelfall ein gehosteter Dienst ist, der selbst in der Cloud läuft. Der Code und alle für Spacelift nötigen, entsprechend unternehmensspezifischen Konfigurationen landen also ebenfalls dort. Zwar bietet Spacelift für größere Setups die Möglichkeit, eine eigene Instanz des Diensts zu mieten. Auch die läuft dann allerdings in AWS und ist im Wesentlichen eine personalisierte Version des generischen Spacelift-Angebots, das alle anderen erhalten. Um die Hyperscaler kommt man bei Spacelift also kaum herum und um AWS gar nicht.

Begrifflichkeiten

Spricht nichts Grundsätzliches gegen Spacelift, steht im nächsten Schritt eine Beschäftigung mit den Begrifflichkeiten der Lösung an. Spezifische Begriffe gibt es eine ganze Menge, wobei der Systemverwalter nicht jeden davon kennen muss. Das würde auch dem Mantra des Anbieters widersprechen, wonach sich produktiv innerhalb weniger Minuten mit Spacelift arbeiten lässt. Ein paar der Termini aus dem CI/CD-Kontext sollten aber schon geläufig sein.

Dazu gehören Terraform und OpenTofu, zwei Deployment-Werkzeuge, die die CI/CD-Dienste der großen Anbieter wie AWS CloudFormation abstrahieren und über eine einheitliche eigene Deklarationssprache steuerbar machen. Terraform ist dabei zweifelsohne die bekanntere Lösung, und bei OpenTofu handelt es sich streng genommen auch um Terraform: Dieser Fork des Mutterprojekts erfolgte kurz nach einem Wechsel der Lizenz von Hashicorp. Auch Begriffe wie Open Policy Agent oder Git sollte man schon einmal gehört haben, was bei den meisten Admins der Fall sein dürfte.

Hat man zumindest ein bisschen Ahnung von CI/CD-typischen Begriffen, erschließt sich der Rest der von Spacelift genutzten Termini recht schnell. Zentral ist etwa der Begriff des Stacks, der wohl jedem Admin geläufig ist, der bereits etwas Erfahrung mit Container-Deployments auf Cloud-Umgebungen hat. Bei Spacelift bezeichnet ein Stack die Gesamtheit aller Ressourcen sowie Konfigurations- und Metadaten eines ausgerollten Setups.

Sinn und Zweck von Spacelift ist es ja gerade, komplette Umgebungen mitsamt der darin laufenden Software in kürzester Zeit bei einem der Hyperscaler auszurollen. Spacelift kennt dazu mehrere Bestandteile, die in Summe einen Stack ergeben. Der lässt sich anschließend aus Spacelift heraus als eigenständige Einheit verwalten und warten. Stacks kann man in Spacelift auf verschiedene Art und Weise anlegen. Die Entwickler empfehlen, den eingebauten Terraform-Provider zu verwenden, um zuvor in einem Git-Verzeichnis gesammelte Konfigurationseinstellungen in ein Setup bei einem der Hyperscaler umzuwandeln.

Die Spacelift-Entwickler weisen explizit darauf hin, dass diese Vorgehensweise den Admin darauf festlegt, die entsprechende Konfiguration und sämtlichen für die Ausführung nötigen Code in Terraform-Syntax zu notieren. Da Spacelift aber auch andere IaC-Werkzeuge wie Ansible unterstützt, lassen sich Stacks jedoch durchaus anderweitig anlegen, beispielsweise mit einem Blueprint, also einer Blaupause. Sie führt ebenso zu einem Stack wie der Weg über Spacelifts Terraform-Integration, enthält aber zusätzlich auch Anweisungen über die zu nutzende Integration für die unterstützten IaC-Komponenten.

Die umfassen neben Terraform und OpenTofu auch Ansible, Terragrunt, Kubernetes sowie Pulumi (Abbildung 1). Durchaus auffällig: Die Automationswerkzeuge der ersten Generation, Puppet und Chef, fehlen in der Liste. Dasselbe gilt für das mittlerweile ebenfalls recht verbreitete Salt. Wer also vorrangig auf diese Werkzeuge setzt, hat einige Migrationsarbeit vor sich, wenn er Spacelift nutzen möchte.

Abbildung 1: Neben einer eigenen Run-Engine für Terraflow unterstützt Spacelift diverse andere Werkzeuge für IaaS, darunter Ansible und Pulumi. Die bekannten Werkzeuge Puppet und Chef fehlen. Quelle: Spacelift

IaC und Versionsverwaltung

Als IaC-Lösung braucht Spacelift notwendigerweise eine vollständige Integration in handelsübliche CI/CD-Workflows. Hier macht die aktuelle Situation der Entwicklungswerkzeuge Spacelift die Sache aber leicht: Außer Git gibt es auf weiter Flur praktisch keine relevanten Lösungen mehr. Entsprechend lässt Spacelift sich sowohl mit Github als auch einer lokalen Gitlab-Instanz hervorragend integrieren (Abbildung 2). Bitbucket unterstützt der Dienst ebenfalls, doch dürfte sich das Interesse der globalen Nutzer für diesen Aspekt des Diensts in Grenzen halten.

Abbildung 2: Spacelift verspricht die All-inclusive-Erfahrung in Sachen IaC und bindet dafür zum Beispiel die VCS verschiedener Anbieter ein. Quelle: Isaac Johnson

Viel wichtiger erscheint aus Sicht des durchschnittlichen Anwenders, dass Spacelift CI/CD-Pipelines selbst implementieren und Bestandteil solcher Pipelines sein kann. Auch die interne Arbeitsweise von Spacelift liegt voll auf einer Linie mit den Prinzipien von CI/CD. Einen fertig ausgerollten Stack betrachtet Spacelift beispielsweise als CI/CD-Pipeline, die mehrere Durchläufe oder Aufrufe haben kann. Anhand dieser Tatsache lässt sich die Art und Weise hervorragend verdeutlichen, wie Spacelift unter der Haube funktioniert.

Im ersten Schritt und unmittelbar, nachdem er Zugriff auf Spacelift erhalten hat, legt der Administrator einen (noch leeren) Stack in Spacelift an. Dann verbindet er mit diesem Stack ein Git-Verzeichnis, in dem der gesamte benötigte Code für das Ausführen aller nötigen Ressourcen dieses Stacks liegt. Allerdings kann Spacelift selbst keine Ressourcendefinitionen für Kubernetes, Ansible oder Amazon CloudFormation erstellen. Die notwendigen Definitionen in Form von Quelltext muss der Administrator stattdessen in einem der unterstützten Konfigurationsformate anlegen.

Ist das erledigt, übernimmt Spacelift aber die Regie. Zunächst besorgt es sich die Konfigurationsdaten aus dem hinterlegten Git-Verzeichnis und liest sie aus. Dann nutzt es seine internen Funktionen, um zunächst vom Administrator hinterlegte Tests auszuführen, die sich auf die Zielplattform ebenso wie auf den vorgefundenen Quelltext beziehen können. Ähnlich verhält es sich bei der Arbeit mit einem Blueprint, bei dem neben Terraform auch die anderen IaC-Werkzeuge zum Einsatz kommen können.

Im Anschluss erstellt Spacelift den Stack und wertet dabei eine Liste der im Stack hinterlegten Aufgaben ab. Diese Tasks bestimmt der Administrator. Ist der Stack fertig konfiguriert, erstellt der Administrator einen sogenannten Run. Je nach Konfiguration kann es sich um einen Development Run oder einen Proposed Run handeln (Abbildung 3). Ersterer räumt seine Ressourcen auf Wunsch im Nachgang automatisch ab, was dabei hilft, teure Überraschungen durch beispielsweise in AWS hinterlassene Test-Setups zu vermeiden. Alle Formen des Runs lassen sich zudem wiederholen. Geht beim ersten Versuch etwas schief, ändert der Administrator zunächst die Konfiguration im Git. Dann startet er den Run neu. Spacelift holt sich automatisch die neueste Konfiguration und versucht es damit erneut.

Abbildung 3: Ein Run bezeichnet in Spacelift alle Arbeitsschritte, die vom nackten Quelltext aus nötig sind, um ein vollständiges Deployment zu erreichen. Dabei gibt es verschiedene Run-Arten für die Entwicklung und die Produktion. Quelle: Spacelift

Proposed Runs zielen auf das Deployment in der Produktion ab. Sie simulieren die Änderungen, die sie vornehmen würden, und zeigen an, ob der Run erfolgreich wäre oder nicht. Der Proposed Run erstellt wie der Development Run also die benötigten Komponenten, greift dafür aber nicht auf produktive Ressourcen zu. Er startet in einer frischen Umgebung auf der Zielplattform die konfigurierten Dienste und Ressourcen mithilfe des jeweiligen IaC-Werkzeugs.

Ganz wie bei CI/CD-Systemen üblich verfolgt Spacelift, ob das Anlegen aller gewünschten Ressourcen funktioniert. Falls nicht, weil etwa die Konfiguration noch nicht passt, ändert der Administrator die Konfiguration in Git und startet einen neuen Development oder Proposed Run. Funktioniert alles wie gewünscht, folgt das Ausrollen in Form eines Tracked Run, also einer überwachten Instanz, in der produktiven Umgebung des jeweiligen Stacks. Den kann Spacelift sowohl frisch starten als auch im laufenden Betrieb durch einen erneuten Tracked Run mit neuer Konfiguration aktualisieren. Dabei agiert Spacelift idempotent.

Liegen alle vom Verwalter konfigurierten Ressourcen auf der Zielplattform vor, ist Spacelift aber noch lange nicht fertig. Zum Funktionsumfang des Werkzeugs gehören allerlei Addons und Erweiterungen, um nicht nur das Deployment zu realisieren, sondern auch dessen implizite Sicherheit und Überwachung. Deswegen kann Spacelift zusätzlich zu dem vom Admin festgelegten Setup viele Komponenten aus der Open-Source-Welt mitausrollen, beispielsweise Prometheus. Die Konfiguration dafür denkt Spacelift sich auf Grundlage der bekannten Konfiguration weitgehend selbst aus. Für eine verteilte Anwendung in Kubernetes lässt sich so sehr schnell eine komplette Überwachung erreichen.

Daneben verfügt Spacelift selbst über eine GraphQL-Schnittstelle, sodass sich ein Export der Metrikdaten in eine bestehende Grafana-Installation in kürzester Zeit realisieren lässt.

Wichtige Zusatzfunktionen

Überhaupt lohnt es sich, auf die Zusatzfunktionen und Bequemlichkeitserweiterungen von Spacelift einen genauen Blick zu werfen. Es ist ja – und das wissen die Entwickler hinter Spacelift – nicht überbordend kompliziert, eine CI/CD-Lösung für Infrastructure as Code zu implementieren, die Anwendungen ausrollt und ihren Lebenszyklus überwacht. Die IT-Hipster setzen für eben diese Aufgabe ohnehin beinahe ausschließlich auf Kubernetes. Hier tummeln sich zahllose Lösungen am Markt. Dazu zählt unter anderem ArgoCD (Abbildung 4), das im Kern sehr ähnliche Ziele wie Spacelift verfolgt und unter der Haube sogar recht ähnlich funktioniert. Allerdings braucht man für ArgoCD ein laufendes Kubernetes. Das bekommt man bei den Hyperscalern aber ebenso flott wie eine souveräne Alternative am deutschen Markt. Auch mit ArgoCD lässt sich in relativ kurzer Zeit also ein existierendes Setup aus dem Boden stampfen.

Abbildung 4: Am Markt existierende Projekte wie ArgoCD versprechen ähnliche Features wie Spacelift, benötigen aber ein Deployment per Kubernetes. Spacelift kann auch “echte” IaaS bei den großen Hyperscalern ausrollen und bietet mehr Flexibilität. Quelle: Cinchy Project

Das Klimbim drumherum gehört bei Spacelift also integral zum Produkt, und die Spacelift-Entwickler tun eine ganze Menge, um sich mit diesen Zusatzfunktionen von der Konkurrenz abzuheben. Das beginnt schon beim Thema Compliance. Gerade größere Unternehmen mit mehreren Entwicklerteams brauchen verbindliche Vorgaben, um ihre internen Standards beim Ausrollen von Anwendungen in der Cloud zu erzwingen. Das umfasst neben der eigentlichen Systemkonfiguration auch Mechanismen, um sie zu überwachen. Damit beispielsweise Standards in Sachen Benutzerauthentifizierung greifen, muss der Administrator sie zunächst in seinem Stack oder Blueprint adäquat implementieren. Das bedeutet aber nicht automatisch, dass sie auch funktionieren. Hier kommen gleich mehrere Features zum Zuge, die Spacelift in Sachen Security und Compliance bereitstellt.

Vorrangig geht es der Lösung um die Compliance innerhalb des eigenen Verantwortungsbereichs. Spacelift offeriert dazu eine API, auf die der Administrator wahlweise mittels der feilgebotenen GUI oder eines Kommandozeilen-Clients zugreift. Letzteren gibt es für Linux und MacOS. In vielen Unternehmen gilt es heute als Voraussetzung, Aktionen des eigenen Personals aufzuzeichnen. So lassen sich Veränderungen im Nachhinein nachvollziehen und eventuelle Fehler in der Konfiguration sowie im Arbeitsablauf erkennen und bereinigen.

Die Kopplung an bestehende Benutzerverzeichnisse stellt für Spacelift dabei kein Problem dar. SAML und OAuth stehen als Authentifizierungsmechanismen zur Verfügung und bieten mithin Anschluss an die IAM-Dienste der großen Anbieter, an ein selbst betriebenes Keycloak mit LDAP im Hintergrund oder ein lokales Active Directory. Die eigentliche Aufzeichnungsfunktion für Audit Trails bietet Spacelift aber ebenso. Je nach Konfiguration schneidet der Dienst dann alles mit, was einzelne Benutzer tun, inklusive des kompletten Payloads eines API-Aufrufs. Damit in Spacelift selbst nicht der verfügbare Platz ausgeht, kann das Werkzeug Audit-Protokolldateien zudem über verschiedene Standardprotokolle wie S3 beispielsweise in AWS ablegen. Auch den Upload überwacht Spacelift. Das schließt aus, dass wegen einer unbemerkt gebliebenen Fehlkonfiguration Audit-Logs im Ausguss verschwinden.

Damit die Grenze zwischen Plattform und Workload keine unüberwindbare Hürde für Spacelift bleibt, kann der Dienst obendrein den Open Policy Agent (OPA) als Teil eines Deployments automatisch ausrollen. OPA ist ein Standard für das Festlegen von Konfigurationsparametern auf Systemen, eine Art Framework, das mehr oder minder generische Regeln erlaubt (Abbildung 5). Sind diese Bestandteil der Konfiguration eines Stacks, erzwingt Spacelift sie auf Wunsch des Administrators komplett automatisch.

Abbildung 5: Policies sind eine Besonderheit in Spacelift: Darüber lassen sich Compliance- und Security-Regeln auch innerhalb ausgerollter Spacelift-Stacks erzwingen. Der CISO hört das vermutlich gern. Quelle: Spacelift

Kommunikation und Überwachung

Darüber hinaus gibt Spacelift sich ausgesprochen kommunikationsfreudig. Um den modernen Anforderungen des ChatOps gerecht zu werden, bietet das Werkzeug native Schnittstellen zu Microsoft Teams und Slack. So lässt sich etwa konfigurieren, dass bestimmte Aktionen in Spacelift zu automatischen Meldungen in vorher konfigurierte Teams- oder Slack-Kanäle führen.

Zudem ermöglicht Spacelift ein weitgehendes Fernsteuern externer Dienste. An externe Git-Verzeichnisse kann es bei bestimmten Ereignissen über Webhook Kommandos schicken. Daneben exponiert Spacelift eine Schnittstelle, um selbst Webhooks auszuführen. So lässt sich sicherstellen, dass ein Commit im entfernten Git-Verzeichnis automatisch zur Anpassung des Stacks in Spacelift führt, etwaige Sicherheitsvorkehrungen inbegriffen. Der Administrator kann an dieser Stelle ganze Abfolgen von Befehlen bauen: Ein Git-Commit führt dann zunächst dazu, dass ein Proposed Run stattfindet. Der wiederum löst, sofern er ohne Fehler funktioniert, ein Update des Tracked Runs aus.

In Kombination miteinander sind diese Features tatsächlich deutlich mächtiger als das, was etwa ArgoCD zustande bringt. Das gilt umso mehr, da Spacelift auch bei der internen Kommunikation seiner einzelnen Dienste wenig Kontaktängste hat. Stacks lassen sich zum Beispiel mittlerweile über eine Abhängigkeit in Relation zueinander setzen. Dann passiert in einem Stack nur etwas, wenn in einem anderen Stack zuvor eine andere Aufgabe erfolgreich abgewickelt wurde. Dabei muss dem ausführenden Administrator allerdings klar sein, dass solche Konstrukte die Komplexität innerhalb von Spacelift bedeutend erhöhen.

Fehlern durch Komplexität möchte Spacelift begegnen, indem es etliche Überwachungsmöglichkeiten bietet. Datadog und Prometheus gehören dabei zum Standardrepertoire, inklusive der jeweiligen Metriksammler, deren Konfiguration der Administrator aber zumindest in der Konfiguration von Stacks oder in Blueprints festlegen muss. Logisch: Wenn eine Anwendung eine native Schnittstelle zu Datadog hat, gilt es, sie in der Konfiguration auch zu aktivieren.

Die Werkzeuge sieht Spacelift übrigens nicht auf Augenhöhe: Prometheus soll vorrangig dem Monitoring von Spacelift selbst dienen, während Datadog auch Dienste überwachen kann, die in Stacks innerhalb von Spacelift laufen.

Preise

Abschließend sollte das Thema Geld nicht zu kurz kommen, denn selbstverständlich offeriert Spacelift sein Werkzeug nicht aus reiner Nächstenliebe. Immerhin können kleine Teams, die viele der beschriebenen Features nicht benötigen und auch nicht allzu viele Workloads brauchen, zur Free-Option des Tools greifen. Sie kostet nichts, erlaubt jedoch nur zwei Benutzer und lediglich ein Projekt. Die meisten Features sind hier aber bereits integriert. Wer die beschriebenen Abhängigkeiten von Stacks oder eine tiefere Integration mit Cloud- und Authentifizierungsdiensten benötigt, greift zur Cloud-Option, die mit 250 US-Dollar monatlich zu Buche schlägt. Das schließt fünf Benutzer ein, jeder zusätzliche kostet 10 US-Dollar. Dafür gibt es hier auch Mandantenfähigkeit.

Das Enterprise-Paket umfasst das beschriebene Audit-Trail-Feature sowie SSO mit SAML oder OIDC und unterstützt private Git-Verzeichnisse. Ein Preis lässt sich an dieser Stelle aber nicht angeben: Wer das Enterprise-Produkt inklusive kommerziellem Support bucht, muss zuvor mit Spacelift telefonieren, was ausgesprochen nervig ist. Man kann aber davon ausgehen, dass für die Enterprise-Variante noch einmal ein deutlicher Aufpreis gegenüber der Cloud-Option anfällt.

Zwei Dinge erscheinen dabei äußerst ärgerlich: Viele der der teuren Enterprise-Variante vorbehaltene Funktionen benötigen wohl die meisten Unternehmen, und günstig ist Spacelift ohnehin eher nicht. Der Hersteller kontert damit, dass seine Lösung in Sachen CI/CD und IaC in einem Durchschnittsunternehmen etliche Vollzeitgegenwerte (Full Time Equivalent, FTE) einer Arbeitskraft über Jahre einspare. Das müsse man beim Preis berücksichtigen. Mal eben schnell dürfte man Spacelift aber in den meisten Unternehmen nicht durch den Einkauf bekommen, dafür liegen die Preise zu hoch.

Fazit

In Summe präsentiert sich Spacelift als Deployment-Werkzeug auf der Höhe der Zeit. Neben den regelmäßig nötigen Funktionen enthält es auch spezielle Features wie den Audit Trail und den Support für automatisiertes Monitoring.

Dass Spacelift dabei nicht nur auf Kubernetes gemünzte Standardfunktionen anbietet, sondern andere IaC-Werkzeuge wie Ansible oder Pulumi unterstützt, ist erfrischend und heute gar nicht mehr so oft zu finden. Das macht Spacelift zu einer validen Alternative zu Werkzeugen wie Foreman und Jenkins, von selbst geschriebenen Tools ganz zu schweigen. Verglichen mit solchen Konstrukten kommt man bei Spacelift in der Tat sehr flott zu vorzeigbaren Ergebnissen, sofern man die Anwendungsseite fertig hat. Die benötigt man für Spacelift ebenso wie für andere Werkzeuge.

Negativ fällt auf, dass sich Spacelift ohne außereuropäische Cloud-Dienste faktisch nicht nutzen lässt. Wer also auf digitale Souveränität Wert legt, schaut in die Röhre. Stellt das kein Problem dar, ist Spacelift aber durchaus einen genaueren Blick wert. (jcb/jlu)