Maestro: Netflix’ Workflow-Orchestrator

 (netflixtechblog.com)
4 Punkte von GN⁺ 2024-07-24 | 1 Kommentare | Auf WhatsApp teilen
  • Netflix hat den horizontal skalierbaren Orchestrator Maestro für groß angelegte Data/ML-Workflows als Open Source veröffentlicht und intern Hunderttausende Workflows mit minimalen Unterbrechungen migriert und in Betrieb genommen
  • Anders als DAG-zentrierte Orchestratoren verarbeitet Maestro sowohl azyklische als auch zyklische Workflows und bietet foreach-Schleifen, Subworkflows und bedingte Verzweigungen als Patterns auf Engine-Ebene
  • Im vergangenen Jahr ist die Zahl der ausgeführten Jobs um 87,5 % gestiegen; derzeit werden im Tagesdurchschnitt Tausende Workflow-Instanzen und rund 500.000 Jobs ausgeführt, an stark ausgelasteten Tagen werden etwa 2 Millionen Jobs abgeschlossen
  • Auf JSON-basierten Definitionen kombiniert Maestro Ausführungsstrategien, Parameter, SEL-Ausdrücke, Signale, Breakpoints, Timelines, Retry-Richtlinien und Rollups, um operative Kontrolle und Debugging zu unterstützen
  • In Umgebungen wie bei Netflix, in denen Datentabellen in einem einzigen Data Warehouse zusammengeführt sind, führen auf mehrere Cluster verteilte Workflows zu hohem Koordinationsaufwand und schlechterer User Experience; deshalb ist eine Struktur wichtig, in der ein einziger Orchestrator den gesamten Ablauf übernimmt

Veröffentlichung von Maestro und Betriebsumfang bei Netflix

  • Netflix hat den Maestro-Quellcode über das Maestro GitHub repository veröffentlicht
  • Maestro ist ein horizontal skalierbarer Workflow-Orchestrator zur Verwaltung groß angelegter Data/ML-Workflows wie Datenpipelines und Trainingspipelines für Machine-Learning-Modelle
  • Er verwaltet den gesamten Lebenszyklus eines Workflows vom Start bis zum Ende und übernimmt Retries, Queuing sowie die Verteilung von Jobs an Compute Engines
  • Nutzer können ihre Business-Logik in verschiedenen Formaten paketieren, etwa als Docker-Image, Notebook, bash-Skript, SQL oder Python
  • Nach der früheren Vorstellung hat Netflix Hunderttausende Workflows zu Maestro migriert und dabei Unterbrechungen für Nutzer minimiert
  • Aktueller Betriebsumfang:
    • In den vergangenen 12 Monaten ist die Zahl der ausgeführten Jobs um 87,5 % gestiegen
    • Im Tagesdurchschnitt werden Tausende Workflow-Instanzen ausgeführt
    • Im Tagesdurchschnitt werden rund 500.000 Jobs ausgeführt
    • An stark ausgelasteten Tagen werden etwa 2 Millionen Jobs abgeschlossen

Skalierbarkeit und Vielfalt mit einem einzigen Orchestrator unterstützen

  • Maestro ist ein vollständig verwalteter Orchestrator, der intern bei Netflix Tausenden Endnutzern, Anwendungen und Services Workflow-as-a-Service bereitstellt
  • Er unterstützt ETL-Pipelines, ML-Workflows, AB-Test-Pipelines und Pipelines zur Datenbewegung zwischen verschiedenen Storage-Systemen
  • Die horizontal skalierbare Architektur ist darauf ausgelegt, sowohl eine große Zahl von Workflows als auch eine große Zahl von Jobs innerhalb eines einzelnen Workflows zu verarbeiten
  • Da Workflows bei Netflix eng miteinander verknüpft sind, wären bei einer Aufteilung in kleine Gruppen und Verwaltung über mehrere Cluster zusätzliche Koordinationsmechanismen nötig, und die User Experience würde leiden
  • Da sich die Datentabellen in einem einzigen Data Warehouse befinden, lautet die Einschätzung, dass ein einziger Orchestrator alle Workflows verarbeiten sollte, die darauf zugreifen

