Maestro: el orquestador de workflows de Netflix

 (netflixtechblog.com)
4 puntos por GN⁺ 2024-07-24 | 1 comentarios | Compartir por WhatsApp
  • Netflix publicó como código abierto Maestro, un orquestador de escalado horizontal para workflows de Data/ML a gran escala, y internamente ya migró y opera cientos de miles de workflows con interrupciones mínimas
  • A diferencia de los orquestadores centrados en DAG, maneja tanto workflows acíclicos como cíclicos, y ofrece bucles foreach, subworkflows y ramificaciones condicionales como patrones a nivel del motor
  • Durante el último año, la cantidad de trabajos ejecutados aumentó 87.5%; actualmente ejecuta en promedio miles de instancias de workflow y alrededor de 500,000 trabajos por día, y en días de alta demanda completa cerca de 2 millones de trabajos
  • Combina definiciones basadas en JSON con estrategias de ejecución, parámetros, expresiones SEL, señales, breakpoints, timelines, políticas de reintento y rollups para dar soporte al control operativo y la depuración
  • En entornos como Netflix, donde las tablas de datos están concentradas en un único data warehouse, dividir los workflows en varios clústeres aumenta los costos de coordinación y deteriora la experiencia de usuario, por lo que es importante una arquitectura en la que un único orquestador se encargue de todo el flujo

Publicación de Maestro y escala operativa dentro de Netflix

  • Netflix publicó el código fuente de Maestro a través del repositorio de Maestro en GitHub
  • Maestro es un orquestador de workflows de escalado horizontal que gestiona workflows de Data/ML a gran escala, como pipelines de datos y pipelines de entrenamiento de modelos de machine learning
  • Gestiona todo el ciclo de vida de un workflow, desde el inicio hasta el final, y se encarga de reintentos, encolamiento y distribución de trabajos a motores de cómputo
  • Los usuarios pueden empaquetar la lógica de negocio en diversos formatos, como imágenes Docker, notebooks, scripts bash, SQL y Python
  • Después de presentarlo anteriormente, Netflix migró cientos de miles de workflows a Maestro y minimizó las interrupciones para los usuarios durante la transición
  • Escala operativa reciente:
    • Durante el último año, la cantidad de trabajos ejecutados aumentó 87.5%
    • Ejecuta en promedio miles de instancias de workflow por día
    • Ejecuta en promedio alrededor de 500,000 trabajos por día
    • En días de alta demanda, completa cerca de 2 millones de trabajos

Soporte para escalabilidad y diversidad con un único orquestador

  • Maestro es un orquestador totalmente administrado que ofrece Workflow-as-a-Service a miles de usuarios finales, aplicaciones y servicios dentro de Netflix
  • Soporta pipelines ETL, workflows de ML, pipelines de pruebas AB y pipelines de movimiento de datos entre varios sistemas de almacenamiento
  • Su arquitectura de escalado horizontal está diseñada para manejar tanto una gran cantidad de workflows como muchos trabajos dentro de un solo workflow
  • Como los workflows de Netflix están estrechamente conectados entre sí, dividirlos en grupos pequeños y gestionarlos en varios clústeres requeriría mecanismos adicionales de coordinación y degradaría la experiencia de usuario
  • Dado que las tablas de datos están en un único data warehouse, la decisión es que un único orquestador gestione todos los workflows que acceden a ellas

