Kestra S.A.S.

Broadcom bündelt Aria Automation in VMware Cloud Foundation, Red Hat baut AWX um und verlangt von Ansible-Automation-Platform-Kunden neue Topologien. Für Infrastrukturteams in Banken ist das weniger ein Toolwechsel als die Frage, wer künftig die Kette zwischen den Werkzeugen besitzt.

Der Auslöser ist selten die Architektur

Programme zur Modernisierung der Infrastrukturautomatisierung beginnen in Banken fast nie mit einem Architektur-Review. Sie beginnen mit einem Termin im Kalender. VMware Aria Automation, früher vRealize Automation, ist nicht mehr als eigenständiges Produkt erhältlich, die Funktionalität steckt in VMware Cloud Foundation 9, und die SaaS-Variante hat Broadcom bereits im Februar 2024 eingestellt. Wer den Orchestrator ohne den vollen VCF-Stack nutzt, steht beim Renewal vor einer Bündelungsentscheidung. Gartner-Analysten berichten gegenüber der Presse von Renewal-Angeboten, die 200 bis 500 Prozent über dem bisherigen Preis liegen.

Auf der Ansible-Seite ist die Lage subtiler, aber nicht weniger verbindlich. Red Hat baut das Upstream-Projekt AWX seit 2024 grundlegend um, semantische Versionsnummern und das Helm-Chart im Operator-Hub sind entfallen. Für Ansible Automation Platform endete im Juni 2026 der reguläre Support für Version 2.4, und mit Version 2.7 entfällt der RPM-Installer ebenso wie der direkte API-Zugriff auf Controller, Hub und Event-Driven Ansible. Jede Integration, die bisher einen Komponenten-Endpunkt angesprochen hat, muss über das Platform Gateway umgeschrieben werden.

Keiner dieser Punkte stellt Ansible oder Terraform in Frage. Unter Druck gerät die Schicht darüber, die Playbooks und Module zu einer Kette verbindet, Freigaben einholt und protokolliert, was gelaufen ist. Genau das ist Infrastruktur-Orchestrierung: die Koordination von Infrastrukturarbeit über mehrere Werkzeuge hinweg, mit Abhängigkeiten, Freigaben, Fehlerbehandlung und einem Ausführungsnachweis, während Infrastrukturautomatisierung manuelle Arbeit innerhalb eines einzelnen Werkzeugs beseitigt.

Was tatsächlich wandert

Die wichtigste Erkenntnis aus laufenden Migrationen ist, wie wenig sich bewegt. Terraform rekonziliert weiterhin den deklarierten Zustand, Ansible konfiguriert weiterhin tausende Hosts, Kubernetes-Operatoren halten ihre Workloads im Soll. Was wandert, ist die Koordination: das Scheduling, die Reihenfolge über Mandanten hinweg, die Approval-Gates vor einem Produktionsschritt und der Ausführungsnachweis am Ende.

Bei einer Ablösung von vRealize Orchestrator muss nur ein Teil wirklich konvertiert werden. Das ist die Skript-Logik in den vRO-Workflows selbst, meist JavaScript gegen die proprietären vRO-APIs.

Bestehende Python-, Shell- und PowerShell-Skripte laufen unverändert als Schritt in einem Workflow weiter. Die Ansible-Playbooks bleiben, wie sie sind, liegen aber künftig versioniert in Git und sind für jemanden lesbar, der nicht im ursprünglichen Team war.

Was ein Ersatz mitbringen muss

Ein Workflow-Engine allein ist als vRA-Ersatz nicht glaubwürdig, weil die Legacy-Produkte ein Ressourcenmodell mitbringen. Sie führen ein Inventar der verwalteten Ressourcen, sperren eine gemeinsam genutzte Ressource, während ein Workflow sie anfasst, und kennen einen Lebenszyklus pro Ressource. Ohne das schreiben irgendwann zwei Workflows gleichzeitig auf dieselbe virtuelle Maschine.