Modell zur Workflow-Definition

  • Workflow-Definitionen in Maestro werden im JSON-Format geschrieben
  • Die Orchestrierungsdefinition setzt sich aus nutzerbereitgestellten Feldern und von Maestro verwalteten Feldern zusammen; ein Beispiel findet sich im Maestro repository wiki
  • Eine Workflow-Definition ist grob in zwei Bereiche unterteilt
    • properties: enthält Informationen zu Autor und Owner sowie Ausführungseinstellungen
    • versioned workflow: enthält Workflow-Metadaten und die Graph-Definition
  • Die properties bewahren auch bei Änderungen der Workflow-Version zentrale Attribute wie Autor- und Owner-Informationen, Ausführungsstrategie und Concurrency-Einstellungen
  • Wenn sich die Ownership ändert, kann der neue Owner die Ownership des bestehenden Workflows übernehmen, ohne eine neue Workflow-Version anzulegen
  • Der versioned workflow enthält eine eindeutige Kennung, Name, Beschreibung, Tags, Timeout-Einstellungen sowie die Criticality-Level low, medium und high zur Priorisierung
  • Änderungen am Workflow erzeugen eine neue Version; standardmäßig wird die aktive oder die neueste Version verwendet
  • Ein Workflow besteht aus steps, den Knoten des vom Nutzer definierten Graphen
    • Ein step kann einen Job, einen anderen Workflow über einen subworkflow step oder eine Schleife über einen foreach step darstellen
    • Ein step enthält unter anderem eine eindeutige Kennung, den step-Typ, Tags, Eingabe- und Ausgabeparameter, Abhängigkeiten, Retry-Richtlinien, Fehlermodus und step-Ausgaben
    • Unterstützt werden Retry-Richtlinien, die je nach Fehlertyp konfigurierbar sind

Run Strategy zur Steuerung der Ausführungsreihenfolge

  • Maestro entscheidet anhand vordefinierter run strategies, ob eine neue Workflow-Instanz ausgeführt wird

  • Sequential Run Strategy

    • Dies ist die Standardstrategie; sie führt Instanzen in FIFO-Reihenfolge jeweils einzeln aus
    • Unabhängig davon, ob der vorherige Lauf erfolgreich war, startet die nächste Instanz in der Queue, sobald eine Instanz einen Endzustand wie Erfolg oder Fehler erreicht

  • Strict Sequential Run Strategy

    • Führt Instanzen in der Reihenfolge aus, in der sie getriggert wurden, blockiert die Ausführung aber, wenn in der Historie der vorherigen Instanz ein blocking error vorliegt
    • Neue Instanzen bleiben in der Queue, bis die fehlgeschlagene Instanz manuell neu gestartet oder per unblock freigegeben wird
    • Nützlich für Workflows mit geringer Zeitsensitivität, aber hoher geschäftlicher Bedeutung

  • First-only Run Strategy

    • Hält keine neuen Instanzen in der Queue, solange der laufende Workflow noch nicht abgeschlossen ist
    • Wenn bereits eine Instanz läuft, werden neu in die Queue eingehende Instanzen entfernt, wodurch Queuing faktisch deaktiviert wird
    • Hilft, Idempotenzprobleme zu vermeiden, weil keine neuen Instanzen aufgestaut werden

  • Last-only Run Strategy

    • Stellt sicher, dass immer die zuletzt getriggerte Instanz ausgeführt wird
    • Wenn bereits eine Instanz läuft, wird sie abgebrochen und die neu getriggerte Instanz ausgeführt
    • Nützlich, wenn nur die neuesten Daten benötigt werden, etwa bei Workflows, die jedes Mal den aktuellen Snapshot einer gesamten Tabelle verarbeiten

  • Parallel with Concurrency Limit Run Strategy

    • Führt mehrere Instanzen parallel innerhalb eines vordefinierten Concurrency-Limits aus
    • Ausführungen können fan-out und verteilt werden, um große Datenmengen innerhalb einer begrenzten Zeit zu verarbeiten
    • Ein typischer Anwendungsfall ist das Backfill älterer Daten

Parameter und SEL-Ausdrücke

  • In Maestro werden Parameter verwendet, um Ausführungslogik zu steuern, Zustand zwischen Workflow und steps zu teilen sowie Zustand zwischen Upstream- und Downstream-steps zu teilen
  • Maestro unterstützt dynamische Parameter mit Code Injection, sodass sich komplexe parametrisierte Workflows definieren lassen
  • Code Injection kann Sicherheits- und Stabilitätsrisiken erzeugen
    • Wenn ein Nutzer eine Endlosschleife schreibt, die einem Array fortlaufend Einträge hinzufügt, kann der Server wegen OOM ausfallen
    • Wird der injizierte Code in die Business-Logik verschoben, steigt die Belastung für Nutzer, und Workflow-Definition und Business-Logik werden stark gekoppelt
  • Um dies abzumildern, hat Netflix mit SEL (Simple, Secure, and Safe Expression Language) eine eigene Expression Language entwickelt
  • SEL folgt Grammatik und Syntax der Java Language Specifications, unterstützt aber eine auf Maestro-Anwendungsfälle zugeschnittene Teilmenge
  • SEL unterstützt Datentypen der Maestro-Parametertypen, Fehlerauslösung, Datum-/Zeitverarbeitung und vordefinierte Utility-Methoden
  • Zur Stabilität enthält SEL Runtime-Prüfungen wie Begrenzungen für Schleifeniterationen, Prüfungen der Array-Größe und Limits für die Speichergröße von Objekten
  • Die SEL-Dokumentation findet sich in der Maestro GitHub documentation

