Kestra S.A.S.

Orchestrierung ist das Bindegewebe des modernen Unternehmens, und derzeit gehört sie niemandem. Genau diese Lücke will ich bei Kestra schließen helfen.

Der Markt steht an demselben Wendepunkt wie Apache Kafka, als ich 2017 zu Confluent kam. Die Technologie ist ausgereift und läuft bereits produktiv bei Apple, JPMorgan, Toyota und Xiaomi. Am Markt ist das Thema noch kaum besetzt. Und es gibt ein Zeitfenster von zwei bis drei Jahren, in dem sich entscheidet, wer diese Kategorie prägt.

Das Orchestrierungsproblem in jedem Unternehmen

Jedes große Unternehmen betreibt vier Arten von Orchestrierungstools, die nicht miteinander sprechen. Klassische IT-Scheduler wie Control-M, ActiveBatch und cron führen datumsgesteuerte Batch-Jobs aus, ohne Events wahrzunehmen. Datenpipeline-Tools wie Airflow, Prefect und Dagster bewegen Daten, bleiben aber auf Python-DAGs beschränkt. Plattformen für Geschäftsprozesse wie Camunda, Appian, Pega und UiPath steuern Freigaben und menschliche Schritte, enden aber an der Prozessgrenze. Tools zur Infrastrukturautomatisierung wie vRA, ServiceNow und Terraform stellen Ressourcen bereit, bleiben aber in ITSM-Lebenszyklen gefangen.

Jedes Tool deckt einen Ausschnitt ab, den Überblick hat keines.

Teuer wird es an den Grenzen zwischen den Tools: dort, wo eine Pipeline fertig wird und der nachgelagerte Job nie startet, oder wo ein Prozess auf eine Freigabe wartet, die in einem Postfach liegt. Solange jedes Tool in seiner Spur blieb, ließ sich das beherrschen. Zwei Kräfte ändern das gerade: Unternehmen modernisieren diese Tools aktiv, und Agentic AI zwingt sie, als Einheit zu funktionieren.

Warum jetzt: erst Modernisierung, dann Agentic AI

Die erste Kraft ist die Modernisierung, und hier setzen die meisten Unternehmen tatsächlich an. Sie lösen fragile, teure Legacy-Scheduler ab. Sie konsolidieren den Wildwuchs an Datenpipelines über Teams hinweg. Sie ersetzen starre BPM-Suiten, die an der Prozessgrenze enden. Jedes dieser Vorhaben ist für sich ein Projekt mit eigenem Budget. Und wer eine Kategorie modernisiert, stellt fast zwangsläufig die nächste Frage: Warum vier Engines betreiben, wenn eine deklarative Plattform alle vier abdeckt?

Die zweite Kraft ist Agentic AI, und sie beseitigt den letzten Grund, die Tools getrennt zu halten. KI-Workflows bleiben nicht in einem einzigen Tool. Eine Ausführung kann eine Datenpipeline berühren, einen Prozessschritt auslösen, ein Modell aufrufen und Infrastruktur bereitstellen. Scheitert sie, dann oft unbemerkt in der Lücke zwischen den Tools. Ein Agent ohne gesteuerten Workflow meldet keinen Fehler, er arbeitet einfach falsch weiter.

Der CTO sieht ein Governance-Risiko. Der CIO sieht eine Infrastruktur, die nicht mithalten kann. Der CDO sieht veraltete Daten. Der COO sieht einen Prozess, der ohne erkennbaren Grund hängt. Die Symptome sind verschieden, die Ursache ist dieselbe: Keine einzelne Ebene steuert den gesamten Mix an Workloads.

Kestra holt alle vier Kategorien auf eine deklarative Plattform unter ein Governance-Modell. Statt eines Flickenteppichs aus unverbundenen Tools orchestriert eine Engine über alle Domänen, auf die ein Unternehmen angewiesen ist. Deterministische Workflows und autonome Agenten laufen nebeneinander, unter einer Control Plane.

Open Source, überall einsetzbar: Cloud, On-Premises, Edge

Kestra steht unter der Apache-2.0-Lizenz, derselben permissiven Lizenz wie Apache Kafka. Entwickler und Data Engineers können in wenigen Minuten starten und Workflows in YAML, über APIs oder im No-Code-Editor bauen. Dazu kommt ein Ökosystem von mehr als 2.000 Plugins, und Tasks laufen in jeder Sprache: Python, Node.js, R, Go, Shell und mehr. Workflows lassen sich sogar per MCP von einem LLM erzeugen: Man beschreibt die Orchestrierung in natürlicher Sprache, und das Modell baut den Flow. Die Plattform ist von Grund auf sprachunabhängig und event-driven.

Für den Produktivbetrieb gibt es eine Enterprise Edition und eine vollständig gemanagte Cloud. Governance, Skalierung und SLAs, die regulierte Organisationen brauchen, sind dort eingebaut und nicht nachträglich angeflanscht. Das schließt air-gapped Deployments ein, für Organisationen, die kein einziges Byte aus ihrem Perimeter lassen dürfen.

