Connect with us

Entwicklung & Code

Domain-driven Design: Beschreibungssprache ESDM legt das Modell neben den Code


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Domain-driven Design (DDD) und Event Sourcing leben von einem präzisen Vokabular. Aggregates, Bounded Contexts, Process Managers, Read Models, Context Mappings: Wer in diesen Begriffen denkt, hat ein gemeinsames Werkzeug, um über fachliche Systeme zu sprechen. Solange das Gespräch während eines Workshops live stattfindet, funktioniert das verlässlich. Das Modell ist konsistent, weil alle Beteiligten es gleichzeitig im Kopf tragen.

Weiterlesen nach der Anzeige


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Sobald der Workshop jedoch endet, beginnt das Problem. Das Modell verlässt den Raum nicht als gemeinsames Artefakt, sondern als Sammlung von Bruchstücken: ein paar Folien aus dem letzten Review, ein Whiteboard-Foto, eine README.md, verstreute Code-Kommentare, vielleicht ein Diagramm im Wiki. Jede dieser Quellen ist plausibel, aber keine ist autoritativ. In diesem Beitrag stelle ich die von meiner Firma the native web entwickelte Sprache ESDM (Event-Sourced Domain Modeling) vor und beschreibe, warum sie aus meiner Sicht die richtige Antwort auf dieses Problem ist.

Wohin Modelle verschwinden, sobald der Workshop endet

Das eigentliche Drama spielt sich in den Wochen nach dem Workshop ab. Ein Entwickler reicht eine Refactoring-Änderung ein, die einen Aggregatnamen umbenennt. Das Code Review winkt sie durch. Niemand denkt an die Folien, niemand öffnet das Wiki, niemand sucht das Whiteboard-Foto wieder heraus. Das Modell auf der Platte verändert sich, das Modell im Kopf der anderen bleibt unverändert, und der Drift beginnt.

Sechs Monate später kommt eine neue Kollegin ins Projekt. Sie liest die Folien aus dem Onboarding, weil das die einzige zusammenhängende Beschreibung ist, die sie findet. Was sie liest, stimmt nicht mehr mit der Realität überein. Ein Bounded Context heißt anders, ein Event existiert nicht mehr, ein ehemals Aggregat ist in zwei zerlegt worden. Die Folien sind kein Modell, sie sind ein Foto eines Modells aus einem bestimmten Monat.

In dieser Lage gibt es eigentlich nur drei mögliche Quellen der Wahrheit, und keine davon ist eine gute: Die Folien sind veraltet, das Wiki ist veraltet, und der Code beschreibt das Modell nicht, sondern führt es aus. Wer die fachliche Wahrheit wissen will, muss aus dem Code rückwärts rekonstruieren, was die ursprüngliche Idee einmal war. Das ist anstrengend, fehleranfällig und nicht skalierbar.

Weiterlesen nach der Anzeige

Der Kern des Problems ist, dass das Modell kein erstklassiges Artefakt ist. Es hat keinen festen Ort, kein verbindliches Format, keine prüfbaren Eigenschaften. Es ist nirgendwo zu Hause, also lebt es überall ein bisschen, und überall ein bisschen heißt im Zweifel nirgendwo richtig.

Was eine Modellierungssprache eigentlich leisten muss

Aus diesem Befund ergibt sich eine ziemlich genaue Anforderungsliste an eine Lösung. Das Modell muss versionierbar sein, also als Text vorliegen, den eine Versionsverwaltung sinnvoll diffen kann. Es muss neben dem Code im Repository leben, damit derselbe Pull-Request, der den Code ändert, auch das Modell einbezieht.

Es muss prüfbar sein, in dem Sinne, dass eine Maschine bestimmte strukturelle Aussagen über das Modell automatisch validieren kann. Ob jedes Aggregat seine Events benennt, ob jedes Event einen Erzeuger hat, ob jeder Context-Mapping-Verweis auf einen tatsächlich existierenden Bounded Context zeigt: Solche Fragen darf nicht der Lesende beantworten müssen, sondern die Werkzeugkette.

Es muss von Werkzeugen lesbar sein, also einer eindeutigen Grammatik folgen. Sobald das Format steht, lassen sich Validatoren, Generatoren, IDE-Integrationen und KI-gestützte Modellierungswerkzeuge dagegen bauen. Dieser Punkt klingt wie ein Nebensatz, ist aber der Hebel, der eine Sprache von einer Konvention unterscheidet.

