Windmill - o mecanismo de workflow open source com self-hosting mais rápido

• O Windmill comprovou por meio de benchmarks que é o mecanismo de workflow open source com self-hosting mais rápido quando comparado a outros mecanismos de workflow como Airflow, Prefect e Temporal
• O Windmill oferece suporte a várias linguagens de programação e fornece um ambiente de desenvolvimento integrado no qual é possível criar e testar workflows em poucos minutos, sem SDKs complexos nem processos de deploy
• Airflow/Prefect suportam apenas um runtime (Python), mas o Windmill suporta Python, Typescript, Go e Bash, além de consultas SQL diretas para BigQuery, Snowflake, Mysql e Postgresql
• Em comparação com o Temporal, o Temporal é especializado em gerenciamento de filas de tarefas, enquanto o Windmill também funciona como um mecanismo de execução durável, incluindo recursos de espera por eventos (reatividade)

Diferença entre mecanismos de workflow e filas de tarefas

• A fila de tarefas é o núcleo de um mecanismo de workflow, e muitos desenvolvedores constroem sua própria lógica para usar filas de tarefas sem usar um mecanismo de workflow
• Já existem várias implementações de fila, como SQS, Kafka, Redis with RMSQ e Orban
• Muitos desenvolvedores constroem sua lógica em torno de filas de tarefas e sentem uma satisfação parecida com a de um mecanismo de workflow (como se estivessem criando seu próprio mecanismo de workflow)

O que é um mecanismo de workflow "all-inclusive"

• Um mecanismo de workflow coordena workflows em um sistema distribuído para concluir tarefas, respeitando as restrições de dependência entre elas
• 5 principais benefícios de um mecanismo de workflow:
  • Alocação de recursos: é possível aproveitar ao máximo um cluster, atribuir cada tarefa a workers diferentes com recursos distintos (CPU, memória, GPU) e garantir que todos os recursos do worker possam ser usados pela tarefa
  • Processamento paralelo: quando algumas etapas podem ser executadas em paralelo devido às restrições do workflow (branches, for-loops), o mecanismo de workflow pode despachar essas etapas não apenas para threads, mas também para vários workers fisicamente separados
  • Observabilidade: cada tarefa tem um ID exclusivo e pode ser observada individualmente, incluindo inspeção de entradas, logs, saídas e estado
  • Durabilidade: se uma máquina parar por um motivo inesperado ou ocorrerem efeitos colaterais, o workflow precisa ser reiniciado
    • O workflow deve poder reiniciar o mais rápido possível quando ocorrer um evento inesperado, e uma forma de alcançar isso é a idempotência, em que executar a mesma tarefa várias vezes produz o mesmo efeito que executá-la uma única vez
    • Em caso de incerteza, reproduzir todo o fluxo sem gerar resultado. Isso geralmente é implementado com arquivos de log e SDKs que pulam efeitos colaterais quando o ID exclusivo anexado à tarefa faz parte do log
    • Outra forma é criar snapshots transacionais do estado do fluxo e salvar o estado após cada tarefa. Para reiniciar, basta recarregar o último estado e continuar dali
    • O Windmill usa esta última abordagem e assume que a idempotência pode ser implementada no espaço do usuário quando desejado
  • Reatividade: pausar o fluxo até que ele seja retomado com base em eventos como webhooks ou aprovações

O segredo da velocidade do Windmill

• O Windmill usa Postgresql e Rust para maximizar a eficiência por meio de um design simples e otimizações

Design do sistema e fila

• O Windmill fornece um único binário compilado em Rust, e os workers e o servidor se conectam ao Postgresql, mas não entre si
• A fila é implementada no próprio Postgresql, e as tarefas podem ser acionadas externamente via API

Estado

• Os mecanismos de workflow representam tarefas como uma máquina de estados finitos (FSM), e o Windmill trata o fluxo inteiro como uma FSM

Transferência de dados

• O Windmill oferece vários métodos para transferência de dados, como expressões JavaScript, compartilhamento de pasta temporária e integração com S3

Eficiência dos workers

• Os workers do Windmill processam uma tarefa por vez e executam tarefas sem contêineres para melhorar o desempenho

Conclusão

• O Windmill é um runtime e plataforma serverless open source com self-hosting que oferece altíssima velocidade com base em Postgresql e Rust, por meio de um design simples e otimizações

Opinião do GN⁺