Gerade für die Orchestrierung ist Open Source mehr als ein Lizenzmodell. Sie ist die einzige Schicht, der alle Teams zugleich vertrauen müssen, und in ihr sammelt sich geschäftskritische Logik schneller an als irgendwo sonst. Die Engine, die in Produktion läuft, kann jeder prüfen und unabhängig betreiben. Self-Hosting, On-Premises- und air-gapped Betrieb sind damit Eigenschaften der Software und keine Zugeständnisse in einem Vertrag.

In Produktion bei Apple, JPMorgan, Toyota, Xiaomi und vielen weiteren Unternehmen

Kestra läuft längst nicht mehr nur bei Early Adopters produktiv. Das Machine-Learning-Team von Apple orchestriert damit großskalige Datenpipelines.

Die Referenzen reichen über Branchen und Regionen: Bloomberg, Crédit Agricole, JPMorgan, Toyota, T-Systems und Xiaomi gehören dazu. Hinter diesen Produktivumgebungen steht eine schnell wachsende Open-Source-Community, deren Ausführungsvolumen im Jahresvergleich um etwa das Zwanzigfache gestiegen ist. Die Wachstumskurve hat dieselbe Form, die ich bei Confluent erlebt habe: erst die Community, dicht dahinter die Unternehmen.

Warum Enterprise-Orchestrierung ein Wachstumsmarkt ist

Auf kleine Wetten lasse ich mich nicht ein. Ich erwarte, dass Kestra ein schnell wachsendes Start-up im Enterprise-Maßstab wird, bei dem die größten Unternehmen der Welt die Plattform in immer mehr Geschäftsbereichen und für immer mehr Anwendungsfälle einsetzen. Die Nachfrage bewegt sich bereits in diese Richtung.

Offene, skalierbare, zuverlässige und flexible Workflow-Orchestrierung wird überall gebraucht. Jeder Geschäftsbereich hat Prozesse, die ausgelöst, koordiniert, wiederholt, auditiert und gesteuert werden müssen. Finanzen, Betrieb, Daten, Plattform-Engineering, kundennahe Teams: Jeder hat eigene Workflows, und heute greift jeder zu einem anderen Tool. Eine Plattform für alle ist ein großer und dauerhafter Markt, keine Nische.

Mit Agentic AI wächst der Bedarf an Orchestrierung deutlich. Jeder Agent, der eine Aktion ausführt, braucht darunter einen gesteuerten, beobachtbaren Workflow. Und diese Workflows überschreiten genau die Grenzen zwischen Geschäftsbereichen, die die heutigen fragmentierten Tools nicht überbrücken können. Je mehr KI ein Unternehmen einsetzt, desto mehr braucht es eine Control Plane über alle Bereiche hinweg. Auch die Wirtschaftlichkeit spricht dafür: Laut einer McKinsey-Analyse agentischer Workflows treibt nicht der Token-Verbrauch die variablen Kosten produktiver Agenten, sondern die menschliche Aufsicht. Diesen Mix aus Agenten, deterministischen Systemen und menschlicher Prüfung zu koordinieren, ist vor allem eine Aufgabe für das Workflow-Design.

Orchestrierung auf einer Datenbank oder auf Kafka – und darüber hinaus

Man kann einfach anfangen. Kestra läuft auf einer Standarddatenbank, ohne dass man je an Kafka denken muss, und für viele Workloads reicht das völlig. Die Plattform ist von Grund auf event-driven, und das Datenbank-Backend bewältigt kleine und mittlere Größenordnungen ohne zusätzliche Komponenten.

Nach neun Jahren in der Nähe von Apache Kafka erwarten viele, dass ich mit dem Kafka-Thema eröffne. Also spreche ich es direkt an, denn hier liegt eine echte und unterschätzte Chance. Aber Kafka ist eine Option, keine Voraussetzung.

Ich habe zu viele Teams gesehen, die das falsche Werkzeug in die Orchestrierung zwingen. Manche orchestrieren Workflows mit Kafka Streams oder Flink. In den meisten Fällen ist das ein Anti-Pattern, denn keines von beiden wurde dafür gebaut. Lang laufende Wartezeiten, menschliche Freigaben und systemeübergreifende Abhängigkeiten lassen sich schlecht auf eine Dataflow-Topologie abbilden. Andere schrauben noch ein komplexes System dazu, nur um zu skalieren. Wieder andere basteln Python-Skripte zusammen und hoffen, dass sie halten.

Kestra geht einen saubereren Weg: auf einer klassischen Datenbank für kleine und mittlere Größenordnungen, auf einem vorhandenen Kafka-Cluster, wenn mehr Durchsatz nötig ist. Für die Tausenden Unternehmen, die Kafka bereits als Nervensystem nutzen, passt das natürlich. Alle anderen bleiben bei der Datenbank.

Was Kestra 2.0 ändert

Mit dem neu aufgebauten Kern von Kestra 2.0 sind Queue und Datenbank vollständig unabhängig und austauschbar. Neben Datenbank und Kafka lassen sich jetzt auch Redis, AMQP und Cloud-Messaging wie Google Cloud Pub/Sub als Queue-Backend nutzen. Queue und Repository werden getrennt gewählt, etwa Postgres als Repository mit Redis für das Queueing. Die Orchestrierungsschicht passt sich der vorhandenen Infrastruktur an, statt ihr die eigene aufzuzwingen.

