Dependendo da sua política, a economia trickle-down nunca funcionou tão bem nos Estados Unidos sob o presidente Ronald Reagan. No software de código aberto, entretanto, parece estar indo bem.
Na verdade, não estou falando de políticas econômicas, é claro, mas sim de equipes de engenharia de software de elite lançando códigos que acabam alimentando o mainstream não tão elitista. Veja o exemplo da Lyft, que lançou o popular projeto Envoy. Ou o Google, que deu ao mundo o Kubernetes (embora, como argumentei, o objetivo não fossem sutilezas de caridade, mas sim uma estratégia corporativa para flanquear a AWS dominante). O Airbnb descobriu uma maneira de ir além da orientação em lote cron agendamento, presenteando-nos com Apache Airflow e pipelines de dados como código.
Hoje, uma grande variedade de empresas convencionais depende do Airflow, do Walmart à Adobe e ao Marriott. Embora sua comunidade inclua desenvolvedores de Snowflake, Cloudera e outros, a maior parte do trabalho pesado é feita por engenheiros da Astronomer, que emprega 16 dos 25 principais committers. A Astronomer faz bom uso dessa administração e conhecimento, operando um serviço Airflow totalmente gerenciado chamado Astro, mas não é o único. Não é de surpreender que as nuvens tenham sido rápidas em criar os seus próprios serviços, sem código proporcional, o que aumenta a preocupação com a sustentabilidade.
Esse código não se escreverá sozinho se não puder se pagar.
Afinal, o que é um pipeline de dados?
Hoje todo mundo está falando sobre grandes modelos de linguagem (LLMs), geração aumentada de recuperação (RAG) e outras siglas de IA generativa (genAI), assim como há 10 anos não nos cansávamos de Apache Hadoop, MySQL, etc. mudam, mas os dados permanecem, com a preocupação sempre presente sobre a melhor forma de mover esses dados entre sistemas.
É aqui que entra o Airflow.
De certa forma, o Airflow é como um sistema seriamente atualizado cron agendador de tarefas. As empresas começam com sistemas isolados, que eventualmente precisam ser interligados. Ou melhor, os dados precisam fluir entre eles. Como indústria, inventámos todos os tipos de formas de gerir estes pipelines de dados, mas à medida que os dados aumentam, os sistemas para gerir esses dados proliferam, para não mencionar a sofisticação cada vez maior das interações entre estes componentes. É um pesadelo, como escreveu a equipe do Airbnb ao abrir o código-fonte do Airflow: “Se você considerar uma equipe de dados de tamanho médio e de ritmo acelerado por alguns anos em uma infraestrutura de dados em evolução e tiver uma rede extremamente complexa de trabalhos de computação em suas mãos , essa complexidade pode se tornar um fardo significativo para as equipes de dados gerenciarem, ou mesmo compreenderem.”
Escrito em Python, o Airflow fala naturalmente a linguagem dos dados. Pense nisso como um tecido conjuntivo que oferece aos desenvolvedores uma maneira consistente de planejar, orquestrar e compreender como os dados fluem entre cada sistema. Uma parcela significativa e crescente das empresas Fortune 500 depende do Airflow para orquestração de pipeline de dados e, quanto mais o utilizam, mais valioso ele se torna. O Airflow é cada vez mais crítico para as cadeias de fornecimento de dados empresariais.
Então, voltemos à questão do dinheiro.
O código não vai se escrever sozinho
Há uma comunidade sólida em torno do Airflow, mas talvez 55% ou mais do código seja contribuído por pessoas que trabalham para o Astronomer. Isto coloca a empresa numa excelente posição para apoiar o Airflow na produção dos seus clientes (através do seu serviço gerido Astro), mas também coloca o projecto em risco. Não, não do Astrônomo exercendo influência indevida no projeto. Os projetos da Apache Software Foundation são, por definição, nunca projetos de uma única empresa. Em vez disso, o risco advém do facto de o Astrónomo decidir potencialmente que não pode justificar financeiramente o seu nível de investimento.
É aqui que as alegações de “puxar o tapete do código aberto” perdem a sua potência. Como argumentei recentemente, temos um problema de carona de um trilhão de dólares no código aberto. Sempre tivemos alguma semelhança com esse problema. Nenhuma empresa contribui com fins de caridade; é sempre uma questão de interesse próprio. Um problema é que pode levar muito tempo para as empresas compreenderem que o seu interesse próprio deve obrigá-las a contribuir (como aconteceu quando a Elastic mudou a sua licença e a AWS descobriu que tinha de proteger milhares de milhões de dólares em receitas através do fork do Elasticsearch). Este reconhecimento tardio é agravado quando outra pessoa paga a conta do desenvolvimento.
É muito fácil deixar outra pessoa fazer o trabalho enquanto você obtém lucro.
Considere o Kubernetes. É justamente considerado um exemplo da comunidade, mas veja como são concentradas as contribuições da comunidade. Desde o início, o Google contribuiu com 28% do código. O próximo maior contribuidor é a Red Hat, com 11%, seguida pela VMware com 8%, depois pela Microsoft com 5%. Todos os outros são um erro de arredondamento relativo, incluindo AWS (1%), que supera todos os outros em termos de receita obtida com o Kubernetes. Isso é totalmente justo, pois a licença permite. Mas o que acontecerá se o Google decidir que não é do interesse da empresa continuar desenvolvendo tanto para o benefício dos outros?
Uma possibilidade (e os dados dos contribuidores podem apoiar esta conclusão) é que as empresas recalibrem os seus investimentos. Por exemplo, nos últimos dois anos, a participação do Google nas contribuições caiu para 20% e a da Red Hat caiu para 8%. A Microsoft, por sua vez, aumentou a sua participação relativa nas contribuições para 8%, e a AWS, embora ainda relativamente pequena, saltou para 2%. Talvez boas comunidades sejam autocorretivas?
O que nos traz de volta à questão dos dados.
É o mundo do Python
Como o Airflow é construído em Python, e Python parece ser a segunda linguagem de todo desenvolvedor (se não a primeira), é fácil para os desenvolvedores começarem. Mais importante, talvez, também seja fácil para eles parar de pensar em pipelines de dados. Os engenheiros de dados não querem realmente manter pipelines de dados. Eles querem que o encanamento fique em segundo plano, por assim dizer.
Como fazer isso acontecer não é imediatamente óbvio, especialmente considerando o caos absoluto do cenário atual de dados/IA, conforme capturado pela FirstMark Capital. O Airflow, especialmente com um serviço gerenciado como o Astronomer's Astro, torna mais fácil preservar a opcionalidade (muitas opções no gráfico FirstMark) enquanto agiliza a manutenção de pipelines entre sistemas.
Este é um grande negócio que continuará crescendo à medida que as fontes de dados proliferarem. Esse “grande negócio” deveria aparecer mais na tabela de contribuidores. Hoje, os desenvolvedores do Astronomer são a força motriz por trás dos lançamentos do Airflow. Seria ótimo ver outras empresas aumentarem suas contribuições também, proporcionalmente à receita que sem dúvida obterão do Airflow.