Und es muss frei von Dialekten sein. Ein Format, das sich pro Team konfigurieren lässt, beschreibt am Ende keine gemeinsame Sprache, sondern eine Familie verwandter Privatsprachen. Der Wert eines geteilten Modells kollabiert, sobald jedes Projekt seine eigenen Regeln zuschneidet. Wer sich auf die Sprache verlassen können will, braucht eine Sprache, die nicht jede Stelle einzeln aushandelbar ist.

ESDM legt das Modell neben den Code

ESDM, kurz für Event-Sourced Domain Modeling, ist genau die Sprache, die diesen Anforderungen entspricht. Die YAML-basierte Sprache mit eingebauter Werkzeugkette ist auch für den kommerziellen Einsatz kostenfrei. Modelle bestehen aus Dateien mit der Endung .esdm.yaml, jede Datei enthält ein oder mehrere Dokumente, jedes Dokument deklariert eine apiVersion und einen kind-Eintrag und beschreibt damit genau ein Element der Domäne.

Die Werkzeugkette ist ein einziges Binary, das auf macOS, Linux und Windows läuft. Das Schema, gegen das die Werkzeuge validieren, ist im Binary eingebettet, nicht aus dem Netz nachgeladen. Das macht ESDM vollständig offline-fähig: Es funktioniert in abgeschotteten Build-Umgebungen, in CI-Runnern ohne ausgehende Netzverbindung und auf dem Laptop im Zug.

Der Effekt dieses Aufbaus ist greifbar. Das Modell liegt nicht mehr in einem entfernten System, sondern direkt im Repository, in einem Verzeichnis neben dem Code. Wer den Code bearbeitet, sieht das Modell. Wer das Modell bearbeitet, sieht es im Diff des Pull Request. Niemand muss sich daran erinnern, dass es das Modell gibt; es liegt sichtbar im Verzeichnisbaum.

Genauso wichtig ist, was sich dadurch im Review-Verhalten verändert. Sobald das Modell Teil des Repositorys ist, wird es Teil des Code-Reviews. Eine Refactoring-Änderung, die einen Aggregatnamen umbenennt, muss die entsprechende .esdm.yaml-Datei in derselben Änderung mitbewegen, sonst meldet der Linter den Bruch. Der Drift wird nicht durch Disziplin verhindert, sondern durch die Werkzeugkette.

Vokabular und Erweiterungen

Inhaltlich deckt ESDM das Vokabular ab, mit dem Domain-driven Design und Event Sourcing operieren. Domains und Subdomains beschreiben den fachlichen Rahmen. Bounded Contexts grenzen Vokabularien voneinander ab. Aggregates, Dynamic Consistency Boundaries (DCBs) und Process Manager tragen die Konsistenzregeln. Events und Commands tragen die Fakten und die Absichten. Read Models und Queries beschreiben die Leseseite. Context Mappings beschreiben, wie Bounded Contexts sich aufeinander beziehen. Actors, Domain Services, Event Handler, Policies und External Systems schließen die Lücken, die in realen Systemen sonst implizit bleiben.

Damit deckt der Kern den Schreib- und Leseweg eines Event-getriebenen Systems ab, von der Absicht über das Faktum bis zur projizierten Sicht. Das Modell ist nicht ausführbar; es beschreibt das Was, nicht das Wie. Diese Trennung ist die Voraussetzung dafür, dass dasselbe Modell für unterschiedliche Implementierungen tragen kann, ohne sich an eine Laufzeit zu binden.

Über den Kern hinaus gibt es Erweiterungen, die Artefakte rund um das eigentliche Modellieren beschreiben. Die Domain-Storytelling-Erweiterung hält Entdeckungsgeschichten als eigene Dokumentenart fest, mit Akteurinnen und Akteuren, Arbeitsobjekten und den Aktivitäten, die sie verbinden. Die Given-When-Then-Erweiterung erfasst Verhaltensbeispiele, also vorausgehende Events, eine auslösende Handlung und die erwarteten Ausgänge.

