Maestro: o orquestrador de workflows da Netflix

 (netflixtechblog.com)
4 pontos por GN⁺ 2024-07-24 | 1 comentários | Compartilhar no WhatsApp
  • A Netflix tornou open source o Maestro, um orquestrador com escalabilidade horizontal para workflows de Data/ML em grande escala, e internamente já migrou centenas de milhares de workflows com mínima interrupção e os mantém em operação
  • Diferentemente de orquestradores centrados em DAGs, ele lida tanto com workflows acíclicos quanto cíclicos, oferecendo loops foreach, subworkflows e ramificações condicionais como padrões no nível do motor
  • No último ano, o número de tarefas executadas aumentou 87,5%; atualmente, executa em média milhares de instâncias de workflow e cerca de 500 mil tarefas por dia, chegando a concluir cerca de 2 milhões de tarefas em dias movimentados
  • Combina definições em JSON com estratégias de execução, parâmetros, expressões SEL, sinais, breakpoints, timelines, políticas de retry e rollups para dar suporte a controle operacional e depuração
  • Em ambientes como o da Netflix, onde as tabelas de dados ficam concentradas em um único data warehouse, dividir workflows entre vários clusters aumenta o custo de coordenação e piora a experiência do usuário; por isso, é importante uma arquitetura em que um orquestrador único cuide de todo o fluxo

Abertura do Maestro e escala de operação dentro da Netflix

  • A Netflix disponibilizou o código-fonte do Maestro por meio do repositório GitHub do Maestro
  • O Maestro é um orquestrador de workflows com escalabilidade horizontal que gerencia workflows de Data/ML em grande escala, como pipelines de dados e pipelines de treinamento de modelos de machine learning
  • Ele gerencia todo o ciclo de vida do workflow, do início ao fim, e lida com retries, enfileiramento e distribuição de tarefas para mecanismos de computação
  • Os usuários podem empacotar a lógica de negócio em diversos formatos, como imagens Docker, notebooks, scripts bash, SQL e Python
  • Depois de apresentá-lo anteriormente, a Netflix migrou centenas de milhares de workflows para o Maestro, minimizando interrupções para os usuários durante a transição
  • Escala operacional recente:
    • O número de tarefas executadas aumentou 87,5% no último ano
    • Execução média diária de milhares de instâncias de workflow
    • Execução média diária de cerca de 500 mil tarefas
    • Em dias movimentados, conclusão de cerca de 2 milhões de tarefas

Suporte a escalabilidade e diversidade com um orquestrador único

  • O Maestro é um orquestrador totalmente gerenciado que fornece Workflow-as-a-Service para milhares de usuários finais, aplicações e serviços dentro da Netflix
  • Ele dá suporte a pipelines ETL, workflows de ML, pipelines de testes A/B e pipelines de movimentação de dados entre vários storages
  • Sua arquitetura com escalabilidade horizontal foi projetada para lidar tanto com um grande número de workflows quanto com muitas tarefas dentro de um único workflow
  • Como os workflows da Netflix são fortemente interconectados, dividi-los em pequenos grupos e gerenciá-los em vários clusters exigiria mecanismos adicionais de coordenação e prejudicaria a experiência do usuário
  • Como as tabelas de dados estão em um único data warehouse, a avaliação é que todos os workflows que acessam esse ambiente devem ser tratados por um orquestrador único

