Die Softwarebranche muss sich nach Einschätzung des Bitkom auf einen tiefgreifenden Umbau ihrer Geschäftsmodelle einstellen. Künftig werde Software weniger nach Arbeitszeit oder pauschalen Lizenzen verkauft, sondern stärker nach messbaren Ergebnissen abgerechnet, heißt es in der Studie „Softwarewelt 2036“. Auslöser ist vor allem der Einsatz von KI-Agenten, die nicht mehr nur als Werkzeug dienen, sondern selbst Aufgaben übernehmen und Prozesse ausführen.

Der Verband verweist darauf, dass sich damit die Logik vieler bestehender Erlösmodelle verschiebt. Wenn ein KI-Agent die Arbeit mehrerer Menschen erledigen kann, lässt sich Aufwand nach Köpfen oder Stunden immer schwerer rechtfertigen. Unter Druck geraten laut Bitkom vor allem Body Leasing, stundenbasierte IT-Dienstleistungen, FTE-Outsourcing und Offshore-Bodyshopping. Auch klassische Entwicklungs- und Support-Pyramiden, deren Wert stark an menschlicher Arbeitsmenge hängt, verlieren demnach an Tragfähigkeit.

Messbare Ergebnisse statt Arbeitszeit

An die Stelle von Zeit- und Lizenzmodellen treten nach Einschätzung des Bitkom zunehmend ergebnisbezogene Abrechnungen. Kunden zahlen dann nicht mehr primär für Softwarezugang oder Personalstunden, sondern für konkrete Resultate wie gelöste Tickets, behobene Sicherheitslücken, bereitgestellte Features oder bestandene Compliance-Prüfungen. Der Bitkom erwartet, dass Outcome- und Value-based Pricing vor allem im B2B-Geschäft an Bedeutung gewinnt.

Damit verändert sich auch die Rolle von Software. Sie werde künftig weniger als einzelnes Werkzeug verstanden, das Menschen bedienen, sondern als Instanz, die KI-Agenten steuert, Prozesse orchestriert und Ergebnisse liefert. Der Bitkom beschreibt dies als Entwicklung hin zu „Agentic Systems“, in denen KI-Agenten Aufgabenketten abarbeiten. Entscheidend werde die Fähigkeit, Geschäftsergebnisse in solche agentenfähigen Architekturen zu übersetzen.

Mit dieser Entwicklung verändern sich auch die Anforderungen an Beschäftigte. Manuelles Coding, Standardlogik und triviale Tests verlieren an Gewicht. Wichtiger werden Architektur, Review, Evaluation, Orchestrierung und die Bewertung von KI-Ergebnissen. Hinzu kommen Datenkompetenz, Urteilsfähigkeit, Verantwortung und die Fähigkeit, zwischen Fachabteilungen, IT und Regulierung zu vermitteln.

Domänenwissen und Vertrauen als Wettbewerbsvorteil

Für Anbieter sieht der Bitkom vor allem dort Chancen, wo technologische Kompetenz mit Branchenwissen zusammenkommt. Reines Coding werde weniger zum Differenzierungsmerkmal, heißt es in der Studie. Wichtiger würden Domänenwissen, Prozessverständnis und die Fähigkeit, fachliche Anforderungen in KI-gestützte Systeme zu übersetzen. Der Verband spricht in diesem Zusammenhang von Übersetzern zwischen Business, IT, Daten, Regulierung und Menschen.

Gleichzeitig gewinnt Vertrauen an Bedeutung. Anbieter müssen Nachvollziehbarkeit, Auditierbarkeit und europäische Datenhaltung von Anfang an mitdenken, meint der Bitkom. Das könne gerade in regulierten Branchen zu einem Wettbewerbsvorteil werden. Compliance und Datensouveränität würden dann nicht nur als Pflicht, sondern auch als Verkaufsargument wirken.

Plattformen, Daten und Handlungsfelder

