Kestra S.A.S.

Klassische Scheduler wie Control-M haben den Industriebetrieb über Jahrzehnte verlässlich getaktet. Jetzt treffen sie auf Sensordaten, OT-Zonen und KI-Cluster, die wöchentlich dazukommen. Für IT-Betriebsleiter geht es weniger um ein neues Werkzeug als um die Schicht, die alle Werkzeuge koordiniert.

Der Scheduler hat seinen Job gemacht

In Fertigungsunternehmen laufen die Nachtläufe seit Jahrzehnten unter einem Enterprise-Scheduler. Control-M, Automic oder Stonebranch starten Batch-Jobs zu festen Zeiten, mit Abhängigkeiten und SLA-Überwachung, und sie tun das zuverlässig. Daneben ist eine zweite Welt entstanden: Terraform provisioniert, Ansible konfiguriert, Argo CD liefert auf Kubernetes aus, eine Patch-Plattform patcht, und Sensordaten aus der Produktion erwarten eine Reaktion innerhalb von Sekunden.

Jedes dieser Werkzeuge erledigt seine Aufgabe innerhalb seiner Grenze gut. Das Problem ist die Kette darüber: Ein Scheduler, der für Zeitfenster gebaut wurde, sequenziert event-getriebene Betriebsabläufe nur mit Umwegen, und die Lücke füllen Skripte, Cron-Einträge und CI-Jobs, die nie für Betriebsaufgaben gedacht waren. Jedes Tool meldet Erfolg, die Kette hat keinen Eigentümer.

Jeder neue Knoten bewegt einen Zähler

Dazu kommt ein finanzieller Effekt, der ohne jede Entscheidung des Betriebsteams eintritt. Ansible Core, OpenTofu, Argo CD und Kubernetes haben keinen Ausführungszähler. Die Kosten sitzen in den kommerziellen Produkten drumherum, und die rechnen nach der Größe der Infrastruktur ab: pro Managed Node bei Ansible Automation Platform, pro Ressource bei HCP Terraform, pro Core bei VMware Cloud Foundation, pro Endpoint bei Patch- und Backup-Plattformen, bei vielen Schedulern pro Job.

Jeder dieser Zähler bewegt sich in dieselbe Richtung wie ein KI-Ausbau. Jeder neue Cluster für Qualitätsprüfung oder Predictive Maintenance bringt Knoten mit, und jeder Knoten erhöht eine Rechnung, die niemand bestellt hat. Gartner prognostiziert für 2026 weltweite IT-Ausgaben von 6,37 Billionen Dollar, ein Plus von 14,2 Prozent, getrieben von KI-Infrastruktur, und rät CIOs, redundante Werkzeuge abzubauen und Verträge neu zu verhandeln.

Die Ausführungswerkzeuge bleiben. Die Konsequenz hat zwei Teile. Neue Arbeit läuft über eine Orchestrierungsschicht, die pro Instanz lizenziert ist, damit die nach Knoten abgerechneten Werkzeuge aufhören zu wachsen. Und die Skripte, Cron-Einträge und Altprodukte, die nur existieren, um andere Werkzeuge zu verbinden, werden abgebaut.

Getrennte IT- und OT-Zonen als Architekturfrage

In der Industrie kommt eine Anforderung hinzu, die reine IT-Umgebungen nicht kennen. Produktionsnetze sind von der Unternehmens-IT getrennt, oft mit eigener Verzeichnisdomäne, und dürfen nicht direkt kommunizieren. Ein zentraler Server, der eingehende Verbindungen zu Agents auf jedem Zielhost braucht, bildet das nur mit Firewall-Ausnahmen ab.

Sauberer ist ein Muster, bei dem Worker innerhalb jeder Zone sitzen und ausschließlich ausgehend zur Control Plane verbinden. Die Control Plane braucht dann keinen eingehenden Pfad in die Zonen, die sie orchestriert, und die Zonen bleiben untereinander isoliert. Wo die Policy verbietet, dass eine Control Plane IT und OT überspannt, läuft eine pro Zone, und das Worker-Muster bleibt in jeder dasselbe.

Aria-Automation-Ablösung über vier OT-Zonen in der Schwerindustrie

Ein Fortune-500-Industriekonzern betrieb seine kritischen Hybrid-Cloud-Automatisierungen auf VMware Aria Automation. Der Orchestrator war teuer, schwer zu entwickeln und zu riskant, um ihn über mehrere OT-Domänen zu spannen. Das Unternehmen hat diese Schicht durch Kestra ersetzt. Die Plattform ist Open Source unter Apache-2.0-Lizenz, mit einem Enterprise-Angebot dahinter. Im Einsatz sind vier isolierte Plattformen für OT und eine für IT. Ansible blieb und wird jetzt orchestriert. Die Lizenzkosten sanken gegenüber Aria Automation um 90 Prozent, die Bereitstellung einer Umgebung von sechs Monaten auf sechs Tage. Inzwischen prüft dasselbe Team, ob die kommerzielle Plattform um die Playbooks herum ihre Lizenz noch verdient.

Die Shortlist zweimal evaluieren

Wer eine Shortlist aufstellt, sollte die Evaluierung zweimal durchführen. Der erste Durchgang sind die Betriebsketten dieses Quartals: Patch-Wellen, Server-Commissioning, Incident-Remediation. Der zweite Durchgang prüft, was die Plattform in zwei oder drei Jahren zusätzlich tragen muss. Datenpipelines aus der Produktion, Anwendungs-Deployments, Geschäftsprozesse und KI-Agenten kommen nacheinander dazu. Ein Werkzeug, das für eine einzige Domäne gebaut wurde, endet genau dort.

Fünf Eigenschaften lassen sich in einem Proof of Concept prüfen.

• Domänenneutralität: eine Datenpipeline auf derselben Instanz laufen lassen.

• Deployment-Flexibilität: einen Worker in die am stärksten abgeschottete Zone stellen.

• Eine Definition in Git: einen Flow per Pull Request ändern und prüfen, dass genau das läuft, was gemerged wurde.

• Lizenz pro Instanz: die Plattform beim Zehnfachen des PoC-Volumens kalkulieren.

• Reichweite über die gesamte Kette: jedes System per nativem Plugin anbinden.

Dieselbe Governance für KI-Agenten im Infrastrukturbetrieb

Der zweite Durchgang entscheidet, weil KI-Agenten den Infrastrukturbetrieb erreichen. Gartner erwartet, dass bis 2029 mindestens 70 Prozent der Unternehmen mit produktiver agentischer KI in I&O einen materiellen Service-, Sicherheits- oder Kostenvorfall erleben, der auf unzureichende Runtime Controls zurückgeht. Agent-Sprawl ist Skript-Sprawl mit mehr Tempo und weniger Sichtbarkeit.

Wer seine deterministischen Ketten heute über eine Control Plane mit Freigaben, eng begrenzten Zugangsdaten und Audit-Record führt, hat diese Schicht bereit, wenn Agenten Änderungen auslösen. Der Agent ruft dann einen Workflow als benanntes, typisiertes Tool auf, etwa über das Model Context Protocol, und der Workflow behält seine Approval-Gates. Ein Unternehmen ohne diese Schicht wird gebeten, einem Agenten direkten Zugriff auf zehn Werkzeuge zu geben. Für ein Werk mit laufender Produktion ist klar, welche der beiden Ausgangslagen tragfähig ist.

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