Modelo de definición de workflows

  • Las definiciones de workflow de Maestro se escriben en formato JSON
  • La definición de orquestación se compone combinando campos proporcionados por el usuario y campos administrados por Maestro; hay un ejemplo en la wiki del repositorio de Maestro
  • La definición de workflow se divide principalmente en dos áreas
    • properties: incluye información de autores y propietarios, además de configuración de ejecución
    • versioned workflow: incluye metadatos del workflow y definición del grafo
  • properties conserva atributos clave como información de autores y propietarios, estrategia de ejecución y configuración de concurrencia, incluso si cambia la versión del workflow
  • Si cambia la propiedad, el nuevo propietario puede asumir la propiedad del workflow existente sin crear una nueva versión del workflow
  • versioned workflow incluye identificador único, nombre, descripción, etiquetas, configuración de timeout y niveles de criticality low, medium y high para priorización
  • Los cambios en el workflow crean una nueva versión y, por defecto, se usa la versión activa o la más reciente
  • Un workflow está compuesto por steps, que son nodos del grafo definido por el usuario
    • Un step puede representar un trabajo, otro workflow mediante un subworkflow step, o un bucle mediante un foreach step
    • Un step incluye identificador único, tipo de step, etiquetas, parámetros de entrada y salida, dependencias, política de reintento, modo de falla y salidas del step, entre otros
    • Soporta políticas de reintento configurables por tipo de error

Run Strategy para controlar el orden de ejecución

  • Maestro decide si ejecutar una nueva instancia de workflow mediante una run strategy predefinida

  • Sequential Run Strategy

    • Es la estrategia predeterminada y ejecuta una instancia a la vez en orden FIFO
    • Independientemente de si la ejecución anterior tuvo éxito, cuando una instancia alcanza un estado terminal como éxito o falla, inicia la siguiente instancia de la cola

  • Strict Sequential Run Strategy

    • Ejecuta en el orden en que se dispararon las instancias, pero bloquea la ejecución si hay un blocking error en el historial de la instancia anterior
    • Las nuevas instancias permanecen en la cola hasta que la instancia fallida se reinicie manualmente o se haga unblock
    • Es útil para workflows con baja sensibilidad al tiempo, pero alta importancia para el negocio

  • First-only Run Strategy

    • No mantiene nuevas instancias en la cola antes de que se complete el workflow en ejecución
    • Si hay una instancia ejecutándose, elimina las nuevas instancias que entren a la cola, desactivando efectivamente el encolamiento
    • Ayuda a evitar problemas de idempotencia al no acumular nuevas instancias

  • Last-only Run Strategy

    • Garantiza que siempre se ejecute la instancia disparada más recientemente
    • Si ya hay una instancia en ejecución, la detiene y ejecuta la instancia recién disparada
    • Es útil cuando solo se necesitan los datos más recientes, como en workflows que procesan cada vez el snapshot más reciente de una tabla completa

  • Parallel with Concurrency Limit Run Strategy

    • Ejecuta varias instancias en paralelo dentro de un límite de concurrencia predefinido
    • Permite hacer fan-out y distribuir la ejecución para procesar muchos datos dentro de un límite de tiempo
    • Un caso de uso común es el backfill de datos antiguos

Parámetros y expresiones SEL

  • En Maestro, los parámetros se usan para controlar la lógica de ejecución, compartir estado entre el workflow y los steps, y compartir estado entre steps upstream y downstream
  • Maestro soporta parámetros dinámicos con inyección de código, lo que permite definir workflows complejos parametrizados
  • La inyección de código puede generar riesgos de seguridad y estabilidad
    • Si un usuario escribe un bucle infinito que sigue agregando elementos a un arreglo, el servidor puede detenerse por OOM
    • Si el código inyectado se traslada dentro de la lógica de negocio, aumenta la carga para el usuario y la definición del workflow queda fuertemente acoplada a la lógica de negocio
  • Para mitigar esto, Netflix desarrolló su propio lenguaje de expresiones, SEL (Simple, Secure, and Safe Expression Language)
  • SEL sigue la gramática y sintaxis de las Java Language Specifications, pero soporta un subconjunto adaptado a los casos de uso de Maestro
  • SEL soporta tipos de datos de los tipos de parámetros de Maestro, generación de errores, manejo de fecha y hora, y métodos utilitarios predefinidos
  • Para mejorar la estabilidad, incluye verificaciones en runtime como límites de iteraciones de bucles, comprobaciones de tamaño de arreglos y límites de tamaño de memoria de objetos
  • La documentación de SEL está en la documentación de Maestro en GitHub