Parallel dazu verschiebt sich der Markt aus Sicht des Bitkom weg von isolierten Einzellösungen hin zu Plattformen und Ökosystemen. Einzeltools ohne Anbindung an größere Prozess- und Datenstrukturen hätten künftig schlechtere Karten. Daten sind dabei die Grundlage, um Wirkung nachzuweisen, Systeme zu verbessern und neue Geschäftsmodelle zu entwickeln. Entscheidend sei nicht nur der Besitz von Daten, sondern ihre Qualität, ihr Kontext, ihre Governance und ihre verantwortungsvolle Nutzung.

Für Unternehmen empfiehlt der Bitkom deshalb, Datenbasis und Systemlandschaften zu bereinigen, KI von Pilotprojekten systematisch zu skalieren und eine einheitliche Daten- und Agentenplattform aufzubauen. Rollenprofile und Karrierepfade müssten an die neuen Anforderungen angepasst werden. Fachkräfte mit Domänenwissen und KI-Orchestrierung seien besonders gefragt.

Auch die Politik muss reagieren, so der Bitkom. Der Verband fordert eine modernisierte Aus- und Weiterbildung, breiter angelegte KI- und Tech-Kompetenzen sowie eine Regulierung, die stärker auf Ergebnisse als auf einzelne Werkzeuge zielt. Gesetze und Vorgaben sollten demnach schneller überprüft und an technologische Entwicklungen angepasst werden. Zudem plädiert der Bitkom für Experimentierräume, schnellere Verfahren und den Ausbau europäischer KI- und Compute-Infrastruktur.

Die Studie „Softwarewelt 2036“ basiert auf Interviews mit Führungskräften und Experten aus der Softwarebranche und angrenzenden Bereichen. Sie ist nicht repräsentativ, soll aber zentrale Muster und Zukunftsbilder sichtbar machen. Für Unternehmen und Politik, so die Schlussfolgerung des Bitkom, bleibe nicht viel Zeit, um sich auf die neuen Bedingungen einzustellen.

(fo)

Montag, 9 Uhr. Ein Entwickler braucht einen Testserver. Er öffnet das Ticketsystem, trägt Hostname, Betriebssystem und Kostenstelle ein und wartet. Einen Tag, manchmal drei. Irgendwann landet die VM in seiner Inbox, konfiguriert nach dem Stand von vor zwei Wochen, weil niemand das Template seitdem angefasst hat.

Der Reflex, dieses Problem mit vorhandenen Werkzeugen zu lösen, ist verständlich. Eine Pipeline in Azure DevOps oder GitHub Actions ist schnell geschrieben. Doch CI/CD-Tools sind für etwas anderes gebaut: Code bauen, testen, deployen. Sie folgen einem Commit, laufen durch und sind fertig. Langlebige Workflows, Retry-Logik und State-Management sind nicht ihr Revier.

Genau diese Lücke füllt Kestra. Das Tool wird seit 2021 von Kestra Technologies entwickelt und ist seit Februar 2022 – im Kern als Open-Source-Projekt unter der Apache-2.0-Lizenz – öffentlich verfügbar. Kommerzielle Enterprise-Funktionen ergänzen den OSS-Kern. Kestra versteht sich als universeller Orchestrator: für Ops-Automatisierung, Data Pipelines, Event-driven Workflows und zunehmend auch für KI-Agenten und -Workflows; alles deklarativ in YAML, alles versionierbar in Git. Dieser Artikel zeigt anhand eines konkreten Beispiels, wie das in der Praxis aussieht: Ein Entwickler oder eine Entwicklerin fordert per Formular eine Hetzner-VM an, Kestra provisioniert sie vollautomatisch per Terraform. Der gesamte Code für Terraform, das Kestra-Setup sowie die Kestra Flows sind im GitHub-Repository des Autors zu finden.

Orchestrierung ist nicht dasselbe wie Automatisierung

Wer zum ersten Mal von Kestra hört, denkt unweigerlich, es handele sich um ein weiteres Tool, das Shell-Skripte in ein hübsches UI verpackt. Das trifft es nicht. Der Unterschied liegt im Konzept: Ein Shell-Skript oder eine CI/CD-Pipeline sind sequenziell: auf Schritt A folgt B, dann C, und am Ende ist der Status entweder fertig oder fehlgeschlagen. Was dazwischen passiert, interessiert das Tool nicht. Kestra hingegen orchestriert: Es kennt den Zustand jedes einzelnen Schritts, kann auf externe Ereignisse warten, Fehler gezielt behandeln, Schritte parallelisieren und einen Workflow nach Stunden oder Tagen an exakt der Stelle fortsetzen, an der er unterbrochen wurde.