Modelo de definição de workflow

  • A definição de workflow do Maestro é escrita em formato JSON
  • A definição de orquestração é composta pela combinação de campos fornecidos pelo usuário e campos gerenciados pelo Maestro; há um exemplo na wiki do repositório do Maestro
  • A definição de workflow se divide em duas áreas principais
    • properties: inclui informações de autor e proprietário, além de configurações de execução
    • versioned workflow: inclui metadados do workflow e a definição do grafo
  • As properties preservam atributos essenciais, como informações de autor e proprietário, estratégia de execução e configurações de concorrência, mesmo quando a versão do workflow muda
  • Quando há mudança de propriedade, o novo proprietário pode assumir a propriedade do workflow existente sem criar uma nova versão do workflow
  • O versioned workflow inclui identificador único, nome, descrição, tags, configurações de timeout e níveis de criticality low, medium e high para priorização
  • Alterações no workflow criam uma nova versão e, por padrão, é usada a versão ativa ou a versão mais recente
  • Um workflow é composto por steps, que são nós do grafo definido pelo usuário
    • Um step pode representar uma tarefa, outro workflow por meio de um subworkflow step ou um loop por meio de um foreach step
    • Um step inclui identificador único, tipo de step, tags, parâmetros de entrada e saída, dependências, política de retry, modo de falha e saídas do step
    • Há suporte a políticas de retry configuráveis por tipo de erro

Run Strategy para controlar a ordem de execução

  • O Maestro decide se deve executar uma nova instância de workflow com base em uma run strategy predefinida

  • Sequential Run Strategy

    • É a estratégia padrão e executa uma instância por vez em ordem FIFO
    • Independentemente de a execução anterior ter sido bem-sucedida ou não, quando a instância atinge um estado final, como sucesso ou falha, a próxima instância da fila é iniciada

  • Strict Sequential Run Strategy

    • Executa na ordem em que as instâncias foram acionadas, mas bloqueia a execução se houver um blocking error no histórico da instância anterior
    • Novas instâncias permanecem na fila até que a instância com falha seja reiniciada manualmente ou desbloqueada
    • É útil para workflows com baixa sensibilidade a tempo, mas alta importância de negócio

  • First-only Run Strategy

    • Não mantém novas instâncias na fila antes que o workflow em execução seja concluído
    • Se já houver uma instância em execução, remove as novas instâncias que entram na fila, efetivamente desativando o enfileiramento
    • Ajuda a evitar problemas de idempotência ao não acumular novas instâncias

  • Last-only Run Strategy

    • Garante que a instância acionada mais recentemente seja sempre a executada
    • Se houver uma instância em execução, ela é interrompida e a instância recém-acionada é executada
    • É útil quando apenas os dados mais recentes são necessários, como em workflows que processam sempre o snapshot mais recente de uma tabela inteira

  • Parallel with Concurrency Limit Run Strategy

    • Executa várias instâncias em paralelo dentro de um limite de concorrência predefinido
    • Permite fazer fan-out e distribuir a execução para processar muitos dados dentro de um prazo limitado
    • Um caso de uso comum é o backfill de dados antigos

Parâmetros e expressões SEL

  • No Maestro, parâmetros são usados para controlar a lógica de execução, compartilhar estado entre workflows e steps, e compartilhar estado entre steps upstream e downstream
  • O Maestro oferece suporte a parâmetros dinâmicos com injeção de código, permitindo definir workflows com parametrização complexa
  • A injeção de código pode criar riscos de segurança e estabilidade
    • Se um usuário escrever um loop infinito que continua adicionando itens a um array, o servidor pode parar por OOM
    • Mover o código injetado para dentro da lógica de negócio aumenta o ônus para o usuário e acopla fortemente a definição do workflow à lógica de negócio
  • Para mitigar isso, a Netflix desenvolveu sua própria linguagem de expressão, a SEL (Simple, Secure, and Safe Expression Language)
  • A SEL segue a gramática e a sintaxe das Java Language Specifications, mas oferece suporte a um subconjunto adaptado aos casos de uso do Maestro
  • A SEL dá suporte aos tipos de dados dos tipos de parâmetro do Maestro, geração de erros, tratamento de data e hora e métodos utilitários predefinidos
  • Para estabilidade, inclui verificações em runtime, como limite de iterações de loops, verificação de tamanho de arrays e limite de tamanho de memória de objetos
  • A documentação da SEL está na documentação do Maestro no GitHub