Ausgabeparameter und parametrisierte Workflows

  • Über callable step execution kann Maestro Ergebnisse von Nutzerausführungen als Ausgabeparameter an das System zurückgeben
  • Ausgabedaten werden über die Maestro REST API übermittelt; die step-Runtime greift nicht direkt auf die Maestro-Datenbank zu
  • Statische Workflows sind einfach, können bei kleinen Unterschieden aber erfordern, denselben Workflow mehrfach zu duplizieren; ohne Parameter können Workflow und Jobs keinen Zustand teilen
  • Vollständig dynamische Workflows sind schwer zu verwalten und zu unterstützen, außerdem erschweren sie Debugging, Troubleshooting und Wiederverwendung
  • Parametrisierte Workflows werden zur Laufzeit auf Basis nutzerdefinierter Parameter stepweise initialisiert und bieten dadurch sowohl Flexibilität bei der Steuerung zur Ausführungszeit als auch Verwaltbarkeit
  • Die Parameterunterstützung von Maestro ermöglicht die Erstellung komplexer parametrisierter Workflows, etwa für Backfill-Datenpipelines

Workflow-Ausführungsmuster auf Engine-Ebene

  • Maestro unterstützt gängige Dataflow- und Workflow-Muster direkt in der Engine
  • Durch die direkte Unterstützung in der Engine werden Musteroptimierung und eine konsistente Implementierungsweise möglich

  • Foreach

    • Das foreach-Muster wurde ursprünglich als eigener Step innerhalb der Workflow-Definition modelliert
    • Jede Iteration einer foreach-Schleife wird intern als separate Workflow-Instanz behandelt
    • Die Ausführung der Steps im foreach-Definitionsblock, also die Ausführung des Sub-Graphs, wird an eine separate Workflow-Instanz delegiert
    • Der foreach-Step überwacht und sammelt den Status der Workflow-Instanzen, die jeweils für eine Iteration zuständig sind
    • Wird häufig für Daten-Backfills oder das Tuning von Machine-Learning-Modellen verwendet, bei denen dieselbe Aufgabe mit unterschiedlichen Parametern pro Iteration ausgeführt wird
    • Nutzer müssen nicht Hunderttausende Iterationen direkt in die Workflow-Definition schreiben, und auch die Notwendigkeit, bei einer Änderung des foreach-Bereichs einen neuen Workflow zu erstellen, wird reduziert

  • Conditional Branch

    • Eine bedingte Verzweigung sorgt dafür, dass nachfolgende Steps nur ausgeführt werden, wenn eine bestimmte Bedingung eines Upstream-Steps erfüllt ist
    • Bedingungen werden als SEL-Ausdrücke definiert und zur Laufzeit ausgewertet
    • So lässt sich ein Ablauf erstellen, der bei einem fehlgeschlagenen Audit-Check-Step Wiederherstellungsarbeiten ausführt und anschließend die Aufgabe erneut startet

  • Subworkflow

    • Ein Subworkflow ermöglicht es, dass ein Workflow-Step einen anderen Workflow ausführt, sodass gemeinsame Funktionen in mehreren Workflows geteilt werden können
    • Workflow-Graphen können in der Form „workflow as a function“ aufgebaut werden
    • Bei Netflix wurden auch komplexe Workflows beobachtet, die aus Hunderten von Subworkflows bestehen und Daten aus Hunderten von Tabellen verarbeiten, indem sie Subworkflows verschiedener Teams kombinieren
    • foreach, bedingte Verzweigungen und Subworkflows können gemeinsam kombiniert werden
    • Eine Menge von Subworkflows kann in einer Schleife verarbeitet werden
    • Verschachtelte foreach-Schleifen können ausgeführt werden
    • Durch die gemeinsame Nutzung von bedingten Verzweigungen und Subworkflows lassen sich automatische Recovery-Workflows erstellen, die Fehler behandeln und Aufgaben automatisch erneut versuchen

Step Runtime und Parameter-Merging

  • Maestro verwendet zur Beschreibung von Aufgaben zum Ausführungszeitpunkt eine Step Runtime
  • Das Step-Runtime-Interface definiert zwei Arten von Informationen
    • Eine Reihe grundlegender APIs, die das Ausführungsverhalten einer Step-Instanz steuern
    • Eine einfache Datenstruktur, die den Laufzeitstatus des Steps und das Ausführungsergebnis nachverfolgt
  • Maestro stellt Implementierungen wie foreach step runtime und subworkflow step runtime bereit
  • Jede Implementierung definiert ihre eigene Logik für die Aktionen start, execute und terminate
  • Der Runtime-Status wird verwendet, um den nächsten Zustandsübergang eines Steps zu bestimmen und zu beurteilen, ob ein Fehler oder eine Beendigung vorliegt
  • Das Ausführungsergebnis enthält Step-Artefakte und die Timeline der Step-Ausführungshistorie und kann von nachfolgenden Steps abgerufen werden

  • Step Parameter Merging

    • Maestro unterstützt die Injektion von Runtime-Parametern und Tags, um das Verhalten von Steps dynamisch zu steuern
    • Die Step-Parameter-Map ist zunächst leer und wird in der folgenden Reihenfolge zusammengeführt
    • Default General Parameters: Grundparameter aller Steps wie workflow_instance_id, step_instance_uuid, step_attempt_id, step_id; sie werden als intern reservierte Werte von Maestro verwendet und können nicht von Nutzern übergeben werden
    • Injected Parameters: Parameter, die dynamisch von der Step Runtime erzeugt werden und je nach Schema des Step-Typs variieren können
    • Default Typed Parameters: Standardparameter, die sich auf einen bestimmten Step-Typ beziehen, etwa loop_params und loop_index bei einem foreach-Step
    • Workflow and Step Info Parameters: Identifikationsinformationen zu Step und Workflow, etwa workflow_id
    • Undefined New Parameters: Step-Parameter, die Nutzer beim Start oder Neustart einer Workflow-Instanz neu angeben
    • Step Definition Parameters: Step-Parameter, die Nutzer zum Definitionszeitpunkt geschrieben haben
    • Run and Restart Parameters: Werte, die Nutzer beim Start oder Neustart bereitstellen, um bestehende Definitionsparameter zu überschreiben; sie werden ganz zuletzt zusammengeführt