Parámetros de salida y workflows parametrizados

  • Maestro permite devolver al sistema los resultados de la ejecución del usuario como parámetros de salida mediante callable step execution
  • Los datos de salida se transmiten a través de la API REST de Maestro, y el runtime del step no accede directamente a la base de datos de Maestro
  • Los workflows estáticos son simples, pero para reflejar pequeñas diferencias puede ser necesario duplicar el mismo workflow varias veces; además, sin parámetros, el workflow y los trabajos no pueden compartir estado
  • Los workflows completamente dinámicos son difíciles de gestionar y soportar, y también dificultan la depuración, la resolución de problemas y la reutilización
  • Los workflows parametrizados se inicializan por step en runtime con base en parámetros definidos por el usuario, lo que ofrece tanto flexibilidad de control en el momento de ejecución como facilidad de gestión
  • El soporte de parámetros de Maestro permite crear workflows parametrizados complejos, como pipelines de datos de backfill

Patrones de ejecución de workflows a nivel de motor

  • Maestro ofrece soporte directo en el motor para dataflows y patrones de workflow comunes
  • El soporte directo del motor permite optimizar patrones y tener una forma de implementación consistente

  • Foreach

    • El patrón foreach originalmente se modela como un step dedicado dentro de la definición del workflow
    • Cada iteración del loop foreach se maneja internamente como una instancia de workflow separada
    • La ejecución de steps dentro del bloque de definición foreach, es decir, la ejecución del subgraph, se delega a una instancia de workflow separada
    • El step foreach monitorea y recopila el estado de la instancia de workflow responsable de cada iteración
    • Se usa con frecuencia en backfills de datos o en el tuning de modelos de machine learning, donde se ejecuta la misma tarea con parámetros distintos por iteración
    • Los usuarios no tienen que escribir directamente cientos de miles de iteraciones en la definición del workflow, y también se reduce la necesidad de crear un workflow nuevo cuando cambia el rango del foreach

  • Conditional Branch

    • La rama condicional permite ejecutar steps posteriores solo cuando se cumple una condición específica de un step upstream
    • La condición se define con una expresión SEL y se evalúa en runtime
    • Se puede configurar un flujo que, cuando falla un step de auditoría, ejecute tareas de recuperación y luego vuelva a ejecutar el trabajo

  • Subworkflow

    • Un subworkflow permite que un step de un workflow ejecute otro workflow, de modo que funciones comunes se puedan compartir entre varios workflows
    • Permite construir el grafo de workflows en forma de “workflow as a function”
    • En Netflix se han observado workflows complejos compuestos por cientos de subworkflows, que procesan datos de cientos de tablas combinando subworkflows provistos por varios equipos
    • foreach, ramas condicionales y subworkflows se pueden combinar entre sí
    • Se puede procesar en loop un conjunto de subworkflows
    • Se pueden ejecutar loops foreach anidados
    • Se pueden usar ramas condicionales junto con subworkflows para manejar errores y crear workflows de recuperación automática que reintenten tareas automáticamente