Das ist keine rein akademische Unterscheidung. In der Praxis bedeutet es, dass Kestra Workflows abbilden kann, die mit klassischen Pipeline-Tools nicht darstellbar sind: ein Provisionierungs-Job, der wartet, bis ein externes System bereit ist, eine Daten-Pipeline, die bei einem HTTP-Fehler drei Minuten pausiert und es dann erneut versucht, ein Deployment, das erst nach einer manuellen Freigabe weiterläuft. Was andere Tools „Pipeline“ nennen, ist in Kestra ein Flow.

Das Entwicklungsteam hinter dem Projekt positioniert Kestra bewusst für ein breites Einsatzspektrum. Im Vordergrund stehen dabei:

• Ops Automation: Infrastruktur bereitstellen, Cluster provisionieren, wiederkehrende Betriebsaufgaben automatisieren.
• Data Pipelines: Kestra tritt hier in direkten Wettbewerb mit Apache Airflow und Prefect
• Event-driven Workflows: Flows, die auf Webhooks, Queue-Nachrichten oder Dateiänderungen reagieren.
• KI-Workflows: Kestra orchestriert KI-Agenten genauso wie klassische Ops-Tasks.

Die vier Grundbausteine

Kestra kennt vier Konzepte, die Entwickler zunächst verinnerlichen sollten, um den Gesamtansatz des Tools leichter zu verstehen.

Ein Flow ist die oberste Einheit, vergleichbar mit einer Pipeline-Definition, aber mit deutlich mehr Ausdruckskraft. Jeder Flow hat eine ID, einen Namespace zur Strukturierung und eine Liste von Tasks. Er lebt als YAML-Datei in Git und lässt sich darüber versionieren und deployen.

Tasks sind die einzelnen Schritte innerhalb eines Flows. Kestra bringt eine umfassende Bibliothek an eingebauten Task-Typen mit: HTTP-Requests, Dateioperationen, Shell-Kommandos, Container-Ausführung, Schleifen, Bedingungen und Parallelisierung. Tasks können Outputs produzieren, die nachfolgende Tasks als Inputs verwenden. Dadurch entsteht ein nachvollziehbarer Datenfluss zwischen den einzelnen Schritten des Flows.

Trigger definieren, wann ein Flow startet. Zur Auswahl stehen Zeitpläne (Cron), Webhooks, andere Flows als Auslöser oder manuelle Ausführung über das UI. Der manuelle Trigger ist dabei nicht zu unterschätzen: Er öffnet im Kestra-UI automatisch ein Eingabeformular für alle deklarierten Inputs.

Plug-ins erweitern Kestra um externe Integrationen. Das offizielle Plug-in-Ökosystem umfasst unter anderem Terraform, Kubernetes, AWS, Azure, GCP, Slack, dbt und Airbyte. Plug-ins sind versionierte JARs, die Kestra beim Start lädt, ohne separates Dependency-Management oder pip install.

Das folgende Listing zeigt einen minimalen Flow:

id: hello-kestra
namespace: demo

inputs:
  - id: message
    type: STRING
    defaults: "Hallo von Kestra"

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "{{ inputs.message }}"

Dieser Flow zeigt das Wesentliche: Der Namespace demo strukturiert Flows im UI ähnlich wie Ordner. Der Input message erscheint bei der manuellen Ausführung als Textfeld. Der Task referenziert den Input per Pebble-Template-Syntax {{ inputs.message }}. Dieselbe Syntax funktioniert überall im Flow für Secrets, für Outputs vorheriger Tasks sowie für Metadaten der Execution.

Kein Ersatz, sondern Ergänzung

Die Frage kommt verlässlich: Haben wir nicht schon Azure DevOps? Brauchen wir das wirklich? Die Antwort ist ja und nein. Azure DevOps oder GitHub Actions bleiben für das, was sie können, ungeschlagen: Code kompilieren, Tests ausführen, Container bauen, Artefakte deployen. Wer diese Aufgaben ersetzen will, hat das falsche Problem, denn Kestra setzt an einer anderen Stelle an.

