Automatizar processos de dados costuma significar conectar diferentes ferramentas, configurar agendadores, gerenciar filas, acompanhar execuções e ainda descobrir onde uma etapa falhou quando alguma coisa dá errado.
Um novo projeto open source está tentando reduzir essa complexidade ao colocar boa parte dessa infraestrutura em um único runtime desenvolvido em Go.
O Brevis.sh, projeto da Aretê Academy, combina orquestração de workflows, transformação de dados, fila persistente, scheduler e uma interface operacional em um único binário. O código está disponível publicamente sob licença MIT.
A ideia: menos ferramentas para coordenar
Em arquiteturas tradicionais de dados, uma equipe pode acabar utilizando diferentes componentes para resolver problemas específicos: uma ferramenta para agendamento, outra para execução, outra para filas, outra para observabilidade e diferentes runtimes para os processos.
A proposta do Brevis é reduzir essa dispersão.
O workflow pode ser descrito em um arquivo YAML versionável, onde são definidos os passos, dependências, imagens utilizadas e regras de execução. O próprio projeto defende uma abordagem declarativa: o arquivo descreve o pipeline e o runtime executa aquilo que foi definido.
Isso permite que um pipeline de dados seja tratado de maneira semelhante ao código da aplicação.
Em vez de configurar diversas telas e serviços, uma alteração no workflow pode ser revisada diretamente como uma mudança no arquivo.
Cada etapa pode ter seu próprio ambiente
Um dos pontos mais interessantes da arquitetura está na forma como os workflows são executados.
No Kubernetes, cada etapa do workflow pode se transformar em um pod independente, utilizando a imagem de container declarada naquele passo. Dessa forma, diferentes tecnologias podem participar do mesmo pipeline sem necessariamente compartilhar o mesmo ambiente de execução.
Um fluxo pode, por exemplo, utilizar:
- Go para uma etapa de extração;
- Python para preparação dos dados;
- dbt para transformação;
- outro container para carregamento;
- Kubernetes para isolar a execução de cada etapa.
O projeto chama essa abordagem de “o trabalho traz seu próprio runtime”.
Na prática, isso significa que trocar a versão de uma ferramenta em uma etapa não precisa obrigatoriamente alterar o ambiente das outras etapas.
Workflows definidos em YAML
A configuração declarativa é outro elemento central.
Um workflow pode definir seu agendamento, tipo de execução e dependências entre etapas. O projeto suporta tanto fluxos sequenciais quanto estruturas em formato de DAG (Directed Acyclic Graph), permitindo representar dependências entre diferentes tarefas.
Um exemplo simplificado disponibilizado pelo projeto utiliza um workflow diário em que uma etapa de extração precisa terminar antes que uma etapa de transformação baseada em dbt seja executada.
Isso abre espaço para cenários comuns em engenharia de dados, como:
API → extração → processamento → transformação → banco de dados → relatório
Tudo isso pode ser representado como um workflow versionável.
Scheduler, fila e execução no mesmo projeto
Outro diferencial está na tentativa de concentrar diferentes responsabilidades dentro do mesmo runtime.
O projeto possui um scheduler responsável por materializar as execuções programadas, enquanto uma fila persistente fica responsável pela execução dos trabalhos. Os dois processos são independentes, permitindo que um deles seja reiniciado sem necessariamente perder o contexto do outro.
Também existem recursos para:
- agendamento por cron;
- retries persistentes;
- backfill de períodos anteriores;
- parâmetros de execução;
- controle de concorrência;
- histórico de execuções;
- métricas;
- logs;
- monitoramento dos workflows.
Esse conjunto aproxima o projeto de uma pequena plataforma de data engineering, e não apenas de uma ferramenta de cron.
Uma interface para acompanhar os workflows
A proposta também tenta resolver outro problema comum em automações: descobrir o que está acontecendo.
O Brevis possui uma interface operacional integrada ao próprio binário. Ela apresenta métricas, histórico de execuções, workflows, estados das etapas e uma visualização em DAG para acompanhar o processamento.
Isso evita a necessidade de instalar uma aplicação separada apenas para visualizar o estado dos pipelines.
A interface também permite pesquisar e filtrar workflows, pausar execuções e disparar determinados processos manualmente.
Não é apenas uma ferramenta de Kubernetes
Embora Kubernetes seja uma parte importante da arquitetura, o projeto não depende exclusivamente dele para funcionar.
O mesmo workflow pode ser executado localmente como processo, enquanto em ambientes Kubernetes cada etapa pode ser transformada em um pod com sua própria imagem.
Essa característica pode ser interessante para equipes que querem desenvolver e testar pipelines localmente antes de levá-los para uma infraestrutura de produção.
SDK para trabalhar com dados
O projeto também disponibiliza um SDK em Go para construção das etapas dos workflows.
Entre os recursos estão mecanismos para extração HTTP com retry, timeout, proteção contra determinados problemas de execução e paginação, além de carregamento em lote para bancos e destinos como BigQuery, PostgreSQL, MySQL, Redshift e arquivos.
Isso coloca o projeto em uma área bastante interessante entre ETL, ELT, data pipelines e infraestrutura de dados.
Open source como parte da proposta
Um dos pontos que mais chama atenção é que o projeto não apresenta o código aberto apenas como uma versão gratuita.
O site afirma que o runtime é 100% open source, permitindo leitura, uso, adaptação e contribuição da comunidade. O repositório utiliza a licença MIT.
Para desenvolvedores e empresas, isso significa que é possível estudar a implementação, adaptar a infraestrutura às próprias necessidades e até utilizar o projeto como base para soluções internas.
O código também permite entender como uma arquitetura desse tipo é construída em Go, desde o processamento dos workflows até scheduler, filas, execução em containers e interface operacional.
Uma alternativa para quem quer reduzir a complexidade
O grande diferencial da proposta não está necessariamente em inventar cada componente utilizado pelo projeto.
Schedulers, filas, containers, DAGs e ferramentas de transformação já fazem parte do ecossistema de engenharia de dados.
A ideia é outra: reunir essas peças em uma infraestrutura mais coesa.
Para equipes pequenas ou projetos que não querem administrar uma grande quantidade de serviços, essa abordagem pode ser especialmente interessante.
Em vez de montar uma arquitetura com várias ferramentas diferentes desde o início, o desenvolvedor pode partir de um runtime único e adicionar complexidade somente quando ela realmente for necessária.
Por que vale acompanhar o projeto?
O crescimento da quantidade de dados processados pelas aplicações também aumenta a necessidade de pipelines confiáveis e automatizados.
Nesse cenário, projetos open source que tentam simplificar workflows, ETL, orquestração de dados e infraestrutura Kubernetes podem ganhar espaço entre desenvolvedores que procuram alternativas mais leves e controláveis.
O Brevis.sh ainda é um projeto em evolução, mas sua proposta é clara: reduzir a quantidade de infraestrutura necessária para transformar, agendar, executar e observar workflows de dados.
Para quem trabalha com Go, Kubernetes, DevOps, Data Engineering ou automação de processos, vale acompanhar o projeto e explorar seu código.
O repositório está aberto no GitHub, junto com documentação, exemplos e SDK para desenvolvimento.
Projeto: Brevis.sh
Tecnologias: Go, Kubernetes, Docker, YAML
Categoria: Open Source / Data Engineering / DevOps
Licença: MIT
Para conhecer a implementação, a documentação e os exemplos, o projeto pode ser explorado diretamente no GitHub e no site oficial do Brevis.sh.