Step Dependencies und Signals

  • Steps im Maestro-Workflow-Graphen können Ausführungsabhängigkeiten über step dependency ausdrücken
  • Eine Step Dependency gibt datenbezogene Bedingungen an, die für die Ausführung eines Steps erforderlich sind
  • Bedingungen werden in der Regel auf Basis von Signals definiert
  • Ein Signal ist eine Nachricht, die Informationen wie Parameterwerte enthält und über Step-Ausgaben oder externe Systeme wie SNS oder Kafka veröffentlicht werden kann
  • Signals werden sowohl für Trigger-Muster als auch für Signal-Dependency-Muster in Publisher-Subscriber-Form verwendet
  • Ein einzelner Step kann ein Output-Signal veröffentlichen und damit die Ausführung mehrerer Steps freigeben, die von diesem Signal abhängen
  • Eine Signal Definition enthält eine Liste gemappter Parameter, und Maestro kann signal matching nur mit einem Teil der Felder durchführen
  • Maestro unterstützt für Signal-Parameterwerte signal operators wie < und >
  • Netflix hat auf dem Signal-Konzept mehrere Abstraktionen aufgebaut
    • Wenn ein ETL-Workflow eine Tabelle aktualisiert und ein Signal sendet, können Downstream-Workflow-Steps ausgeführt werden, die von diesen Daten abhängen
    • signal lineage ermöglicht es, frühere Signal-Instanzen sowie die Workflow-Steps zu durchsuchen, die das jeweilige Signal veröffentlicht oder konsumiert haben
    • Signal Trigger garantieren exactly-once execution für Workflows, die ein einzelnes oder ein gejointes Set von Signals abonnieren
  • Da Workflows oder Steps nur ausgeführt werden, wenn die angegebenen Signal-Bedingungen erfüllt sind, lassen sich Ressourcen sparen

Debugging und Ausführungstransparenz

  • Breakpoint

    • Maestro kann Breakpoints für Workflow-Steps setzen
    • Wenn eine Workflow-Instanz einen Step mit gesetztem Breakpoint erreicht, wechselt dieser Step in den Status paused
    • Der Fortschritt des Workflow-Graphen stoppt, bis ein Nutzer ihn manuell fortsetzt
    • Wenn mehrere Instanzen desselben Workflow-Steps an einem Breakpoint angehalten wurden, wirkt sich das Fortsetzen einer Instanz nur auf diese Instanz aus; die übrigen bleiben im Status paused
    • Wird der Breakpoint gelöscht, werden alle angehaltenen Step-Instanzen fortgesetzt
    • Das ist nützlich, um während der frühen Workflow-Entwicklung die Step-Ausführung und Ausgabedaten zu prüfen
    • Wird im foreach-Muster ein Breakpoint auf einen einzelnen Step gesetzt, halten alle Iterationen an diesem Step an und können debuggt werden
    • Es kann auch zur Unterstützung menschlicher Eingriffe während der Ausführung oder zur Änderung des Step-Status zur Laufzeit verwendet werden

  • Timeline

    • Maestro enthält eine Timeline der Step-Ausführung und zeichnet wichtige Ereignisse wie Änderungen der State Machine und deren Gründe auf
    • Beispielereignisse umfassen Übergänge wie Created und Evaluating params
    • Implementierte Step Runtimes können Timeline-Events hinzufügen, um Endnutzern Ausführungsinformationen anzuzeigen
    • Ein Timeline-Beispiel findet sich in sample-step-instance-failed.json