Step Runtime y fusión de parámetros

  • Maestro usa step runtime para describir el trabajo en el momento de ejecución
  • La interfaz de step runtime define dos tipos de información
    • Un conjunto básico de API que controla el comportamiento de ejecución de una instancia de step
    • Una estructura de datos simple que rastrea el estado de runtime del step y el resultado de la ejecución
  • Maestro ofrece implementaciones como foreach step runtime y subworkflow step runtime
  • Cada implementación define su propia lógica para las acciones start, execute y terminate
  • El estado de runtime se usa para decidir la siguiente transición de estado del step y determinar si falló o terminó
  • El resultado de ejecución contiene los artefactos del step y la línea de tiempo del historial de ejecución del step, y puede ser accedido por steps posteriores

  • Step Parameter Merging

    • Maestro admite la inyección de runtime parameters y tags para controlar dinámicamente el comportamiento de los steps
    • El step parameter map inicialmente está vacío y se fusiona en el siguiente orden
    • Default General Parameters: parámetros básicos de todos los steps, como workflow_instance_id, step_instance_uuid, step_attempt_id, step_id; son valores reservados internos de Maestro y el usuario no puede pasarlos
    • Injected Parameters: parámetros generados dinámicamente por el step runtime, que pueden variar según el schema de cada tipo de step
    • Default Typed Parameters: parámetros predeterminados relacionados con un tipo específico de step; por ejemplo, en un step foreach, loop_params, loop_index, entre otros
    • Workflow and Step Info Parameters: información de identificación relacionada con el step y el workflow, como workflow_id
    • Undefined New Parameters: nuevos parámetros de step especificados por el usuario al iniciar o reiniciar una instancia de workflow
    • Step Definition Parameters: parámetros de step escritos por el usuario en el momento de la definición
    • Run and Restart Parameters: valores proporcionados por el usuario al iniciar o reiniciar para sobrescribir parámetros de definición existentes; se fusionan al final

Step Dependencies y Signal

  • Los steps del grafo de workflow de Maestro pueden expresar dependencias de ejecución mediante step dependency
  • Una step dependency especifica condiciones relacionadas con datos necesarias para ejecutar un step
  • Las condiciones normalmente se definen con base en signals
  • Un signal es un mensaje que contiene información como valores de parámetros, y puede publicarse mediante la salida de un step o a través de sistemas externos como SNS o Kafka
  • Los signals se usan tanto en el patrón trigger como en el patrón signal dependency de tipo publisher-subscriber
  • Un step puede publicar un signal de salida para desbloquear la ejecución de varios steps que dependen de ese signal
  • Una signal definition incluye una lista de parámetros mapeados, y Maestro puede realizar signal matching usando solo algunos campos
  • Maestro soporta signal operators como < y > para valores de parámetros de signal
  • Netflix construyó varias abstracciones sobre el concepto de signal
    • Cuando un workflow ETL actualiza una tabla y envía un signal, puede ejecutarse un step de workflow downstream que depende de esos datos
    • signal lineage permite explorar instancias de signal históricas y los steps de workflow que publicaron o consumieron esos signals
    • Un signal trigger garantiza exactly-once execution para workflows que se suscriben a un signal o a un conjunto de signals unidos
  • Como los workflows o steps se ejecutan solo cuando se cumplen las condiciones de signal especificadas, se pueden ahorrar recursos

Depuración y visibilidad de ejecución

  • Breakpoint

    • Maestro permite configurar breakpoints en steps de un workflow
    • Cuando una instancia de workflow llega a un step con breakpoint, ese step pasa al estado paused
    • El avance del grafo de workflow se detiene hasta que el usuario lo reanuda manualmente
    • Si varias instancias del mismo step de workflow se detienen en un breakpoint, reanudar una de ellas solo afecta a esa instancia, y las demás permanecen en estado paused
    • Al eliminar un breakpoint, se reanudan todas las instancias de step que estaban detenidas
    • Es útil para revisar la ejecución de steps y los datos de salida durante el desarrollo inicial de un workflow
    • En el patrón foreach, si se configura un breakpoint en un solo step, todas las iteraciones se detienen en ese step para poder depurarlas
    • También se puede usar para permitir intervención humana durante la ejecución o cambios en el estado de un step en ejecución

  • Timeline

    • Maestro incluye una línea de tiempo de ejecución de steps y registra eventos principales, como cambios en la máquina de estados y sus motivos
    • Entre los eventos de ejemplo se incluyen transiciones como Created y Evaluating params
    • Un step runtime implementado puede agregar eventos a la línea de tiempo para mostrar información de ejecución al usuario final
    • Hay un ejemplo de línea de tiempo en sample-step-instance-failed.json