Parâmetros de saída e workflows parametrizados

  • O Maestro permite que resultados de execução do usuário sejam retornados ao sistema como parâmetros de saída por meio de callable step execution
  • Os dados de saída são transmitidos via API REST do Maestro, e o runtime do step não acessa diretamente o banco de dados do Maestro
  • Workflows estáticos são simples, mas podem exigir várias cópias do mesmo workflow para refletir pequenas diferenças; sem parâmetros, workflows e tarefas não conseguem compartilhar estado
  • Workflows totalmente dinâmicos são difíceis de gerenciar e dar suporte, além de dificultarem depuração, troubleshooting e reutilização
  • Workflows parametrizados são inicializados por step em runtime com base em parâmetros definidos pelo usuário, oferecendo ao mesmo tempo flexibilidade no controle em tempo de execução e capacidade de gerenciamento
  • O suporte a parâmetros do Maestro possibilita criar workflows parametrizados complexos, como pipelines de dados de backfill

Padrões de execução de workflow no nível do engine

  • O Maestro dá suporte direto, no engine, a dataflows e padrões de workflow comuns
  • O suporte direto no engine permite otimizar padrões e manter uma forma de implementação consistente

  • Foreach

    • O padrão foreach foi originalmente modelado como um step dedicado dentro da definição do workflow
    • Cada iteração do loop foreach é tratada internamente como uma instância de workflow separada
    • A execução dos steps dentro do bloco de definição do foreach, ou seja, a execução do subgraph, é delegada a uma instância de workflow separada
    • O step foreach monitora e coleta o estado das instâncias de workflow responsáveis por cada iteração
    • É usado com frequência em backfills de dados ou tuning de modelos de machine learning, em que a mesma tarefa é executada com parâmetros diferentes por iteração
    • O usuário não precisa escrever diretamente centenas de milhares de iterações na definição do workflow, e também diminui a necessidade de criar um novo workflow quando o intervalo do foreach muda

  • Conditional Branch

    • O desvio condicional faz com que steps posteriores sejam executados somente quando uma condição específica de um step upstream é satisfeita
    • As condições são definidas como expressões SEL e avaliadas em runtime
    • É possível configurar um fluxo em que, quando um step de verificação de auditoria falha, uma ação de recuperação é executada e depois a tarefa é executada novamente

  • Subworkflow

    • Um subworkflow permite que um step de workflow execute outro workflow, possibilitando compartilhar funcionalidades comuns entre vários workflows
    • É possível compor o grafo do workflow no formato “workflow as a function”
    • Na Netflix, também foram observados workflows complexos compostos por centenas de subworkflows, que combinam subworkflows fornecidos por várias equipes para processar dados de centenas de tabelas
    • foreach, desvio condicional e subworkflow podem ser combinados entre si
    • É possível processar um conjunto de subworkflows em loop
    • É possível executar loops foreach aninhados
    • Ao usar desvio condicional e subworkflow juntos, é possível criar workflows de recuperação automática que tratam erros e repetem automaticamente a tarefa

Step Runtime e mesclagem de parâmetros

  • O Maestro usa step runtime para descrever o trabalho no momento da execução
  • A interface de step runtime define duas informações
    • Um conjunto básico de APIs que controla o comportamento de execução da instância do step
    • Uma estrutura de dados simples que rastreia o estado de runtime e o resultado da execução do step
  • O Maestro fornece implementações como foreach step runtime e subworkflow step runtime
  • Cada implementação define sua própria lógica para as ações start, execute e terminate
  • O estado de runtime é usado para determinar a próxima transição de estado do step e verificar se houve falha ou encerramento
  • O resultado da execução contém os artefatos do step e a timeline do histórico de execução do step, e pode ser acessado por steps posteriores

  • Step Parameter Merging

    • O Maestro oferece suporte à injeção de runtime parameters e tags para controlar dinamicamente o comportamento do step
    • O step parameter map começa vazio e é mesclado na seguinte ordem
    • Default General Parameters: parâmetros básicos de todos os steps, como workflow_instance_id, step_instance_uuid, step_attempt_id e step_id; são valores reservados internamente pelo Maestro e não podem ser passados pelo usuário
    • Injected Parameters: parâmetros gerados dinamicamente pelo step runtime, que podem variar conforme o schema de cada tipo de step
    • Default Typed Parameters: parâmetros padrão relacionados a um tipo específico de step, como loop_params e loop_index em um step foreach
    • Workflow and Step Info Parameters: informações de identificação relacionadas ao step e ao workflow, como workflow_id
    • Undefined New Parameters: novos parâmetros de step especificados pelo usuário ao iniciar ou reiniciar uma instância de workflow
    • Step Definition Parameters: parâmetros de step escritos pelo usuário no momento da definição
    • Run and Restart Parameters: valores fornecidos pelo usuário ao iniciar ou reiniciar para sobrescrever parâmetros existentes da definição; são mesclados por último