CI/CD bleibt die richtige Schicht für alles, was aus dem Repository kommt: bauen, testen, ausliefern. Viele Betriebsprozesse beginnen jedoch mit einer Anfrage statt mit einem Commit: Eine Umgebung soll entstehen, ein Change muss geprüft, eine Ressource freigegeben oder ein externer Dienst eingebunden werden. Genau dort ergänzt Kestra die vorhandene CI/CD-Landschaft.

Ein konkretes Beispiel: Ein Entwickler will einen Kubernetes-Cluster provisionieren. In einer Azure-DevOps-Pipeline lässt sich das technisch abbilden, mit terraform apply als Skript-Task. Was fehlt, ist alles drumherum: Es gibt kein strukturiertes Eingabeformular für Entwickler und keine saubere Retry-Logik, wenn der Cloud-Provider einmal nicht antwortet. Es gibt auch kein Log, das zeigt, wer wann welche Ressource angefordert hat. Vor allem aber behandelt eine Pipeline Terraform im Stil von „fire and forget“: Skript starten, durchlaufen lassen, auf ein Ergebnis hoffen – was dazwischen passiert, ist nicht greifbar. Kestra kapselt dagegen jede Execution vollständig mit ihren Parametern: State, Logs und Retry-Verhalten sind eindeutig einer konkreten Execution zugeordnet und im UI nachvollziehbar. Schlägt ein Schritt fehl, weiß Kestra, an welcher Stelle, mit welchen Eingaben und in welchem Zustand, und kann gezielt darauf reagieren, statt blind von vorne zu beginnen.

Vergleich mit Airflow und Prefect: Der Blickwinkel ist entscheidend

Welche Alternativen zu Kestra infrage kommen, hängt vom Blickwinkel ab, der sich etwa zwischen Data Engineering und Platform Engineering erheblich unterscheidet. Wer aus dem Data-Engineering-Umfeld kommt, denkt meist zuerst an Apache Airflow, heute ein Top-Level-Projekt der Apache Software Foundation, oder an Prefect, das vom gleichnamigen Unternehmen entwickelt wird. Airflow ist der etablierte Standard für DAG-basierte Daten-Pipelines mit Abhängigkeiten, Scheduling und Retry-Logik. Prefect ist eine modernere Alternative, die mit geringerem Betriebsaufwand und einer schlankeren API punktet. Kestra besetzt denselben Raum, ist aber weniger Python-zentrisch: Flows sind in YAML definiert, Tasks sind Plug-in-Aufrufe, Python-Wissen ist nicht erforderlich. Das macht Kestra vor allem für gemischte Teams zugänglicher.

Im Platform Engineering kommen hingegen ganz andere Werkzeuge zum Einsatz. Verbreitet sind unter anderem Argo Workflows als Kubernetes-nativer Orchestrator, die Ansible Automation Platform für Betriebsaufgaben und Configuration Management oder Terraform Cloud für Infrastructure-as-Code-Workflows. All diese Tools lösen echte Probleme, aber jedes ist fest in seinem Paradigma verankert. Terraform Cloud macht Terraform, Argo macht Kubernetes-Workflows, die Ansible Automation Platform macht Ansible. Kestra gibt sich hier bewusst universeller: Ein Flow kann einen Terraform-Container starten, danach ein PowerShell-Skript ausführen, eine HTTP-API aufrufen und das Ergebnis in Slack melden – in einem einzigen YAML-Flow, ohne dass das Tool Rücksicht auf die darunter liegenden Technologien nehmen müsste.

Aus Entwicklersicht bleiben Azure DevOps und GitHub Actions erste Wahl für die CI/CD-Schicht. Airflow oder Prefect können in datengetriebenen Umgebungen weiter ihren Dienst tun. Kestra ergänzt aber dort, wo keines dieser Tools zu Hause ist: als Orchestrierungsschicht, die heterogene Toollandschaften zusammenhält, gleichzeitig aber auch als Ersatz für einzelne Tools dienen kann.

Lokal testen, im Cluster betreiben

