Windmill – die am schnellsten selbst hostbare Open-Source-Workflow-Engine

• Windmill belegt per Benchmark, dass es im Vergleich zu anderen Workflow-Engines wie Airflow, Prefect und Temporal die am schnellsten selbst hostbare Open-Source-Workflow-Engine ist
• Windmill unterstützt verschiedene Programmiersprachen und bietet eine integrierte Entwicklungsumgebung, mit der sich Workflows in wenigen Minuten aufbauen und testen lassen – ohne komplexe SDKs oder Deployment-Prozesse
• Airflow/Prefect unterstützen nur eine Runtime (Python), während Windmill Python, Typescript, Go und Bash unterstützt und direkte SQL-Abfragen für BigQuery, Snowflake, Mysql und Postgresql bietet
• Im Vergleich zu Temporal, das auf das Management von Job-Queues spezialisiert ist, fungiert Windmill auch als langlebige Execution Engine einschließlich Event-Waiting-(Reactivity-)Funktionen

Der Unterschied zwischen Workflow-Engines und Job-Queues

• Job-Queues sind der Kern von Workflow-Engines, und viele Entwickler bauen ihre eigene Logik darauf auf und nutzen Job-Queues, ohne eine Workflow-Engine zu verwenden
• Es gibt bereits verschiedene Queue-Implementierungen wie SQS, Kafka, Redis with RMSQ und Orban
• Viele Entwickler bauen ihre Logik rund um Job-Queues auf und empfinden dadurch eine ähnliche Zufriedenheit wie mit einer Workflow-Engine – praktisch der Bau einer eigenen Workflow-Engine

Was ist eine „All-Inclusive“-Workflow-Engine?

• Eine Workflow-Engine koordiniert Workflows in verteilten Systemen, um Aufgaben unter Einhaltung von Abhängigkeitsbeschränkungen abzuschließen
• Die 5 wichtigsten Vorteile einer Workflow-Engine:
  • Ressourcenzuweisung: Cluster können optimal ausgelastet werden, indem alle Aufgaben verschiedenen Workern mit unterschiedlichen Ressourcen (CPU, Speicher, GPU) zugewiesen werden, sodass die gesamten Ressourcen eines Workers für einen Job genutzt werden können
  • Parallelisierung: Wenn sich aufgrund der Einschränkungen eines Workflows bestimmte Schritte parallel ausführen lassen (Branches, For-Loops), kann die Workflow-Engine diese Schritte nicht nur auf Threads, sondern auf mehrere physisch getrennte Worker dispatchen
  • Observability: Jede Aufgabe hat eine eindeutige ID und kann einzeln beobachtet werden, etwa durch Inspektion von Eingaben, Logs, Ausgaben und Status
  • Dauerhaftigkeit: Wenn eine Maschine aus unerwarteten Gründen stoppt oder Side Effects auftreten, muss der Workflow neu gestartet werden
    • Ein Workflow sollte bei unerwarteten Ereignissen so schnell wie möglich neu starten können; ein Weg dorthin ist Idempotenz, bei der dieselbe Aufgabe bei mehrfacher Ausführung den gleichen Effekt hat wie bei einmaliger Ausführung
    • Wenn Unsicherheit besteht, wird der gesamte Ablauf ohne zusätzliche Auswirkungen erneut abgespielt. Das wird üblicherweise mit Log-Dateien und SDKs umgesetzt, bei denen eine an Aufgaben angehängte eindeutige ID Teil des Logs ist, sodass Side Effects übersprungen werden können
    • Eine weitere Methode ist das Erzeugen transaktionaler Snapshots des Flow-Zustands, bei dem der Zustand nach jeder Aufgabe gespeichert wird. Für einen Neustart lädt man einfach den letzten Zustand und setzt die Ausführung von dort fort
    • Windmill verwendet Letzteres und geht davon aus, dass Idempotenz bei Bedarf im User Space implementiert werden kann
  • Reaktivität: Der Flow wird pausiert, bis er durch ein Event wie einen Webhook oder eine Freigabe wieder aufgenommen wird

Das Geheimnis hinter Windmills hoher Geschwindigkeit

• Windmill nutzt Postgresql und Rust, um durch ein einfaches Design und Optimierungen maximale Effizienz zu erreichen

Systemdesign und Queue

• Windmill liefert ein einzelnes in Rust kompiliertes Binary; Worker und Server sind mit Postgresql verbunden, aber nicht direkt miteinander
• Die Queue wird direkt in Postgresql implementiert, und Jobs können extern über die API ausgelöst werden

Zustand

• Workflow-Engines stellen Aufgaben als Finite-State-Machine (FSM) dar, während Windmill den gesamten Flow selbst als FSM behandelt

Datenübergabe

• Windmill bietet verschiedene Methoden zur Datenübergabe, darunter JavaScript-Ausdrücke, die gemeinsame Nutzung temporärer Ordner und S3-Integration

Worker-Effizienz

• Die Worker von Windmill verarbeiten jeweils nur eine Aufgabe gleichzeitig und führen Jobs ohne Container aus, um die Performance zu verbessern

Fazit

• Windmill ist eine Open-Source-, selbst hostbare serverlose Runtime und Plattform, die auf Postgresql und Rust basiert und durch einfaches Design und Optimierungen sehr hohe Geschwindigkeit bietet

Meinung von GN⁺

Der wichtigste Punkt dieses Artikels ist, dass Windmill verschiedene Programmiersprachen unterstützt und eine integrierte Entwicklungsumgebung bietet, mit der sich Workflows schnell aufbauen und testen lassen – ohne komplexe SDKs oder Deployment-Prozesse. Diese Eigenschaften sind für Softwareentwickler sehr nützlich, und Windmills hohe Performance und Effizienz können dabei helfen, bessere Produkte schneller auf den Markt zu bringen. Der Artikel ist für Entwickler interessant, insbesondere für diejenigen, die eine eigene Workflow-Engine bauen oder bestehende Engines optimieren möchten.