Dependências de step e signals

  • Os steps no grafo de workflow do Maestro podem expressar dependências de execução por meio de step dependency
  • Uma step dependency especifica condições relacionadas a dados necessárias para a execução do step
  • As condições geralmente são definidas com base em signals
  • Um signal é uma mensagem que contém informações como valores de parâmetros, e pode ser publicado por saídas de steps ou por sistemas externos como SNS e Kafka
  • Signals são usados tanto no padrão de trigger quanto no padrão de signal dependency no formato publisher-subscriber
  • Um step pode publicar signals de saída para liberar a execução de vários steps que dependem desse signal
  • Uma signal definition inclui uma lista de parâmetros mapeados, e o Maestro pode realizar signal matching usando apenas alguns campos
  • O Maestro oferece suporte a signal operators, como < e >, para valores de parâmetros de signal
  • A Netflix construiu várias abstrações sobre o conceito de signal
    • Quando um workflow de ETL atualiza uma tabela e envia um signal, steps de workflows downstream que dependem desses dados podem ser executados
    • signal lineage permite explorar instâncias antigas de signals e os steps de workflow que publicaram ou consumiram esses signals
    • O signal trigger garante exactly-once execution para workflows que assinam um ou um conjunto de signals unidos por join
  • Como workflows ou steps são executados somente quando as condições de signal especificadas são satisfeitas, é possível economizar recursos

Depuração e visibilidade da execução

  • Breakpoint

    • O Maestro permite definir breakpoints em steps de workflow
    • Quando uma instância de workflow chega a um step com breakpoint, esse step fica no estado paused
    • O avanço do grafo do workflow é interrompido até que o usuário retome manualmente
    • Se várias instâncias do mesmo step de workflow estiverem paradas em um breakpoint, retomar uma delas afeta apenas essa instância, enquanto as demais permanecem no estado paused
    • Ao remover um breakpoint, todas as instâncias de step que estavam paradas são retomadas
    • É útil para inspecionar a execução de steps e os dados de saída durante o desenvolvimento inicial de um workflow
    • No padrão foreach, ao colocar um breakpoint em um único step, todas as iterações param nesse step para permitir a depuração
    • Também pode ser usado para oferecer suporte à intervenção humana durante a execução ou à alteração do estado de um step em execução

  • Timeline

    • O Maestro inclui a timeline de execução do step e registra eventos importantes, como mudanças na máquina de estados e seus motivos
    • Exemplos de eventos incluem transições como Created e Evaluating params
    • Implementações de step runtime podem adicionar eventos à timeline para mostrar informações de execução ao usuário final
    • Um exemplo de timeline está em sample-step-instance-failed.json