Beide Erweiterungen folgen denselben Konventionen wie der Kern und werden von derselben Werkzeugkette validiert. Sie injizieren aber keine neuen Bausteine in den Kern, und ein Kerndokument validiert nie gegen ein Erweiterungsschema. Diese Asymmetrie ist bewusst: Sie hält den Kern schmal und erlaubt es trotzdem, die Oberfläche der Sprache mit der Zeit wachsen zu lassen, ohne den Bestand zu gefährden.

Die Versionierung des Schemas folgt derselben Disziplin, die Sie aus Kubernetes-API-Gruppen kennen. Jedes Dokument deklariert eine apiVersion, und diese Version bindet das Dokument an eine konkrete Schema-Generation. Non-breaking Changes erhöhen die Schema-Revision, ohne die apiVersion anzufassen; Breaking Changes wandern in eine neue Hauptversion, und alte Dokumente validieren weiter gegen das alte Schema. Stabilität ist die Voreinstellung, Wechsel sind eine bewusste Entscheidung.

Der Linter hält das Modell sauber

Im Zentrum der Werkzeugkette steht der Linter. Er liest die .esdm.yaml-Dateien unter einem Verzeichnis, parst sie gegen das eingebettete Schema, prüft eine feste Liste struktureller und modellierender Regeln und meldet jede Verletzung als Diagnose mit Datei, Zeile und Spalte. Eine saubere Modellierung erzeugt keine Ausgabe und verlässt das Werkzeug mit Statuscode 0.

Der feste Regelkatalog ist eine bewusste Entscheidung. Es gibt keine Projektkonfigurationsdatei, keine Severity-Schalter, kein Abschalten einzelner Regeln. Eine Regel gilt oder sie gilt nicht; diese Entscheidung trifft die Werkzeugkette, nicht das Repository. Der Preis dafür ist, dass eine Regel gelegentlich strenger wirkt, als die konkrete Situation zu verlangen scheint. Der Gewinn ist, dass jedes ESDM-Modell, egal von welchem Team, dieselben Eigenschaften garantiert. Eine Sprache mit Schaltern beschreibt am Ende viele Sprachen mit demselben Namen, und der Wert des gemeinsamen Modells geht verloren.

Diagnosen sind Orte, keine Stack Traces. Jede Meldung verweist auf eine Datei, eine Zeile und eine Spalte und beschreibt das Problem in einem kurzen Satz, der das Vokabular der Modellierenden spricht, nicht das der Werkzeugkette. Es gibt keine Fehlernummern, die in einer Tabelle nachgeschlagen werden müssten, und keine internen Aufrufketten, die nach außen sichtbar wären.

Die volle Wirkung entfaltet der Linter, sobald er in der Continuous-Integration-Pipeline läuft. Ein Pull Request, der ein Aggregat umbenennt, ohne das Modell mitzuziehen, scheitert am CI-Schritt und wird nicht gemergt. Ein neues Event ohne Erzeuger oder ohne Konsumenten scheitert genauso. Der Drift, der vorher durch Disziplin verhindert werden musste, wird durch eine kurze, präzise Diagnose verhindert.

Konsistent mit ESDM

Konkret zahlt sich diese Architektur in mehreren Szenarien aus. Im Event-Storming-Workshop oder in der Domain-Storytelling-Sitzung gibt ESDM den Entdeckungen einen Ort, an dem sie überleben. Statt nach dem Workshop Fotos zu archivieren, schreibt man die Events, Commands, Akteurinnen und Akteure und Bounded Contexts in .esdm.yaml-Dateien und bekommt sofort Rückmeldung, ob das Modell intern konsistent ist. Ein Aggregat, das keine Events besitzt, ein Command, das niemand publiziert, ein Process Manager ohne Auslöser: Solche Lücken zeigt der Linter, bevor sie sich als unausgesprochene Annahmen verfestigen.

Bei einem bestehenden System, dessen Modell nur in den Köpfen der Beteiligten existiert, lässt sich ESDM als nachträgliches Beschreibungswerkzeug einsetzen. Beginnen Sie mit den Konsistenzeinheiten: jedes Aggregat, jeden Process Manager, jede Dynamic Consistency Boundary (DCB), jedes Read Model. Listen Sie die Events auf, die jeweils publiziert werden, und die Commands, die akzeptiert werden. Die Übung selbst legt Lücken frei, und am Ende steht ein Modell, das mit dem Code mitwachsen kann, statt ihm hinterherzulaufen.