Reintentos, vista agregada, rollup

  • Políticas de reintento

    • Maestro admite políticas de reintento para los steps que terminaron en estado de falla
    • Los usuarios pueden configurar la cantidad de reintentos, la demora entre reintentos, reintentos con intervalo fijo y estrategias de exponential backoff
    • Los reintentos se dividen en dos tipos
    • platform retry: respuesta a errores a nivel de plataforma no relacionados con la lógica del usuario
    • user retry: reintento según condiciones definidas por el usuario
    • Cada tipo puede tener su propia política de reintento
    • Los reintentos automáticos son útiles para manejar errores transitorios que pueden resolverse sin intervención del usuario
    • Los steps que no son idempotentes pueden configurar la cantidad de reintentos en 0 para evitarlos

  • Vista agregada

    • Como una workflow instance puede tener varios runs, el usuario debe poder ver el estado agregado de todos los steps
    • La vista agregada se calcula combinando la vista agregada base con el estado de los steps del run actual
    • Por ejemplo, si en la primera ejecución step1 y step2 tuvieron éxito, step3 falló, y step4 y step5 aún no habían iniciado, el reinicio comienza desde step3, y step1 y step2 pueden omitirse por su estado exitoso anterior
    • Si todos los steps tienen éxito, la vista agregada muestra el estado de run de todos los steps

  • Rollup

    • rollup proporciona un resumen de alto nivel de una workflow instance, e indica el estado de cada step y la cantidad de steps por estado
    • Agrega desplegando los steps del instance actual y de workflows no inline anidados, como subworkflow y foreach
    • Si un workflow exitoso tiene tres steps y uno de ellos es un subworkflow de cinco steps, el rollup muestra 7 steps exitosos
    • En el rollup solo se agregan los leaf steps, y los demás steps se tratan como punteros al workflow concreto
    • También se conservan las referencias de los steps que no tuvieron éxito, para poder navegar hasta el step problemático dentro del workflow anidado
    • El rollup agregado se calcula combinando los runtime data del run actual con el rollup base
    • El rollup de un step de subworkflow refleja tal cual el rollup de la subworkflow instance
    • El rollup de un step foreach combina el rollup base, excluyendo las iteraciones que serán reiniciadas desde ejecuciones anteriores, con los rollups de las iteraciones actualmente en ejecución
    • Debido a este proceso, el modelo de rollup es eventually consistent, y si foreach y subworkflow anidados se introducen en varios niveles, el cálculo puede ser complejo y recursivo

Publicación de eventos e integración externa

  • Cuando cambian una definición de workflow, una workflow instance o una step instance, Maestro genera eventos y, tras procesarlos internamente, los publica en sistemas externos
  • Los eventos de Maestro se dividen en eventos internos y externos
    • internal event: rastrea cambios internos del ciclo de vida de workflows, workflow instances y step instances, y se publica en una cola interna
    • external event: contiene información de cambios de estado de Maestro para que la consuman servicios downstream y se envía a colas externas como SNS o Kafka
  • El Maestro event processor se suscribe a la cola interna, toma los internal events, los procesa según el tipo de evento y, si es necesario, los transforma en external events
  • En la etapa final, el notification publisher publica los eventos externos para que los servicios downstream puedan consumirlos
  • Los servicios downstream son en su mayoría event-driven, y los eventos de Maestro contienen los mensajes necesarios para detectar diversos cambios en Maestro
  • Los tipos de cambio se dividen en dos grandes categorías
    • workflow change: acciones a nivel de workflow, como cambios en la definición o las properties del workflow
    • instance status change: transiciones de estado de una workflow instance o una step instance