Tentativas, Aggregated View, Rollup

  • Políticas de retry

    • O Maestro oferece suporte a políticas de retry para steps que chegaram a um estado final de falha
    • Os usuários podem configurar o número de tentativas, o atraso entre tentativas, retries em intervalo fixo e a estratégia de exponential backoff
    • Os retries são divididos em dois tipos
    • platform retry: resposta a erros em nível de plataforma, sem relação com a lógica do usuário
    • user retry: retry com base em condições definidas pelo usuário
    • Cada tipo pode ter uma política de retry separada
    • O retry automático é útil para tratar erros transitórios que podem ser resolvidos sem intervenção do usuário
    • Steps que não são idempotentes podem definir o número de tentativas como 0 para evitar retries

  • Aggregated View

    • Como uma única workflow instance pode ter vários runs, o usuário precisa conseguir ver o estado agregado de todos os steps
    • A aggregated view é calculada mesclando a aggregated view base com o estado dos steps do run atual
    • Por exemplo, se na primeira execução step1 e step2 tiverem sucesso, step3 falhar e step4 e step5 ainda não tiverem começado, o reinício começa a partir do step3, e step1 e step2 podem ser pulados por causa do estado de sucesso anterior
    • Quando todos os steps têm sucesso, a aggregated view mostra o estado de run de todos os steps

  • Rollup

    • rollup fornece um resumo de alto nível de uma workflow instance, mostrando o estado de cada step e a contagem de steps por estado
    • Ele expande e agrega os steps da instância atual e de workflows non-inline aninhados, como subworkflow e foreach
    • Se um workflow bem-sucedido tiver três steps, e um deles for um subworkflow com cinco steps, o rollup exibirá 7 steps bem-sucedidos
    • No rollup, apenas leaf steps são agregados; os demais steps são tratados como ponteiros para o workflow específico
    • Referências a steps que não tiveram sucesso também são preservadas, permitindo navegar até o step com problema dentro de um workflow aninhado
    • O aggregated rollup é calculado combinando os runtime data do run atual com o base rollup
    • O rollup de um step de subworkflow reflete diretamente o rollup da subworkflow instance
    • O rollup de um step foreach combina o base rollup, excluindo as iterações alvo de reinício da execução anterior, com os rollups das iterações em execução no momento
    • Por causa desse processo, o modelo de rollup é eventually consistent e, quando foreach e subworkflow aninhados entram em vários níveis, o cálculo pode ser complexo e recursivo

Publicação de eventos e integração externa

  • Quando uma definição de workflow, workflow instance ou step instance é alterada, o Maestro gera eventos e, após o processamento interno, os publica em sistemas externos
  • Os eventos do Maestro são divididos em eventos internos e externos
    • internal event: rastreia mudanças internas no ciclo de vida de workflows, workflow instances e step instances, e é publicado em uma fila interna
    • external event: contém informações de mudança de estado do Maestro a serem consumidas por serviços downstream e é enviado para filas externas como SNS e Kafka
  • O Maestro event processor assina a fila interna, busca internal events e os processa conforme o tipo de evento, convertendo-os em external events quando necessário
  • Na última etapa, o notification publisher publica eventos externos para que serviços downstream possam consumi-los
  • A maioria dos serviços downstream é orientada a eventos, e os eventos do Maestro contêm as mensagens necessárias para detectar diversas mudanças no Maestro
  • Os tipos de mudança se dividem, em linhas gerais, em duas categorias
    • workflow change: ações em nível de workflow, como mudanças na definição ou nas properties do workflow
    • instance status change: transições de estado de uma workflow instance ou step instance