Kestra lässt sich lokal per Docker Compose starten. Die vollständige docker-compose.yml liegt im begleitenden GitHub-Repository. Der Befehl docker compose up -d genügt, danach ist das UI unter sofort erreichbar:

Für den produktiven Betrieb auf Kubernetes gibt es ein offizielles Helm-Chart. Die Komponenten (Server, Scheduler, Executor und Worker) laufen als separate Deployments und lassen sich unabhängig skalieren. Worker übernehmen die eigentliche Task-Ausführung und sind der primäre Skalierungshebel: Mehr parallele Executions bedeuten mehr Worker-Replicas, der Rest der Infrastruktur bleibt stabil. Wer Kestra-Ressourcen (Flows, Namespaces, Secrets, User und Rollen) ebenfalls als Code verwalten will, greift zum offiziellen Terraform-Provider: Er bildet die gesamte Kestra-Konfiguration als Terraform-Ressourcen ab und lässt sich nahtlos in bestehende Infrastructure-as-Code-Pipelines integrieren.

Seit Herbst 2024 kooperieren AMD und Intel in der x86 Ecosystem Advisory Group, auch um sich gegen Konkurrenten wie ARM und RISC-V zu stärken. Nun ist die gemeinsam erarbeitete Spezifikation für neue x86-Prozessorbefehle erschienen, die die Verarbeitung von KI-Algorithmen beschleunigen sollen: Die AI Compute Extensions, kurz „ACE“.

Bei ACE geht es vor allem um Matrix-Multiplikationen mit KI-Datenformaten für das Inferencing mit quantisierten Gewichten.

Konkurrent ARM hat bereits Scalable Matrix Extensions (SME2) spezifiziert, die auf die Scalable Vector Extensions (SVE2) aufbauen. SME-Rechenwerke lassen sich auf unterschiedliche Art in ARM-SoCs integieren. Apple baut SME2 seit dem M4 ein, Qualcomm ab dem Snapdragon X2.

Eng mit AVX verknüpft

Die AI Compute Extensions (ACE) Specification steht in Version 1.15 auf der Website der x86 Ecosystem Advisory Group zum Download bereit. Die Spezifikation beschreibt nur die Befehle, nicht die konkrete Implementierung.

Kommende ACE-Rechenwerke sind eng mit den Advanced Vector Extensions (AVX) gekoppelt und nutzen beispielsweise dieselben Register. Konkret nennt die Spezifikation AVX10. Sie erwähnt zudem die bisher nur von Intel in aktuellen Xeon-Serverprozessoren eingebauten Advanced Matrix Extensions (AMX).

Prozessoren mit ACE-v1-Rechenwerken müssen auch einen bestimmten Teil des Befehlsumfangs von AVX10.2 beherrschen.

Viele KI-Datenformate

ACE v1 beschreibt 11 Datenformate, einige in unterschiedlichen Darstellungen. Mit Daten in diesen Formaten müssen ACE-Rechenwerke nicht nur rechnen können, sondern die Spezifikation legt auch eine Fülle von Formatumwandlungen fest.

NPU-Konkurrenz

Seit 2023 sind x86-Prozessoren mit zusätzlich eingebauter Neural Processing Unit (NPU) im Handel. Die verarbeiten bestimmte Datenformate besonders schnell und effizient, sind aber wenig flexibel und belegen relativ viel Chip-Fläche.

Microsoft macht seit 2024 eine NPU mit einer Leistung von mindestens 40 Billionen INT8-Operationen pro Sekunde (40 Tops) zur Voraussetzung für das Marketing-Label Copilot+. Mittlerweile weicht Microsoft diese Vorgabe auf und ermöglicht auch GPUs. Mit kommenden ACE-tauglichen Prozessoren dürften weitere Änderungen nötig werden.

Nach bisherigen Informationen dürften ACE-v1-kompatible x86-Prozessoren frühestens 2028 erscheinen. Denn bisher haben weder AMD für Zen 6 noch Intel für Nova Lake ACE erwähnt. AMD nennt erst für Zen 7 eine neue „Matrix Engine“, vermutlich ACE-kompatibel.

Hören Sie dazu auch:

(ciw)