Cómo empezar

  • El código de Maestro se puede consultar en github.com/Netflix/maestro
  • Las preguntas, opiniones y comentarios se pueden dejar como GitHub issue en el repositorio de Maestro
  • Netflix espera que la escalabilidad y facilidad de uso que ofrece Maestro también permitan desarrollar workflows rápidamente fuera de Netflix

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-24
Opiniones de Hacker News

  • Antes me impresionaban estos blogs técnicos corporativos y los sistemas internos propietarios, pero ya no. Porque el código es deuda.
    En vez de reinventar cosas como cron/Celery/Airflow, prefiero usar open source ya existente, con un largo historial de mantenimiento y mejoras. Alguien tiene que mantenerlo, corregir bugs y agregar funciones. Claro, la excepción sería si viene con un ascenso y un aumento de sueldo/RSU.
    Hay que darse cuenta de que el código que no forma parte del negocio central que le genera dinero a la empresa es algo que distrae y consume recursos.

    • Creo que esta publicación del blog existe precisamente por eso. La idea es convertir este software en open source para no tener que mantenerlo todo solo internamente.
      Lo crearon porque había una necesidad que el open source existente no resolvía, y ahora el proceso es volverlo open source establecido para seguir usándolo mientras comparten la carga de mantenimiento. ¿Cómo surgiría una herramienta así desde el principio? Alguien tiene que crearla.
    • La visión de que “el código es deuda” es demasiado extrema y está muy ligada a esa mentalidad estilo MBA de minimizar-maximizar todo en el mundo.
      Me alegra que haya gente que no tenga miedo de crear sistemas nuevos y empujar ideas nuevas. Incluso desde el punto de vista empresarial, hay un límite a lo que se puede lograr solo con soluciones mediocres y aversas al riesgo. Las empresas más rentables suelen ser bastante audaces técnicamente.
      El código no es deuda; es lo que hace girar los engranajes de la empresa.
    • El open source establecido muchas veces también es resultado de que grandes empresas publiquen herramientas internas. Airflow, que mencionaste directamente, es un buen ejemplo, y en este ámbito Temporal también lo es. Alguien tiene que ser lo suficientemente “tonto” como para crear algo nuevo.
    • La frase “un largo historial de mantenimiento y mejoras” carga con un supuesto enorme.
      Me pregunto si también tienes planes de contribuir a la comunidad. Construir o comprar siempre es una discusión importante, pero asumir que del lado de “comprar” el costo de mantenimiento y confiabilidad es exactamente 0 me parece ingenuo.
    • La condición de “algo que no es el negocio central de la empresa” es importante. Para un equipo experimentado en un área donde el rendimiento importa, el punto de inflexión en el que el código externo se convierte en deuda de baja calidad/bajo control no está tan lejos.

  • Me pregunto cuántas iteraciones más harán falta para que los ingenieros queden satisfechos con las soluciones de workflow. Netflix ya tenía varias soluciones antes de Maestro, como Metaflow; Uber también creó varias soluciones, y Amazon tenía al menos una docena de motores de workflow internos.
    Me parece interesante que tantas personas en distintas empresas quieran crear motores de workflow. No lo digo para menospreciar a nadie ni a Netflix; lo veo como una observación para conversar de forma ligera.

    • El problema es que la orquestación de workflows es un dominio de problemas muy amplio. Las empresas tienen que resolver múltiples problemas distintos, así que cualquier solución termina siendo un producto enorme con muchas funciones relacionadas y, a medida que crece, tiende a convertirse en un gran monolito con una filosofía fuerte. Por eso casi nadie queda satisfecho.
      En realidad hay cinco preocupaciones centrales: scheduling de recursos, resolución de dependencias, una API/DSL para crear tareas y workflows, ejecución programada tipo cron, y conciencia de dominio, que expone información del dominio en workflows de ETL o ML/AI.
      No existe una única solución que haga todo eso de forma limpia. Por eso las empresas terminan creando algo propio o rodeando las limitaciones para cubrir las carencias de los productos existentes, y se mantiene un ciclo en el que todos siguen insatisfechos.
      No creo que sea un problema que una startup pueda resolver como “la solución”. Hay que resolverlo con un ecosistema open source de buenos componentes modulares enchufables.
    • Metaflow corre sobre Maestro; ninguno de los dos reemplaza al otro.
      En https://netflixtechblog.com/orchestrating-data-ml-workflows-... dice: “Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.”
      La sección de orquestación de este artículo (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) explica en detalle cómo Metaflow encaja con Maestro, Airflow, Argo Workflows y Step Functions.
    • Creé un motor de workflow propio, pero tenía tantos bugs y era tan poco flexible que casi arruina un proyecto no relacionado.
      Estoy empezando a pensar que los motores de workflow pueden ser, hasta cierto punto, un olor de diseño. Una vez que haces algo reutilizable, parece atractivo porque podrías usarlo en muchísimos workflows, pero los workflows casi no tienen nada en común salvo que necesitan más de un paso asíncrono.
      Los datos son distintos, las API son distintas, y el feedback que hay que recibir de usuarios u otros sistemas para poder seguir avanzando también es distinto.
    • Probablemente sea porque todavía no hemos encontrado un motor/orquestador de workflows que pueda manejar tareas diversas y, al mismo tiempo, sea fácil de entender y operar.
      Crear un motor de workflows a medida optimizado para un caso de uso específico es realmente fácil. Creo que aún no ha habido convergencia porque esa herramienta todavía no se ha creado.
      Si miramos herramientas recientes que dominaron rápidamente sus áreas, Terraform resolvió IaC y Kubernetes resolvió problemas difíciles de cómputo distribuido. Ambas son muy complejas, pero resuelven problemas difíciles. En cambio, los motores de workflow de propósito general son complejos de entender, difíciles de operar y la experiencia es ambigua, así que mucha gente ni siquiera lo intenta.
    • ¿Nombrar cosas, invalidación de caché y motores de workflow? :)
      https://github.com/meirwah/awesome-workflow-engines

  • Soy fundador de https://windmill.dev, y Windmill tiene muchos puntos en común con Maestro.
    La parte de la descripción de Maestro que dice “un orquestador de workflows de propósito general y escalable horizontalmente para gestionar workflows a gran escala, pipelines de datos y pipelines de entrenamiento de modelos de ML” también encaja perfectamente si se cambia por Windmill. Lo que ellos llaman rollup es lo que nosotros llamamos openflow state.
    Las principales diferencias son que Windmill está escrito en Rust en lugar de Java, y que Maestro usa CockroachDB para guardar el estado, mientras que nosotros usamos PostgreSQL tanto para el estado como para la cola. Dicho eso, entiendo por qué usan CockroachDB. En Windmill también tuvimos que crear nuestro propio algoritmo de sharding para escalar horizontalmente en instancias de clientes muy grandes.
    Maestro es Apache 2.0 y Windmill usa la menos amigable AGPL. Con el respaldo de Netflix, el financiamiento es prácticamente infinito, mientras que nosotros, aunque somos rentables, somos una empresa mucho más pequeña.
    Maestro no tiene suficiente documentación de self-hosting basada en Kubernetes o docker-compose, y no tiene una UI para crear cosas, o al menos eso todavía no se ve claro en la documentación. Aun así, en general es bastante genial que lo hayan publicado como open source, y pienso seguirlo de cerca y hacer benchmarks lo antes posible.

    • Si estás considerando Windmill, primero deberías ver esto: https://www.windmill.dev/docs/advanced/local_development
      No entiendo por qué hay que “sincronizar” con Windmill, por qué Windmill trae un IDE integrado ni por qué es tan complejo. Parece que empezaron buscando lock-in incluso antes de crear un buen producto o encontrar encaje de mercado.
    • Comparar está bien, pero aunque Maestro tenga licencia Apache, si depende de CockroachDB no es tan bueno, porque CockroachDB en sí no es open source.
      En mi opinión, una base de código AGPL es preferible a una dependencia que no es open source. Por supuesto, con el tiempo alguien podría agregar soporte para una base de datos alternativa.

  • Estoy un poco confundido sobre lo que está pasando aquí. Este proyecto parece usar Netflix/conductor [0]. Pero si vas a ese repositorio, está archivado y hay un mensaje que dice que fue reemplazado por una versión interna no open source de Netflix y por un fork comunitario no mencionado. Supongo que se refiere a Orkes Conductor [1].
    Pero esto no parece usar Orkes Conductor, sino la versión discontinuada de Netflix, com.netflix.conductor:conductor-core:2.31.5 [2]. Y además es una versión antigua.
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

  • Me pregunto si alguien ha usado ActiveBatch. Para mí es el mejor software para el que me gustaría que existiera un equivalente para usuarios no empresariales.
    He seguido probando otros “competidores”, pero con ActiveBatch conectas una simple DB de MS SQL, instalas una GUI de Windows y agentes de ejecución, y con unos pocos clics tienes un entorno de automatización sólido basado en GUI. No necesitas escribir código, y si quieres puedes escribir código en cualquier lenguaje.
    Airflow puede ser potente, pero está escondido detrás de una barrera de complejidad, así que la mayoría nunca ve cuál es su verdadera capacidad. Lo mismo pasa con otros competidores “open source”.
    No entiendo por qué nadie logra crear un sistema robusto basado en DB y con GUI como prioridad. También probé servicios online, pero no se comparan. Quizá los productos pagos más simples fracasan por el costo de mantener extensiones.
    Es una verdadera lástima que ActiveBatch esté atrapado detrás de un modelo de ventas empresariales absurdo. Eso impide que este excelente software llegue a una comunidad más amplia. Es como un secreto oculto.

  • Como consejo, conviene no depender de herramientas que Netflix publica como open source. Tienen un largo historial de anunciarlas y luego dejar de darles soporte.
    Alguien habrá conseguido marcar una casilla en su evaluación de ascenso con esta entrada de blog y la publicación del código, pero no deberías construir un negocio sobre soluciones así.

  • No entiendo por qué habría que considerar esto en lugar de algo más establecido como Temporal. Maestro está escrito en Java, y Temporal parece estar escrito en Go

    • El código Go de Temporal es algo extraño. Creo que antes usaban Java, pero se cambiaron a Go, y ese Go se ve muy al estilo Java
      O quizá simplemente no conozco bien Fx
      https://github.com/temporalio/temporal/blob/main/service/mat...
      El problema con el que me topé repetidamente en Temporal es que la documentación es muy insuficiente. Es algo que se instala en el núcleo del negocio, pero es realmente difícil entender qué está pasando en la práctica después de atravesar varias capas y documentación muy críptica
      Maestro parece no tener documentación. Si es así, Temporal gana por defecto
    • Netflix también usa Temporal: https://temporal.io/in-use/netflix
    • Me parece que Maestro no es una alternativa a Temporal, sino a Airflow. Temporal no es un orquestador de workflows. Hay partes que se superponen en la estructura interna, pero son diseños distintos para casos de uso distintos
    • ¿No habían reescrito parte del núcleo de Temporal en Rust?

  • Parece un proyecto realmente bueno. En casi todos los proyectos híbridos de ML + ingeniería de datos en los que trabajé, alguna vez consideré crear algo casi igual a esto, probablemente en una versión peor
    Me entusiasma probarlo directamente

  • Como estoy creando orchestra en este ámbito, dejo mi opinión: hacerlo open source y desarrollarlo públicamente sin duda es excelente. Pero, como ellos mismos dicen, esto es un orquestador, y ya hay demasiados proyectos anteriores, incluidos Airflow y otros
    Por eso, más allá de sumar otra opción que nadie usará en entornos comerciales, me cuesta ver qué aporta realmente a este espacio
    Promoción descarada: https://getorchestra.io

  • Me pregunto si esto es significativamente distinto del Conductor que fue archivado anteriormente. Al revisar el código se ven bastantes similitudes, y también coincide en usar JSON como lenguaje de definición de workflows