Como começar

  • O código do Maestro pode ser consultado em github.com/Netflix/maestro
  • Perguntas, feedback e comentários podem ser deixados como GitHub issue no repositório do Maestro
  • A Netflix espera que a escalabilidade e a usabilidade oferecidas pelo Maestro também permitam acelerar o desenvolvimento de workflows fora da Netflix

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-24
Opiniões no Hacker News

  • Antigamente eu ficava impressionado com esses blogs técnicos corporativos e sistemas internos proprietários, mas hoje não mais. Porque código é dívida.
    Em vez de reinventar algo como cron/Celery/Airflow, eu preferiria usar open source consolidado, com um longo histórico de manutenção e melhorias. Afinal, alguém precisa manter, corrigir bugs e adicionar recursos. Claro, a exceção é se isso vier acompanhado de promoção e aumento de salário/RSU.
    É preciso perceber que código que não está ligado ao trabalho central que gera dinheiro para a empresa é algo que dispersa a atenção e consome recursos.

    • Acho que este post no blog saiu justamente por isso. A ideia é tornar esse software open source, para que ele não precise mais ser mantido inteiramente só internamente.
      Eles o criaram porque havia uma necessidade que as opções open source consolidadas existentes não resolviam, e agora estão no processo de transformá-lo novamente em open source consolidado, continuando a usá-lo enquanto compartilham o peso da manutenção. Como uma ferramenta dessas surgiria desde o início? Alguém precisa criá-la.
    • A visão de que “código é dívida” é extrema demais e está fortemente ligada a uma mentalidade de minimizar-maximizar tudo no mundo no estilo MBA.
      Ainda bem que existem pessoas que não têm medo de criar novos sistemas e impulsionar novas ideias. Mesmo do ponto de vista corporativo, soluções medianas e avessas a risco têm seus limites. As empresas mais lucrativas costumam ser bastante ousadas tecnicamente.
      Código não é dívida; é o que faz as engrenagens da empresa girarem.
    • Muitas vezes, open source consolidado também é resultado de grandes empresas terem aberto suas ferramentas internas. O Airflow que você mencionou diretamente é um bom exemplo, e nessa área o Temporal também é. Alguém precisa ser “burro” o suficiente para criar algo novo.
    • A expressão “longo histórico de manutenção e melhorias” carrega uma premissa enorme.
      Fico curioso se você também planeja contribuir com a comunidade. Construir ou comprar é sempre uma discussão importante, mas parece ingênuo assumir que, no lado de “comprar”, os custos de manutenção e confiabilidade sejam exatamente 0.
    • A condição “algo que não é o trabalho central da empresa” é importante. Para uma equipe experiente em uma área onde desempenho é importante, o ponto de inflexão em que código externo vira dívida de baixa qualidade/baixo controle não fica tão distante.

  • Fico me perguntando quantas iterações ainda serão necessárias para que engenheiros fiquem satisfeitos com soluções de workflow. Antes do Maestro, a Netflix já tinha várias soluções como o Metaflow; a Uber também criou várias soluções; e a Amazon tinha pelo menos uma dúzia de motores de workflow internos.
    É interessante que tantas pessoas, em várias empresas, queiram criar motores de workflow. Não estou tentando depreciar ninguém nem a Netflix; vejo isso apenas como uma observação interessante para uma conversa descontraída.

    • O problema é que orquestração de workflows é um domínio de problema muito amplo. As empresas precisam resolver vários problemas diferentes, então qualquer solução acaba virando um produto enorme, com muitos recursos relacionados, e, conforme cresce, tende a se tornar um grande monólito com uma filosofia forte. Por isso, quase ninguém fica satisfeito.
      Na prática, há cinco preocupações centrais: agendamento de recursos, resolução de dependências, API/DSL para criar tarefas e workflows, execução agendada ao estilo cron e consciência de domínio, que expõe informações de domínio em workflows de ETL ou ML/AI.
      Não existe uma solução única que faça tudo isso de forma limpa. Por isso, as empresas acabam criando suas próprias soluções ou contornos para cobrir as deficiências dos produtos existentes, e o ciclo em que todos continuam insatisfeitos se perpetua.
      Não acho que seja um problema que uma startup possa criar como “a solução”. Isso precisa ser resolvido por um ecossistema open source composto por bons componentes modulares plugáveis.
    • O Metaflow roda em cima do Maestro, e um não substitui o outro.
      Em https://netflixtechblog.com/orchestrating-data-ml-workflows-... está escrito: “Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.”
      A seção de orquestração deste artigo (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) explica em detalhes como o Metaflow se encaixa com Maestro, Airflow, Argo Workflows e Step Functions.
    • Criei um motor de workflow próprio, mas ele tinha tantos bugs e era tão inflexível que quase arruinou um projeto não relacionado.
      Estou começando a achar que motores de workflow podem ser, em certa medida, um cheiro de design. Depois que você cria algo reutilizável, parece atraente pensar que ele poderá ser usado em inúmeros workflows, mas, além do fato de precisarem de mais de uma etapa assíncrona, os workflows quase não têm nada em comum.
      Os dados são diferentes, as APIs são diferentes, e o feedback que precisa vir de usuários ou de outros sistemas para continuar também é diferente.
    • O motivo provavelmente é que ainda não encontramos um motor/orquestrador de workflows que lide com tarefas variadas e, ao mesmo tempo, seja fácil de entender e operar.
      Criar um motor de workflow sob medida, otimizado para um caso de uso específico, é realmente fácil. Acho que a convergência ainda não aconteceu porque essa ferramenta ainda não foi criada.
      Olhando para ferramentas recentes que dominaram rapidamente seus respectivos domínios, Terraform resolveu IaC, e Kubernetes resolveu problemas difíceis de computação distribuída. Ambos são muito complexos, mas resolvem problemas difíceis. Já motores de workflow de propósito geral são complexos de entender, difíceis de operar e oferecem uma experiência meio ambígua; por isso, muita gente nem tenta.
    • Nomear coisas, invalidar cache e... motores de workflow? :)
      https://github.com/meirwah/awesome-workflow-engines

  • Sou fundador da https://windmill.dev, e o Windmill tem muitos pontos em comum com o Maestro.
    A parte da descrição do Maestro que diz “um orquestrador de workflows horizontalmente escalável e de uso geral para gerenciar workflows em larga escala, pipelines de dados e pipelines de treinamento de modelos de ML” também se encaixa exatamente se trocarmos por Windmill. O que eles chamam de rollup é o que nós chamamos de openflow state.
    As principais diferenças são que o Windmill foi escrito em Rust em vez de Java, e o Maestro usa CockroachDB para armazenar estado, enquanto nós usamos PostgreSQL tanto para estado quanto para filas. Dito isso, entendo por que usam CockroachDB. O Windmill também precisou criar seu próprio algoritmo de sharding para escalar horizontalmente em instâncias de clientes muito grandes.
    O Maestro é Apache 2.0, enquanto o Windmill usa a AGPL, menos amigável. Com o apoio da Netflix, o financiamento deles é praticamente ilimitado; nós, embora sejamos lucrativos, somos uma empresa muito menor.
    O Maestro não tem documentação suficiente para self-hosting baseado em Kubernetes ou docker-compose, e não há uma UI para criar coisas, ou isso ainda não aparece claramente na documentação. Ainda assim, no geral é bem legal que tenha sido lançado como open source, e vamos continuar acompanhando e fazer benchmarks assim que possível.

    • Se você está considerando o Windmill, deve ver isto primeiro: https://www.windmill.dev/docs/advanced/local_development
      Não entendo por que é preciso “sincronizar” com o Windmill, por que há um IDE dentro do Windmill, nem por que é tão complicado. Parece que começaram mirando em efeito de aprisionamento antes mesmo de criar um bom produto ou encontrar aderência ao mercado.
    • A comparação é boa, mas, mesmo que o Maestro tenha licença Apache, se depende do CockroachDB isso não é tão bom, porque o próprio CockroachDB não é open source.
      Na minha visão, uma base de código AGPL ainda é melhor do que uma dependência que não é open source. Claro que, com o tempo, alguém pode adicionar suporte a bancos de dados alternativos.

  • Estou um pouco confuso sobre o que está acontecendo aqui. Este projeto parece usar Netflix/conductor [0]. Mas, ao acessar esse repositório, ele está arquivado e há uma mensagem dizendo que foi substituído por uma versão interna não open source da Netflix e por um fork comunitário não mencionado. Imagino que isso se refira ao Orkes Conductor [1].
    Mas este projeto não parece usar o Orkes Conductor; parece usar a versão descontinuada da Netflix, com.netflix.conductor:conductor-core:2.31.5 [2]. E é uma versão antiga.
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

  • Fico curioso se alguém aqui já usou o ActiveBatch. Para mim, é o melhor software para o qual eu gostaria que existisse um equivalente voltado a usuários não corporativos.
    Continuei tentando usar outros “concorrentes”, mas com o ActiveBatch basta conectar um banco MS SQL simples, instalar a GUI para Windows e os agentes de execução, e com alguns cliques você tem um ambiente de automação sólido baseado em GUI. Não é preciso escrever código, e, se quiser, você também pode escrever código em qualquer linguagem.
    O Airflow pode ser poderoso, mas fica escondido atrás de uma barreira de complexidade, então a maioria das pessoas não consegue ver suas verdadeiras capacidades, sejam elas quais forem. O mesmo vale para outros concorrentes “open source”.
    Não entendo por que alguém não consegue criar um sistema robusto, baseado em banco de dados e com GUI em primeiro lugar. Também experimentei serviços online, mas nem se comparam. Talvez produtos pagos mais simples fracassem por causa do custo de manter extensões.
    É uma pena que o ActiveBatch esteja preso atrás de um modelo idiota de vendas corporativas. Isso impede que esse excelente software se espalhe por uma comunidade mais ampla. Parece um segredo escondido.

  • Meu conselho: é melhor não depender de ferramentas que a Netflix lança como open source. Eles têm um longo histórico de anunciar algo e depois abandonar o suporte.
    Alguém provavelmente ganhou um item marcado na ficha de avaliação para promoção com esse post no blog e a publicação do código, mas você não deveria construir um negócio em cima de soluções como essa.

  • Não entendo por que considerar isso em vez de algo mais estabelecido como o Temporal. O Maestro foi escrito em Java, e o Temporal parece ter sido escrito em Go

    • O código Go do Temporal é meio estranho. Antigamente acho que usavam Java, mas mudaram para Go, e esse Go parece muito com Java
      Ou talvez eu não conheça bem o Fx
      https://github.com/temporalio/temporal/blob/main/service/mat...
      O problema em que esbarrei repetidamente com o Temporal é que a documentação é muito insuficiente. É algo que você instala no núcleo do negócio, mas é realmente difícil entender o que está acontecendo de fato depois de passar por várias camadas e uma documentação muito obscura
      O Maestro parece não ter documentação. Se for assim, o Temporal vence por padrão
    • A Netflix também usa Temporal: https://temporal.io/in-use/netflix
    • Acho que o Maestro não é uma alternativa ao Temporal, mas sim ao Airflow. O Temporal não é um orquestrador de workflows. Há sobreposições na estrutura interna, mas são designs diferentes para casos de uso diferentes
    • Parte do núcleo do Temporal não foi reescrita em Rust?

  • Parece um projeto realmente bom. Em praticamente todos os projetos híbridos de ML + engenharia de dados em que trabalhei, já pensei em criar algo quase igual a isso, talvez uma versão pior
    Estou ansioso para testar diretamente

  • Como estou criando o orchestra nessa área, deixando aqui minha opinião: tornar open source e desenvolver publicamente é sem dúvida ótimo. Mas isso, como eles mesmos dizem, é um orquestrador, e já existem muitos anteriores, incluindo o Airflow
    Então é difícil ver o que isso realmente acrescenta a essa área, além de adicionar mais uma opção que ninguém vai usar em um ambiente comercial
    Divulgação descarada: https://getorchestra.io

  • Fico curioso se isso é significativamente diferente do Conductor, que foi arquivado no passado. Dando uma olhada no código, vejo bastantes semelhanças, e o uso de JSON como linguagem de definição de workflow também é igual