Eine Control Plane, die diese Koordinationsschicht übernimmt, braucht deshalb drei Dinge: ein Inventar unter den Kennungen, die das Unternehmen bereits verwendet, zeitlich begrenzte Sperren, die bei einem fehlgeschlagenen Workflow von selbst ablaufen, und eine klare Grenze zur CMDB. Wo ServiceNow das System of Record bleibt, registriert der Orchestrator die Ressource, sperrt sie während Terraform und Ansible arbeiten, und schreibt den Eintrag als letzten Schritt zurück. Das Ticket bleibt, wo es ist.

Patch-Management in der Private Cloud einer europäischen Bank

Wie das in einer regulierten Umgebung aussieht, zeigt eine europäische Bank, die Patch-Management und Infrastrukturbetrieb auf einer selbst betriebenen Private Cloud unter strikter Netzsegmentierung fährt. Die Orchestrierungsschicht ist hier Kestra. Die Plattform ist Open Source unter Apache-2.0-Lizenz, mit einem Enterprise-Angebot dahinter. Die Playbooks laufen weiter unter Ansible.

Die Control Plane läuft hochverfügbar in einer eigenen Zone, erreichbar über einen Proxy im Büronetz mit Single Sign-on und rollenbasiertem Zugriff. Flow-Definitionen liegen in Git, Secrets kommen zur Laufzeit aus Vault, Artefakte landen im Objektspeicher. Entscheidend ist, dass die Playbooks außerhalb der Control Plane laufen. Sie triggert einen dedizierten Ausführungshost im Admin-Netz. Dort läuft ein Worker mit vorinstallierter Ansible-Laufzeit, der die Host-Credentials hält und die Mandantennetze per SSH erreicht. Die Control Plane selbst besitzt zu keinem Zeitpunkt Zugangsdaten zu den Servern, die sie patcht.

Daraus folgen zwei Eigenschaften, die ein Sicherheitsteam schätzt: Der Blast Radius des Orchestrators lässt sich sauber eingrenzen, und die Ansible-Investition bleibt unangetastet. Jedes Playbook, das gestern von der Kommandozeile lief, läuft heute aus einem Workflow, versioniert, mit Freigabe und mit einem Audit-Record, den es vorher nicht gab.

Migration in Wellen und der Audit-Nachweis als Abnahmekriterium

Die Ablösung läuft gestaffelt, Kette für Kette, mit dem Ziel, die Lizenz des Altprodukts zum Renewal zu beenden. Ein guter erster Kandidat kreuzt mindestens drei Werkzeuge, hängt an einer Compliance- oder SLA-Frist und wird heute von Hand rekonstruiert. Eine Patch-Welle mit Freigabe und Verifikation erfüllt alle drei Kriterien.

Dass der Nachweis das eigentliche Ergebnis ist, hat in Banken einen regulatorischen Grund. NIS2 und DORA fragen nicht mehr, ob gepatcht wurde, sondern verlangen den Beleg: welche Systeme, in welchem Fenster, von wem freigegeben, wie verifiziert. Eine Kette über fünf Werkzeuge liefert Evidenz in fünf Formaten, und die Korrelation ist ein Mensch mit einer Tabelle. Eine Kette, die als ein Workflow läuft, liefert einen Datensatz, der sich per Syslog an das SIEM weiterreichen lässt. Wer den Orchestrator wechselt, sollte diesen Datensatz zum Abnahmekriterium der Migration machen.

Der Beitrag basiert auf dem Whitepaper "Infrastructure Automation Is Not Infrastructure Orchestration", das Kestra kostenlos zum Download anbietet (https://kestra.io/resources/whitepapers/infrastructure-orchestration).

Über den Autor

Kai Waehner ist Global Field CTO bei Kestra. Er verfügt über mehr als 20 Jahre Erfahrung in Enterprise-Architektur, Datenintegration und KI. Er arbeitet mit Fortune-500- und Global-2000-Unternehmen in Europa, Nordamerika, dem Nahen Osten, Asien und Australien. Er ist internationaler Speaker, Blogger (kai-waehner.de) und Buchautor.