O ponto mais importante deste texto é que o Windmill suporta várias linguagens de programação e fornece um ambiente de desenvolvimento integrado para criar e testar workflows rapidamente, sem SDKs complexos nem processos de deploy. Essas características são muito úteis para desenvolvedores de software, e o desempenho rápido e a eficiência do Windmill podem ajudá-los a lançar produtos melhores com mais rapidez. O texto traz pontos interessantes para desenvolvedores, especialmente para quem deseja construir seu próprio mecanismo de workflow ou otimizar um mecanismo existente.

[xguru]

Windmill - plataforma open source para criar apps internos e automações em empresas, baseada em Python

Foi mostrado discretamente em maio do ano passado, mas o desenvolvedor disse que ainda não estava pronto para tornar público e comentou algo como “vou fazer a entrevista do YC em 10 minutos!”... depois escreveu nos comentários que tinha sido aprovado no YC.
Depois de passar pelo YC e tocar o projeto por um ano e meio, finalmente lançou o produto oficialmente.

[GN⁺]

Opiniões no Hacker News

• Parece que os desenvolvedores do Windmill seguiram exatamente o oposto do conselho de "faça uma coisa bem feita". Mesmo olhando o Windmill.dev, não fica claro para que o software serve. Fica confuso se ele compete com Retool, Airflow e Temporal, se é um construtor de workflows no-code, um construtor de UI drag-and-drop, uma IDE online ou uma plataforma com inúmeras integrações.
• Fico em dúvida se a velocidade de um motor de workflow realmente importa depois de certo ponto. Como muitos workflows incluem tarefas de longa duração, o mais importante é multitenancy, ou seja, a capacidade de suportar quantos trabalhos o usuário quiser, enquanto cada um é agendado e executado como se fosse o único no motor de workflow.
• Quero mover processos de negócio que hoje vivem em planilhas, e-mails pessoais e na memória do gerente para formulários web, uploads, e-mails automatizados e dashboards. Olhei Airtable, Smartsheet, Budibase etc., mas parecem mais focados em gestão de projetos e não me satisfizeram em integração com calendário, e-mail ou scripts agendados. Consigo programar se houver ou se for necessária uma API para os dados, e prefiro uma abordagem low-code em que o gerente possa fazer parte do trabalho de UI com uma visualização em planilha, enquanto o programador cuida das integrações.
• Fico surpreso que as pessoas gastem tanto tempo e esforço escrevendo textos e nunca usem um corretor ortográfico sequer uma vez. Em 2023, fico me perguntando se ainda há gente usando editores de texto que não fazem verificação ortográfica básica por padrão.
• É confuso dizer que é open source e ao mesmo tempo ter um limite de 10 usuários para SSO. Open source normalmente permite modificar o código, então fico me perguntando como esse limite de 10 pessoas é imposto. Dei uma olhada no código-fonte e há código de verificação de licença. Se é open source, qualquer um não poderia simplesmente remover esse código? Se não for possível modificar, então isso é "source-available", não "open source". O projeto parece legal e eu queria sugeri-lo ao meu chefe, mas não sei como explicar essa parte.
• Acompanho o Windmill desde o lançamento no HN e comecei a usá-lo mais intensamente há menos de um ano. O servidor no Discord é muito ativo, e o Ruben responde e corrige bugs em poucos minutos, até nos fins de semana.
• Quero usar o sistema do Windmill, mas estou hesitando por causa da licença. A maior parte do software está sob AGPLv3, mas a seção de licença comercial no README sugere uma interpretação ampla da AGPL. Dizer que, para construir funcionalidades por meio do Windmill, o seu produto também precisa ser AGPLv3 implica que até chamadas feitas apenas via API poderiam estar sujeitas à lei de direitos autorais. Isso faz com que posicionar o Windmill como "totalmente open source" seja tecnicamente correto, mas na prática mais próximo de "source-available". Se o Windmill não quer que a licença seja interpretada dessa forma, precisa deixar isso claro.
• O Windmill é excelente. Ele pode ser self-hosted e parece muito fiel à experiência do desenvolvedor (Developer Experience, DX). Nunca precisei usá-lo no trabalho, mas em casa uso para rodar pequenos crawlers web e tarefas com yt-dlp. É uma ferramenta bem divertida.
• Estou confuso com a licença.
• Ainda não encontrei uma boa forma de equilibrar armazenar código no banco de dados e editá-lo por meio de uma IDE web versus versioná-lo em Git e só alterá-lo por meio do processo normal de desenvolvimento e revisão por pares. O Windmill armazena código principalmente no banco, mas oferece uma API para sincronizar com um repositório Git. Fico curioso se existe algum mecanismo para impor regras que restrinjam scripts/funcionalidades/segredos específicos apenas a workflows importados de um repositório fornecido.