Für regulierte Umgebungen ist eine zweite Änderung mindestens ebenso wichtig. Seit 2.0 verbinden sich Worker über einen einzigen ausgehenden gRPC-Stream mit der Control Plane. Sie halten keine Datenbankverbindung und keinen Zustand zwischen Tasks. Worker können damit in anderen Regionen, in segmentierten Netzwerken, On-Premises oder am Edge laufen, ohne dass ein Datenbankport geöffnet werden muss. Die Ausführung folgt den Daten und der Compliance-Grenze, statt beide zum Umzug zu zwingen.

Kafka ist aber nur einer von mehreren Einstiegen. Die größere Chance liegt jenseits meiner Herkunft: in der Modernisierung von Legacy-Schedulern, in Daten- und KI-Pipelines und in der unternehmensweiten Orchestrierung von Geschäftsprozessen.

Die Rolle des Global Field CTO bei Kestra

Der Global Field CTO ist die externe Technologie- und Business-Stimme von Kestra: gegenüber Kunden, Partnern, Analysten, Presse und der Community der Praktiker. Die Aufgabe ist, Kestra beim Wachstum zu unterstützen, über die Orchestrierungsdomänen hinweg, über Regionen hinweg und in der Community derer, die auf der Plattform bauen.

In der Praxis bedeutet das drei Dinge. Erstens die Arbeit mit CIOs und CTOs großer Unternehmen, in Briefings und Roundtables, um herauszufinden, wo Orchestrierung in ihre Architektur passt. Zweitens Briefings für Analystenhäuser wie Gartner, Forrester und IDC zu den Kundenmustern und Marktverschiebungen, die ich beobachte. Drittens die öffentliche Arbeit: Referenzarchitekturen, Keynotes, Wettbewerbspositionierung und Inhalte, die die Technologie auf konkrete Anwendungsfälle abbilden, in Finanzdienstleistung, Versicherung, Fertigung, Automobilindustrie, Telekommunikation, Handel, Logistik und Technologie.

In diesen letzten Bereich habe ich über Jahre viel investiert: Landscape-Reports, Branchenleitfäden, Bücher. Das mache ich weiter, jetzt mit Orchestrierung als verbindender Schicht zwischen Datenintegration, Process Intelligence und Agentic AI.

Ich empfehle die richtige Architektur, auch wenn sie nicht Kestra heißt

Eines wird sich gegenüber meiner bisherigen Arbeit nicht ändern: Ich empfehle die richtige Architektur, auch wenn Kestra nicht die Antwort ist.

Orchestrierung steht selten allein. Ein Unternehmen kann Celonis für Process Mining einsetzen, um seine Abläufe zu verstehen, und Kestra für die Prozessorchestrierung im großen Maßstab, sobald Agentic AI auf diese Erkenntnisse hin handelt. Ein anderes behält Camunda für menschenzentrierte, in BPMN modellierte Freigabeprozesse und nutzt Kestra für die technische Orchestrierung darunter: die Datenpipelines, Integrationen und Agent-Schritte, von denen diese Prozesse abhängen. In beiden Fällen ergänzen sich die Systeme.

Es gibt auch klare Fälle, in denen ich Architekten woandershin verweise. Wer ein System of Record für Enterprise Service Management mit CMDB und ITIL-Prozessen braucht, ist bei ServiceNow, BMC Helix oder Jira Service Management richtig. Kestra integriert sich mit diesen Systemen. Wer kontinuierlich auf Daten in Bewegung rechnen muss, etwa mit Joins und Aggregationen im Sub-Sekunden-Bereich, braucht Apache Flink, Kafka Streams oder Spark Structured Streaming. Und Mainframe-Scheduling oder die Automatisierung in ERP-Systemen wie SAP bleiben, wo sie sind: Kestra koordiniert um sie herum, stößt sie an und verbindet sie mit dem Rest des Unternehmens.

Meine Aufgabe ist, klar zu sagen, wo Kestra passt, wo nicht, und wie es mit dem Rest des Stacks zusammenspielt. Ohne diese Ehrlichkeit wäre die Rolle wertlos.

Europa heute, die USA als Nächstes

Die meisten Enterprise-Kunden hat Kestra heute in Europa. Der nächste Schritt sind die USA: Dort expandiert das Unternehmen in den kommenden Monaten strategisch und eröffnet eine Präsenz in New York. Diesen Schritt werde ich stark unterstützen. Kunden in Asien und Australien sind bereits produktiv, der Nahe Osten ist ein bewusst geplanter nächster Schritt.

Zum Autor: Kai Waehner ist Global Field CTO bei Kestra. Zuvor war er über neun Jahre beim Daten-Streaming-Pionier Confluent. Er schreibt regelmäßig über Datenintegration, Process Intelligence, Enterprise-Architektur und vertrauenswürdige Agentic AI, in seinem Newsletter sowie auf LinkedIn und X.