Wiederholungen, Aggregated View, Rollup

  • Retry Policies

    • Maestro unterstützt Retry Policies für Steps, die in einem fehlgeschlagenen Endzustand landen.
    • Nutzer können die Anzahl der Wiederholungen, die Verzögerung zwischen Wiederholungen, Wiederholungen in festen Intervallen und Strategien mit Exponential Backoff konfigurieren.
    • Wiederholungen werden in zwei Typen unterteilt.
    • platform retry: Reaktion auf Fehler auf Plattformebene, die unabhängig von der Nutzerlogik sind.
    • user retry: Wiederholung auf Basis nutzerdefinierter Bedingungen.
    • Jeder Typ kann eine eigene Retry Policy haben.
    • Automatische Wiederholungen sind nützlich, um temporäre Fehler zu behandeln, die ohne Eingriff des Nutzers behoben werden können.
    • Für nicht idempotente Steps kann die Anzahl der Wiederholungen auf 0 gesetzt werden, um Retries zu vermeiden.

  • Aggregated View

    • Da eine einzelne Workflow Instance mehrere Runs haben kann, müssen Nutzer den aggregierten Status aller Steps sehen können.
    • Die Aggregated View wird berechnet, indem die grundlegende Aggregated View mit dem Step-Status des aktuellen Runs zusammengeführt wird.
    • Wenn beispielsweise im ersten Lauf step1 und step2 erfolgreich sind, step3 fehlschlägt und step4 sowie step5 noch nicht gestartet wurden, beginnt ein Neustart bei step3; step1 und step2 können wegen ihres zuvor erfolgreichen Status übersprungen werden.
    • Wenn alle Steps erfolgreich sind, zeigt die Aggregated View den Run-Status aller Steps an.

  • Rollup

    • Ein Rollup bietet eine übergeordnete Zusammenfassung einer Workflow Instance und zeigt den Status jedes Steps sowie die Anzahl der Steps je Status an.
    • Es klappt die Steps der aktuellen Instance sowie verschachtelter Non-Inline-Workflows wie subworkflow und foreach auf und aggregiert sie.
    • Wenn ein erfolgreicher Workflow drei Steps hat und einer davon ein Subworkflow mit fünf Steps ist, zeigt das Rollup die Anzahl erfolgreicher Steps als 7 an.
    • Im Rollup werden nur Leaf-Steps aggregiert; andere Steps werden als Pointer auf konkrete Workflows behandelt.
    • Auch Referenzen auf nicht erfolgreiche Steps bleiben erhalten, sodass man zu problematischen Steps in verschachtelten Workflows navigieren kann.
    • Das aggregierte Rollup wird berechnet, indem die Runtime Data des aktuellen Runs mit dem Base Rollup kombiniert wird.
    • Das Rollup eines Subworkflow-Steps spiegelt unverändert das Rollup der Subworkflow Instance wider.
    • Das Rollup eines foreach-Steps kombiniert das Base Rollup ohne die für den Neustart vorgesehenen Iterationen aus der vorherigen Ausführung mit den Rollups der aktuell laufenden Iterationen.
    • Aufgrund dieses Prozesses ist das Rollup-Modell eventually consistent; wenn verschachtelte foreach- und Subworkflow-Strukturen über mehrere Ebenen reichen, kann die Berechnung komplex und rekursiv werden.

Event-Veröffentlichung und externe Integration

  • Wenn sich Workflow-Definitionen, Workflow Instances oder Step Instances ändern, erzeugt Maestro Events, verarbeitet sie intern und veröffentlicht sie anschließend an externe Systeme.
  • Maestro-Events werden in interne und externe Events unterteilt.
    • internal event: Verfolgt interne Änderungen im Lebenszyklus von Workflows, Workflow Instances und Step Instances und wird in eine interne Queue veröffentlicht.
    • external event: Enthält Informationen zu Maestro-Statusänderungen, die von Downstream-Services konsumiert werden sollen, und wird an externe Queues wie SNS oder Kafka gesendet.
  • Der Maestro Event Processor abonniert die interne Queue, holt internal events ab, verarbeitet sie je nach Event-Typ und wandelt sie bei Bedarf in external events um.
  • In der letzten Stufe veröffentlicht der Notification Publisher externe Events, damit Downstream-Services sie konsumieren können.
  • Downstream-Services sind größtenteils eventbasiert, und Maestro Events enthalten die Nachrichten, die nötig sind, um verschiedene Änderungen in Maestro zu erkennen.
  • Die Änderungstypen lassen sich grob in zwei Kategorien einteilen.
    • workflow change: Workflow-weite Aktionen wie Änderungen an Workflow-Definitionen oder Properties.
    • instance status change: Statusübergänge einer Workflow Instance oder Step Instance.

Erste Schritte

  • Der Maestro-Code ist unter github.com/Netflix/maestro verfügbar.
  • Fragen, Meinungen und Kommentare können als GitHub issue im Maestro-Repository hinterlassen werden.
  • Netflix hofft, dass die von Maestro gebotene Skalierbarkeit und Benutzerfreundlichkeit auch die Entwicklung von Workflows außerhalb von Netflix beschleunigen kann.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-24