[xguru]

Windmill - Open Source für das Erstellen Python-basierter interner Unternehmens-Apps und für Automatisierungsplattformen

Im Mai letzten Jahres wurde es kurz vorgestellt, aber der Entwickler meinte, er sei noch nicht bereit für die Veröffentlichung, und sagte dann: „In 10 Minuten habe ich mein YC-Interview!“ .. und später schrieb er in einem Kommentar, dass er bei YC angenommen wurde.
Nach der YC-Zusage sind sie anderthalb Jahre durchgestartet und haben das Produkt nun offiziell gelauncht.

[GN⁺]

Hacker-News-Kommentare

• Die Entwickler von Windmill scheinen den Rat „Mach eine Sache gut“ genau ins Gegenteil verkehrt zu haben. Selbst auf Windmill.dev ist nicht klar, wofür die Software eigentlich gedacht ist. Es ist verwirrend, ob sie ein Konkurrent zu Retool, Airflow oder Temporal ist, ein No-Code-Workflow-Builder, ein Drag-and-Drop-UI-Builder, eine Online-IDE oder etwas mit unzähligen Integrationen.
• Ich frage mich, ob die Geschwindigkeit einer Workflow-Engine ab einem bestimmten Punkt überhaupt noch wichtig ist. Viele Workflows enthalten lang laufende Aufgaben, daher ist Multitenancy entscheidend, also die Fähigkeit, so viele Jobs zu unterstützen, wie die Nutzer wollen, während jeder einzelne so geplant und ausgeführt wird, als wäre er der einzige in der Workflow-Engine.
• Ich möchte Geschäftsprozesse aus Tabellen, persönlichen E-Mails und dem Gedächtnis von Managern in Webformulare, Uploads, automatisierte E-Mails und Dashboards überführen. Ich habe mir Airtable, Smartsheet, Budibase usw. angesehen, aber sie scheinen stärker auf Projektmanagement fokussiert zu sein und sind bei Kalender-Integration, E-Mail oder geplanten Skripten nicht zufriedenstellend. Ich kann programmieren, wenn es eine API für die Daten gibt oder nötig ist, und bevorzuge einen Low-Code-Ansatz, bei dem Manager mit einer Tabellenansicht einen Teil der UI-Arbeit übernehmen können und Programmierer die Integrationen erledigen.
• Es überrascht mich, dass Leute so viel Zeit und Mühe ins Schreiben stecken und dann nicht einmal einmal die Rechtschreibprüfung benutzen. Ich frage mich, ob es 2023 wirklich noch Menschen gibt, die Texteditoren verwenden, die standardmäßig keine Rechtschreibprüfung haben.
• Es ist verwirrend, sich Open Source zu nennen und gleichzeitig ein Limit von 10 SSO-Nutzern zu haben. Open Source erlaubt normalerweise Änderungen am Code, aber ich frage mich, wie dieses Limit von 10 Nutzern durchgesetzt wird. Als ich mir den Quellcode ansah, gab es dort Code zur Lizenzprüfung. Wenn es Open Source ist, könnte dann nicht jeder diesen Code entfernen? Wenn Änderungen nicht möglich sind, ist es eher „source-available“ als „Open Source“. Das Projekt sieht großartig aus, und ich würde es gern meinem Chef vorschlagen, aber ich weiß nicht, wie ich diesen Teil erklären soll.
• Ich verfolge Windmill seit dem HN-Launch und nutze es seit weniger als einem Jahr deutlich häufiger. Der Discord-Server ist sehr aktiv, und Ruben antwortet selbst am Wochenende innerhalb weniger Minuten und behebt Bugs.
• Ich würde das Windmill-System gern verwenden, zögere aber wegen der Lizenz. Der Großteil der Software steht unter AGPLv3, aber der Abschnitt zur kommerziellen Lizenz in der README deutet auf eine sehr weitreichende Auslegung der AGPL hin. Wenn man Funktionen über Windmill baut, müsste dann auch das eigene Produkt unter AGPLv3 stehen, was bedeuten würde, dass sogar ein bloßer Aufruf per API urheberrechtlich relevant sein könnte. Dadurch ist die Positionierung von Windmill als „vollständig Open Source“ technisch zwar nicht falsch, in der Praxis aber eher näher an „source-available“. Falls Windmill die Lizenz nicht so ausgelegt sehen möchte, sollte das klargestellt werden.
• Windmill ist großartig. Es lässt sich selbst hosten und scheint der Developer Experience (DX) treu zu bleiben. Ich musste es bei der Arbeit nicht verwenden, nutze es aber zu Hause, um kleine Web-Crawler und yt-dlp-Jobs auszuführen. Ein wirklich unterhaltsames Tool.
• Ich bin wegen der Lizenz verwirrt.
• Ich habe noch keinen Weg gefunden, die Balance zu finden zwischen dem Speichern von Code in einer Datenbank und dem Bearbeiten über eine Web-IDE einerseits und dem Einchecken von Code in Git und Änderungen nur über normale Entwicklungs- und Peer-Review-Prozesse andererseits. Windmill speichert Code hauptsächlich in der Datenbank, stellt aber APIs bereit, um mit Git-Repositories zu synchronisieren. Ich frage mich, ob es einen Mechanismus gibt, mit dem sich Regeln erzwingen lassen, sodass bestimmte Skripte/Funktionen/Secrets nur auf Workflows beschränkt sind, die aus dem angegebenen Repository stammen.