Sobald das Modell vorliegt, wird es zum natürlichen Gesprächsformat mit fachlichen Stakeholderinnen und Stakeholdern. Der view-Befehl rendert das Modell als hierarchische Übersicht, von der Domäne über die Subdomains und Bounded Contexts bis hinunter zu den Konsistenzeinheiten und ihren Events und Commands. Diese Übersicht ist auf Knopfdruck verfügbar und entspricht garantiert dem Quellzustand. Domänenexpertinnen und Domänenexperten lesen darin dieselben Begriffe, die sie selbst verwenden, und können ohne Umweg über Implementierungsdetails Rückmeldung geben.

In Systemen mit mehreren Teams und gemeinsamen Bounded Contexts macht ESDM die Verträge zwischen den Teams explizit. Ein Context Mapping beschreibt die Beziehung zwischen zwei Bounded Contexts, ein teamübergreifender Event-Verweis ist eine geprüfte Tatsache und keine Vermutung. Was zwischen zwei Teams einmal vereinbart und im Modell festgehalten ist, prüft die Werkzeugkette danach automatisch. Die fachliche Annahme ist nicht mehr nur eine geteilte Erinnerung, sondern eine prüfbare Aussage.

Schließlich passt ESDM erstaunlich gut zu Workflows mit KI-Unterstützung. Das YAML ist schlicht genug, dass große Sprachmodelle es direkt lesen und schreiben, und das fixierte Schema und das benannte Vokabular geben dem Modell genau die Leitplanken, die es braucht, um etwas Kohärentes zu produzieren. Ein Modell aus einem Domänengespräch zu skizzieren oder aus einem Code-Bestand Kandidaten für Aggregates und Events zu extrahieren, sind Aufgaben, die sich mit dem ESDM-Vokabular zuverlässiger und überprüfbarer lösen lassen, als wenn das Modell in Prosa beschrieben wird.

Was ESDM bewusst nicht ist

Genauso wichtig wie die Beschreibung dessen, was ESDM ist, ist auch die Abgrenzung zu dem, was es nicht ist. ESDM ist kein Eventstore. Es speichert und liest keine Ereignisse, es legt nichts in eine Datenbank ab. ESDM beschreibt lediglich, welche Events es überhaupt geben soll.

ESDM ist auch kein Framework. Es schreibt keinen Programmierstil vor, keine Klassenhierarchie, keine Annotationen, keinen bestimmten Aufbau eines Service. Welche Sprache, welches Framework, welche Bibliothek Sie für die tatsächliche Implementierung verwenden, bleibt vollständig Ihnen überlassen. ESDM mischt sich in diese Entscheidungen nicht ein.

ESDM ist kein Codegenerator und keine Laufzeitumgebung. Es erzeugt aus dem Modell keine Klassen, keine Migrationen, keine API-Endpunkte. Es führt nichts aus. Diese Entscheidung ist keine Lücke, sondern Programm: Eine Modellierungssprache, die zugleich generieren oder ausführen will, zwingt mich zu Laufzeitentscheidungen, und eine Laufzeit, die zugleich modelliert, vergräbt das Modell unter Implementierungsdetails.

ESDM hält die beiden Seiten getrennt. Es ist eine deskriptive Schicht, die neben dem Code lebt und das Modell ehrlich hält, und es ist genau das, nichts darüber hinaus. Diese Sparsamkeit ist die Voraussetzung dafür, dass ESDM sich frei mit dem kombinieren lässt, was Sie tatsächlich in Produktion betreiben.

Lesen Sie auch


(rme)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Kestra: Ops-Automation jenseits von CI/CD


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

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.

Weiterlesen nach der Anzeige


Philip Lorenz

Philip Lorenz

Philip Lorenz ist als DevOps- und Cloud-Engineer tätig. Zudem hält er Schulungen zu den Themen PowerShell, Automatisierung und Cloud-Computing.

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.




Die auf Developer Experience (DX) und Platform Engineering spezialisierte CLC-Konferenz findet vom 11. bis 12. November 2026 in Mannheim statt. Ein besonderer Fokus liegt darauf, wie Agentic AI die Arbeit von Developern, Software-Architekten, DevOps- und Platform Engineers verändert und wie sich digitale Souveränität nachhaltig erreichen lässt.

Ab sofort sind Tickets zum Frühbucherpreis verfügbar.

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.

Weiterlesen nach der Anzeige

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:


Kestra-Dashboard mit Plugins-Menü und Suchleiste

Kestra-Dashboard mit Plugins-Menü und Suchleiste

Kestra bringt bereits über 1300 Plug-ins mit (Abb. 1).

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.



Source link

Weiterlesen

Entwicklung & Code

AMD und Intel spezifizieren KI-Befehlssatz „ACE“ für x86-Prozessorkerne


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“.

Weiterlesen nach der Anzeige

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.

Weiterlesen nach der Anzeige

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.

Datenformate der AI Compute Extensions ACE v1
Format Beschreibung
INT8 Ganze Zahlen mit 8 Bit (Integer)
INT32 Ganze Zahlen mit 32 Bit
FP32 Gleitkommazahlen mit 32 Bit laut IEE-754 (SE8M32)
FP16 SE5M10
BF16 SE8M7
E8M0 8-Bit-Zahl mit vorzeichenlosem Exponent
FP8 nach OCP-Spezifikation (OFP8): E4M3 oder E5M2
MX FP8 Microscaling-Formate (MX) SE5M2 oder SE4M3
MX FP6 SE3M2 oder SE2M3
MX FP4 SE2M1
MX INT8 Bruchformat

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)



Source link

Weiterlesen

Entwicklung & Code

Open VSX: Version 1.0 der Microsoft-Alternative von Eclipse erschienen


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Die Eclipse Foundation hat Open VSX in Version 1.0 veröffentlicht. Damit erreicht die Registry für Visual Studio Code Extensions einen stabilen Stand.

Weiterlesen nach der Anzeige

Open VSX ist eine Plattform zum Veröffentlichen und Herunterladen von Extensions und Werkzeugen, die kompatibel zu der VS-Code-Extensions-API sind. Einige Entwicklungsumgebungen und Tools können die Extensions integrieren, und manche Entwicklungsumgebungen bauen auf Forks von Visual Studio Code auf.

Das Projekt besteht aus einer Serveranwendung mit einer Datenbank für die Extensions sowie einer Webanwendung und einem Kommandozeilenwerkzeug zum Hoch- und Herunterladen der Erweiterungen.

Deutsche Wurzeln mit Open-Source-Basis

Das deutsche Start-up-Unternehmen TypeFox hatte Open VSX ursprünglich entwickelt und 2021 an die Eclipse Foundation übergeben. Mike Milinkovich, Geschäftsführer der Eclipse Foundation, wollte die Plattform als offene Alternative zum Visual Studio Marketplace betreiben, zumal dieser in den Nutzungsbedingen den Einsatz der Extensions auf Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server sowie nachfolgende Microsoft-Produkte beschränkt.

Die Eclipse Foundation entwickelt Open VSX als Open-Source-Projekt über ein GitHub-Repository. Seit Juni 2023 kümmert sich eine eigene Arbeitsgruppe um den Fortbestand. Im April 2026 startete die Eclipse Foundation eine Initiative, um Bugs und Schwachstellen in Open VSX aufzuspüren.

Stabilität und Security

Weiterlesen nach der Anzeige


Open VSX 1.0.0, celebration image

Open VSX 1.0.0, celebration image

(Bild: Eclipse Foundation)

Version 1.0 setzt vor allem auf Stabilität und Security: Das Release bringt unter anderem einen Read-Only-Modus und TLS-geschützte Redis-Verbindungen. Außerdem spricht der Blogbeitrag zur Veröffentlichung von Open VSX 1.0 von zusätzlichen Maßnahmen für eine verbesserte Sicherheit.

Plattformen, die Erweiterungen für Entwicklungswerkzeuge und Programmiersprachen anbieten, sind ein beliebtes Ziel für Supply-Chain-Attacken. Im Oktober 2025 traf die GlassWorm-Attacke neben Microsofts Marktplatz auch Open VSX. Damals reagierte die Eclipse Foundation zügig mit zusätzlichen Schutzmaßnahmen.

Weitere Details lassen sich der Ankündigung von Open VSX 1.0.0 im Eclipse-Blog entnehmen. Die Eclipse Foundation betreibt die öffentliche Open VSX Registry und bietet zudem eine verwaltete Plattform auf Open-VSX-Basis für Unternehmen und Organisationen als Open VSX Managed Registry an.


(rme)



Source link

Weiterlesen

Beliebt