Hacker-News-Kommentare

  • Früher war ich von solchen Tech-Blogs von Unternehmen und ihren internen proprietären Systemen beeindruckt, heute nicht mehr. Denn Code ist Schulden.
    Statt cron/Celery/Airflow neu zu bauen, würde ich lieber etablierte Open-Source-Lösungen mit langer Wartungs- und Verbesserungshistorie nutzen. Irgendjemand muss sie schließlich warten, Bugs beheben und Features hinzufügen. Eine Ausnahme wäre natürlich, wenn damit Beförderungen und Gehalts-/RSU-Erhöhungen verbunden sind.
    Man sollte erkennen, dass Code, der nicht zum Kerngeschäft gehört und dem Unternehmen Geld einbringt, die Aufmerksamkeit ablenkt und Ressourcen frisst.

    • Ich denke, genau deshalb gibt es diesen Blogbeitrag. Sie wollen diese Software Open Source machen, damit sie nicht mehr alles ausschließlich intern warten müssen.
      Sie haben sie gebaut, weil es einen Bedarf gab, den bestehende etablierte Open-Source-Lösungen nicht abgedeckt haben, und sind nun dabei, sie wieder in etablierte Open Source zu verwandeln, um sie weiter zu nutzen und die Wartungslast zu teilen. Wie sollten solche Tools denn von Anfang an entstehen? Irgendjemand muss sie bauen.
    • Die Sichtweise „Code ist Schulden“ ist zu extrem und eng mit einer Denkweise verbunden, die alles auf der Welt im MBA-Stil minimieren/maximieren will.
      Zum Glück gibt es Menschen, die keine Angst davor haben, neue Systeme zu bauen und neue Ideen voranzutreiben. Auch aus Unternehmenssicht kommt man mit durchschnittlichen, risikoscheuen Lösungen nur bis zu einem gewissen Punkt. Die profitabelsten Unternehmen sind technisch ziemlich mutig.
      Code ist keine Schuld, sondern das, was die Zahnräder eines Unternehmens antreibt.
    • Auch etablierte Open-Source-Projekte sind oft das Ergebnis davon, dass große Unternehmen interne Tools veröffentlicht haben. Airflow, das du selbst erwähnt hast, ist ein gutes Beispiel, und in diesem Bereich gilt das auch für Temporal. Irgendjemand muss „dumm genug“ sein, etwas Neues zu bauen.
    • Die Formulierung „lange Wartungs- und Verbesserungshistorie“ trägt eine enorme Annahme mit sich herum.
      Ich frage mich, ob du auch planst, selbst zur Community beizutragen. Bauen oder kaufen ist immer eine wichtige Diskussion, aber anzunehmen, dass beim „Kaufen“ Wartungs- und Zuverlässigkeitskosten exakt 0 sind, wirkt naiv.
    • Wichtig ist die Einschränkung „nicht zum Kerngeschäft des Unternehmens“. Für ein erfahrenes Team in einem performancekritischen Bereich ist der Wendepunkt, an dem externer Code zu niedrigqualitativen/schlecht kontrollierbaren Schulden wird, nicht besonders weit entfernt.

  • Ich frage mich, wie viele Iterationen noch nötig sind, bis Engineers mit Workflow-Lösungen zufrieden sind. Netflix hatte schon vor Maestro mehrere Lösungen wie Metaflow, Uber hat ebenfalls mehrere Lösungen gebaut, und bei Amazon gab es intern mindestens ein Dutzend Workflow-Engines.
    Interessant ist, dass so viele Einzelpersonen in verschiedenen Unternehmen Workflow-Engines bauen wollen. Das soll niemanden oder Netflix herabsetzen, sondern ist eher eine Beobachtung, über die man locker diskutieren kann.

    • Das Problem ist, dass Workflow-Orchestrierung ein sehr breites Problemfeld ist. Unternehmen müssen viele unterschiedliche Probleme lösen, sodass jede Lösung zu einem riesigen Produkt mit vielen entsprechenden Features wird und mit dem Wachstum leicht zu einem großen Monolithen mit starker Philosophie wird. Deshalb ist fast niemand zufrieden.
      Tatsächlich gibt es fünf zentrale Anliegen: Ressourcen-Scheduling, Dependency Resolution, eine API/DSL zum Erstellen von Jobs und Workflows, cron-artige geplante Ausführung und Domain Awareness, die bei ETL- oder ML/AI-Workflows Domäneninformationen sichtbar macht.
      Es gibt keine einzelne Lösung, die all das sauber erledigt. Deshalb bauen Unternehmen selbst etwas oder umgehen bestehende Standardprodukte, um deren Schwächen auszugleichen, und der Kreislauf an Unzufriedenheit geht weiter.
      Ich glaube nicht, dass das ein Problem ist, das ein Startup als „die Lösung“ bauen kann. Es sollte durch ein Open-Source-Ökosystem aus guten, steckbaren modularen Komponenten gelöst werden.
    • Metaflow läuft auf Maestro auf; keines von beiden ersetzt das andere.
      Unter https://netflixtechblog.com/orchestrating-data-ml-workflows-... heißt es: „Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.“
      Der Orchestrierungsabschnitt dieses Artikels (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) erklärt ausführlich, wie Metaflow mit Maestro, Airflow, Argo Workflows und Step Functions zusammenspielt.
    • Wir haben eine eigene Workflow-Engine gebaut, aber sie war so fehleranfällig und so unflexibel, dass sie beinahe ein eigentlich nicht damit zusammenhängendes Projekt ruiniert hätte.
      Ich bekomme langsam den Eindruck, dass Workflow-Engines bis zu einem gewissen Grad ein Design Smell sein können. Sobald man etwas Wiederverwendbares baut, sieht es verlockend so aus, als könne man es für unzählige Workflows einsetzen, aber außer der Tatsache, dass mehr als ein asynchroner Schritt nötig ist, haben die Workflows kaum etwas gemeinsam.
      Die Daten sind unterschiedlich, die APIs sind unterschiedlich, und auch das Feedback, das man von Nutzern oder anderen Systemen braucht, um fortzufahren, ist unterschiedlich.
    • Wahrscheinlich liegt es daran, dass man noch keine Workflow-Engine/keinen Orchestrator gefunden hat, die/der vielfältige Aufgaben bewältigt und zugleich leicht zu verstehen und zu betreiben ist.
      Es ist wirklich einfach, eine maßgeschneiderte Workflow-Engine zu bauen, die für einen bestimmten Use Case optimiert ist. Ich denke, der Grund, warum es noch keine Konvergenz gibt, ist, dass ein solches Tool noch nicht gebaut wurde.
      Wenn man sich Tools ansieht, die ihre jeweiligen Bereiche zuletzt schnell dominiert haben: Terraform hat IaC gelöst, Kubernetes die schwierigen Probleme des verteilten Rechnens. Beide sind sehr komplex, lösen aber schwierige Probleme. Allgemeine Workflow-Engines hingegen sind komplex zu verstehen, schwer zu betreiben und liefern eine eher unklare Erfahrung, sodass viele es gar nicht erst versuchen.
    • Naming, Cache-Invalidierung und Workflow-Engines? :)
      https://github.com/meirwah/awesome-workflow-engines

  • Ich bin der Gründer von https://windmill.dev; Windmill hat viele Gemeinsamkeiten mit Maestro.
    Die Beschreibung von Maestro als „horizontal skalierbarer, universeller Workflow-Orchestrator zur Verwaltung von Workflows, Datenpipelines und ML-Modell-Trainingspipelines in großem Maßstab“ würde auch mit Windmill anstelle von Maestro genau passen. Was sie Rollup nennen, nennen wir openflow state.
    Die wichtigsten Unterschiede: Windmill ist in Rust statt Java geschrieben, und Maestro nutzt CockroachDB für die Zustandsverwaltung, während wir PostgreSQL sowohl für State als auch für Queues verwenden. Ich verstehe aber, warum sie CockroachDB nutzen. Auch Windmill musste für sehr große Kundeninstanzen einen eigenen Sharding-Algorithmus für horizontale Skalierung entwickeln.
    Maestro steht unter Apache 2.0, Windmill unter der weniger freundlichen AGPL. Mit der Unterstützung von Netflix ist die Finanzierung praktisch unbegrenzt, während wir zwar profitabel, aber ein deutlich kleineres Unternehmen sind.
    Maestro hat noch keine ausreichende Dokumentation für Self-Hosting auf Basis von Kubernetes oder docker-compose, und es gibt keine UI zum Erstellen von Dingen, oder sie ist in der Dokumentation noch nicht wirklich sichtbar. Insgesamt ist es aber ziemlich cool, dass es als Open Source veröffentlicht wurde, und wir werden es weiter beobachten und so bald wie möglich benchmarken.

    • Wenn man Windmill in Betracht zieht, sollte man sich zuerst das hier ansehen: https://www.windmill.dev/docs/advanced/local_development
      Ich verstehe nicht, warum man sich mit Windmill „synchronisieren“ muss, warum in Windmill eine IDE steckt und warum das so kompliziert ist. Es wirkt, als ob von Anfang an auf Lock-in abgezielt wurde, noch bevor ein gutes Produkt gebaut oder Product-Market-Fit gefunden wurde.
    • Der Vergleich ist gut, aber selbst wenn Maestro unter der Apache-Lizenz steht, ist es nicht besonders gut, wenn es von CockroachDB abhängt, denn CockroachDB selbst ist nicht Open Source.
      Ich halte eine AGPL-Codebasis für besser als eine nicht quelloffene Abhängigkeit. Natürlich kann mit der Zeit jemand Unterstützung für eine alternative Datenbank hinzufügen.

  • Ich bin etwas verwirrt darüber, was hier vor sich geht. Dieses Projekt scheint Netflix/conductor [0] zu verwenden. Wenn man aber in dieses Repository schaut, ist es archiviert und enthält die Nachricht, dass es durch eine interne, nicht quelloffene Netflix-Version und einen nicht näher genannten Community-Fork ersetzt wurde. Vermutlich ist Orkes Conductor [1] gemeint.
    Dieses Projekt scheint jedoch nicht Orkes Conductor zu verwenden, sondern die eingestellte Netflix-Version com.netflix.conductor:conductor-core:2.31.5 [2]. Und das ist auch noch eine alte Version.
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

  • Ich frage mich, ob jemand ActiveBatch ausprobiert hat. Für mich ist es die beste Software, von der ich mir ein gleichwertiges Produkt für Nicht-Unternehmenskunden wünschen würde.
    Ich habe immer wieder versucht, andere „Konkurrenzprodukte“ zu nutzen, aber bei ActiveBatch hängt man einfach eine schlichte MS-SQL-DB an, installiert die Windows-GUI und Ausführungsagenten, und mit ein paar Klicks hat man eine robuste, GUI-basierte Automatisierungsumgebung. Man muss keinen Code schreiben, kann aber, wenn man möchte, Code in jeder beliebigen Sprache verwenden.
    Airflow kann mächtig sein, aber es versteckt sich hinter einer Komplexitätsbarriere, sodass die meisten Menschen seine eigentlichen Fähigkeiten nie sehen, wie groß sie auch sein mögen. Dasselbe gilt für andere „Open-Source“-Konkurrenten.
    Ich verstehe nicht, warum niemand ein robustes DB-basiertes, GUI-first System bauen kann. Ich habe auch Onlinedienste ausprobiert, aber sie sind nicht vergleichbar. Vielleicht scheitern einfachere kostenpflichtige Produkte an den Kosten für die Pflege von Erweiterungen.
    Es ist wirklich schade, dass ActiveBatch hinter einem albernen Enterprise-Vertriebsmodell eingesperrt ist. Das verhindert, dass diese großartige Software eine breitere Community erreicht. Es wirkt wie ein verborgenes Geheimnis.

  • Mein Rat: Man sollte sich besser nicht auf Tools verlassen, die Netflix als Open Source veröffentlicht hat. Es gibt eine lange Vorgeschichte, in der sie nach der Ankündigung die Unterstützung eingestellt haben.
    Irgendjemand hat mit diesem Blogpost und der Code-Veröffentlichung vermutlich ein Häkchen auf seiner Beförderungs-Scorecard bekommen, aber man sollte kein Geschäft auf einer solchen Lösung aufbauen.

  • Ich verstehe nicht, warum man das statt etwas Etablierterem wie Temporal in Betracht ziehen sollte. Maestro ist in Java geschrieben, und Temporal scheint in Go geschrieben zu sein.

    • Der Go-Code von Temporal ist etwas seltsam. Früher haben sie wohl Java verwendet, dann auf Go umgestellt, und dieses Go sieht sehr Java-mäßig aus.
      Oder vielleicht kenne ich Fx einfach nicht gut genug.
      https://github.com/temporalio/temporal/blob/main/service/mat...
      Das Problem, auf das ich bei Temporal immer wieder gestoßen bin, ist die sehr dürftige Dokumentation. Das ist etwas, das man im geschäftskritischen Kern installiert, aber es ist wirklich schwer, durch mehrere Schichten und sehr undurchsichtige Dokumentation hindurch zu verstehen, was tatsächlich passiert.
      Maestro scheint gar keine Dokumentation zu haben. Wenn dem so ist, gewinnt Temporal standardmäßig.
    • Netflix nutzt ebenfalls Temporal: https://temporal.io/in-use/netflix
    • Ich vermute, Maestro ist keine Alternative zu Temporal, sondern eher zu Airflow. Temporal ist kein Workflow-Orchestrator. In der internen Struktur gibt es Überschneidungen, aber es sind unterschiedliche Designs für unterschiedliche Use Cases.
    • Wurde nicht ein Teil des Kerns von Temporal in Rust neu geschrieben?

  • Sieht nach einem wirklich guten Projekt aus. Bei fast jedem gemischten ML- + Data-Engineering-Projekt, an dem ich gearbeitet habe, habe ich darüber nachgedacht, fast genau so etwas – vermutlich in einer schlechteren Version – zu bauen.
    Ich freue mich darauf, es selbst zu testen.

  • Da ich in diesem Bereich orchestra baue, hier meine Gedanken: Es ist sicherlich großartig, das als Open Source bereitzustellen und öffentlich zu entwickeln. Aber wie sie selbst sagen, ist das ein Orchestrator, und es gibt bereits sehr viel, was vorher kam, darunter Airflow usw.
    Deshalb fällt es mir schwer zu sehen, was es diesem Bereich tatsächlich hinzufügt, außer eine weitere Option, die in kommerziellen Umgebungen niemand nutzen wird.
    Unverschämte Eigenwerbung: https://getorchestra.io

  • Ich frage mich, ob sich das wesentlich von dem früher archivierten Conductor unterscheidet. Beim Überfliegen des Codes sehe ich ziemlich viele Ähnlichkeiten, und auch die Verwendung von JSON als Workflow-Definitionssprache ist gleich.