O CI mais rápido que construímos fracassou
(earthly.dev)- Em vez de competir de frente com fornecedores já estabelecidos no mercado de ferramentas de CI/CD, a Earthly focou na velocidade de build, encerrou o Earthly CI e voltou a concentrar esforços no Earthly e no Satellites
- A visão original era unificar sistema de build e CI e executá-los de forma distribuída, oferecendo paralelismo automático, cache e reprodutibilidade local ao mesmo tempo
- Earthly e Earthly Satellites validaram respectivamente consistência de build e pipelines de CI 2 a 20 vezes mais rápidos, mas um produto de substituição completa de CI não gerou adoção suficiente
- Novos clientes viam como altos o custo de migração e o peso de reescrever scripts, enquanto clientes atuais do Satellites já obtinham 95% do valor do Earthly CI usando combinações de CI existentes como GitHub Actions
- O Earthly CI será encerrado em 1º de outubro de 2023, e a Earthly passará a investir no Satellites para que usuários obtenham builds rápidos sem trocar seu CI atual
Encerramento do Earthly CI e mudança de foco
- A Earthly está encerrando o Earthly CI e reorganizando a empresa em torno do Earthly e do Earthly Satellites
- Daqui para frente, o foco se reduz a dois valores
- builds locais e reprodutibilidade
- Earthly Satellites para uso junto com CIs existentes
- O Earthly CI tinha como objetivo oferecer CI rápido, mas não conseguiu gerar sinais suficientes de adoção inicial no mercado
A visão original do “CI mais rápido”
- A Earthly começou em abril de 2020 com o objetivo de melhorar as ferramentas de CI/CD
- O ponto de partida eram duas perguntas
- como seria um CI se ele pudesse rodar também no notebook
- como seria o sistema de CI mais rápido do planeta
- A resposta encontrada pela Earthly foi que o sistema de build e o CI deveriam ser a mesma coisa e, ao mesmo tempo, distribuídos
- O objetivo era não repetir etapas de build não afetadas por mudanças, oferecer execução paralela automática e permitir reproduzir com confiabilidade qualquer parte do build no notebook
Como uma equipe pequena compete com fornecedores de CI já estabelecidos
- Para uma startup em estágio inicial, é difícil competir em acabamento, número de recursos e amplitude de integrações com empresas estabelecidas que têm capital, equipe, reputação e mais de 10 anos de vantagem
- A estratégia escolhida pela Earthly foi, em vez de convencer o mercado inteiro, entregar uma solução 10 vezes melhor para um pequeno número de equipes com um problema muito intenso
- A validação inicial se parece com o surgimento de um pequeno grupo de usuários que usam o produto com entusiasmo, mesmo com bugs e limitações
- Quando um MVP não obtém validação suficiente, simplesmente adicionar mais recursos tende a puxar a disputa para um terreno em que os incumbentes levam vantagem
O plano em 3 etapas rumo ao Earthly CI
- Em vez de construir diretamente o Earthly CI, que era o objetivo final, a Earthly dividiu a proposta em vários produtos independentes e tentou validar cada etapa
-
Etapa 1: Earthly
- O primeiro marco foi o Earthly
- O Earthly primeiro entregou a sintaxe de build e a experiência de execução de builds sob demanda
- Seu valor principal era a consistência de build, fazendo com que o build rodasse da mesma forma independentemente do ambiente de execução
- No início ele rodava localmente e em outros CIs, e depois passou a ser usado em milhares de repositórios
- VMware, Adobe, Namely, Roche, ExpressVPN e Bluecore são citadas como usuárias
- Era um projeto sem financiamento, desenvolvido por uma pessoa, com bugs e restrições, mas o fato de as pessoas realmente o usarem serviu como sinal de validação
-
Etapa 2: Earthly Satellites
- O segundo marco foi o Earthly Satellites
- O Satellites é um runner remoto que pode ser chamado do notebook ou de qualquer CI
- O valor central era a velocidade de build, acelerando pipelines de CI em 2 a 20 vezes com cache e paralelismo
- Como o Earthly era open source, os usuários já podiam operar por conta própria runners remotos baseados em Buildkit antes do serviço comercial existir e obter efeitos parecidos
- Quando o Satellites gerenciado foi lançado, os usuários passaram a adotar o produto para não precisarem administrar runners remotos por conta própria
- O Satellites inicial tinha bugs, era ineficiente e instável, mas atraiu usuários porque havia poucas alternativas com nível semelhante de velocidade em CI/CD
-
Etapa 3: Earthly CI
- O terceiro marco foi o Earthly CI
- O Earthly CI era a plataforma completa de CI combinando Earthly e Satellites, pensada para competir com CIs como GitHub Actions, CircleCI e Jenkins
- Como o Earthly mirava consistência de build e o Earthly CI mirava velocidade de build, a empresa acreditava que o Earthly gratuito não canibalizaria a monetização do Earthly CI
- Mais tarde, porém, a diferença entre as propostas de valor de consistência versus velocidade acabou se tornando um problema
As barreiras de conversão que apareceram após o lançamento
- O Earthly CI foi lançado, apareceu no TechCrunch e também foram preparados posts de blog para Reddit e HackerNews
- Nas primeiras 1 a 2 semanas após o lançamento, cerca de 50 e-mails entraram na lista de espera, superando a meta
- Havia uma diferença clara entre novos clientes e usuários existentes do Earthly
- Novos clientes muitas vezes viam “CI como tudo igual, mudando só a sintaxe” e não examinavam a diferenciação do Earthly CI com profundidade
- A conversa quase sempre acabava girando em torno do custo de migração de reescrever scripts existentes e se adaptar
- Usuários já existentes do Earthly tinham concluído a migração para Earthfile e experimentado as vantagens do Earthly, então estavam prontos para se tornar defensores internos da ferramenta
- Para novos clientes, a Earthly não tinha reputação suficiente para sustentar a promessa de entregar esses benefícios em larga escala, e era difícil provar em uma chamada curta no Zoom a experiência de “10 vezes mais simples” relatada por usuários existentes
Por que nem os clientes atuais migraram para o Earthly CI
- A maioria dos clientes existentes do Earthly Satellites já usava o Satellites no seu CI/CD
- A Earthly interpretou isso como validação da necessidade do Earthly CI, já que o provedor de CI ficava só com o acionamento do pipeline enquanto a execução real ocorria no Satellites
- Mas os clientes do Satellites já obtinham 95% do valor do Earthly CI
- Em comparação com uma configuração de GitHub Actions + Satellites, o Earthly CI não era melhor o suficiente, então faltavam motivos para migrar
- Como usuários existentes do Earthly já usavam Earthfile, parecia que a mudança seria fácil, mas na prática havia mais exigências
- ecossistema de plugins do GitHub
- action do codecov
- gatilhos manuais
- gatilhos baseados na criação de git tags
- escolha do tamanho da máquina
- cancelamento de builds antigos
- confiança para entregar segredos de build
- O MVP do Earthly CI era o CI mais rápido, mas não atendia alguns requisitos centrais
- Alguns usuários entusiastas testaram o Earthly CI, porém o produto não se expandiu para além de 2 ou 3 pessoas em organizações maiores com orçamento
- Alguns usuários do Earthly CI depois migraram para o Satellites para obter ao mesmo tempo o ecossistema do GitHub e a velocidade do Satellites
Por que pedidos de demo acabaram sendo um sinal negativo
- A Earthly teve mais de 100 chamadas com clientes em potencial, mas era difícil convencer alguém a usar Earthly CI, Satellites ou Earthly apenas por meio de conversas diretas
- Em contrapartida, quando usuários chegavam por conta própria pelo site, crescimento orientado por produto, boca a boca ou marketing de conteúdo, a adoção do Earthly acontecia todos os dias e crescia bastante
- Ferramentas para desenvolvedores, especialmente as que exigem trabalho de integração, são difíceis de validar por vendas diretas tradicionais
- O critério negativo mais forte era o potencial cliente pedir uma demo
- As equipes que realmente convertiam baixavam o Earthly, liam a documentação, escreviam um Earthfile por conta própria e só depois entravam em contato; elas não precisavam de demo
- Ferramentas para desenvolvedores que exigem integração são adotadas no tempo do usuário, e é difícil empurrar a venda ou acelerar artificialmente esse processo
O teste A/B que trocou “CI” por “build”
- Na época, a mensagem do site da Earthly era “Earthly makes CI super simple”, e a maior parte da primeira tela enfatizava CI
- Gavin Johnson sugeriu um teste A/B trocando a palavra “CI” por “build” no site
- O texto passou a ser “Earthly makes builds super simple”
- Essa mudança de uma única palavra dobrou a conversão da página principal de CTA, “Get Earthly”
- Depois desse resultado, a desconfiança em relação ao próprio Earthly CI aumentou
Lições tiradas da experiência com a ShiftLeft
- A ShiftLeft, iniciada antes da Earthly, hoje se chama Qwiet.ai
- A visão inicial era um agente de segurança instalado em produção para proteger aplicações em nuvem contra ataques que explorassem vulnerabilidades no código-fonte
- O produto exigia um analisador de código com suporte a várias linguagens de programação, agentes por runtime e um backend distribuído para integrar tudo, algo parecido com uma startup pequena tentando construir de uma vez a complexidade equivalente a três empresas
- Depois de mais de um ano de esforço, foi possível fazer o fluxo end-to-end funcionar em uma linguagem de programação, mas a reação do mercado foi fraca
- O público-alvo do produto de segurança eram grandes empresas altamente reguladas, e ele precisava ser colocado tanto no CI/CD quanto em produção, o que tornava o caminho de adoção muito difícil
- Na época, a visão era de que adicionar mais recursos poderia superar a dificuldade de adoção, então a equipe passou mais um ano e meio construindo, mas o mercado não queria aquilo
- Só mais tarde perceberam que o produto complexo podia ser dividido em dois produtos diferentes
- um introspector de código para especialistas em segurança
- um analisador de código independente 40 vezes mais rápido do que outros analisadores do mercado
- O maior arrependimento foi não ter parado antes, quando os sinais já estavam presentes
A avaliação final da Earthly
- A Earthly resumiu a situação da seguinte forma
- as pessoas querem builds mais rápidos
- as pessoas não gostam de trocar de CI
- um novo CI carrega o estigma de não ser diferenciado, e os usuários abandonam o site no momento em que veem “CI” na página
- um envolvimento no estilo design partner com contato direto com clientes não funciona por causa da alta percepção de custo de migração
- o MVP do Earthly CI não conseguiu formar um grupo suficientemente forte de adotantes iniciais
- a reação melhora quando se diz que é possível obter builds mais rápidos com Earthly Satellites sem trocar o CI existente
- O problema central não era falta de recursos no Earthly CI
- Um produto inicial promissor precisa ter um grupo disposto a tolerar a ausência de recursos para ainda assim obter os benefícios, mas no caso do Earthly CI não houve sinais suficientes nesse nível
- Por isso, a Earthly decidiu encerrar o Earthly CI e se concentrar no Earthly e no Earthly Satellites, que já estavam funcionando
Cronograma de encerramento e transição dos usuários
- O Earthly CI será encerrado em 1º de outubro de 2023
- O Earthly CI estava marcado como beta/experimental, mas a Earthly dará suporte à transição dos usuários
- Como o Earthly funciona com qualquer CI, a empresa considera fácil migrar para fora do Earthly CI
- Quem quiser continuar com builds rápidos poderá conectar o Earthly Satellites, que também tem um plano gratuito
- O suporte à transição será oferecido diretamente na comunidade Slack da Earthly
Direção futura de investimento no Satellites
- O Earthly Satellites está mostrando sinais de crescimento porque oferece builds rápidos e consistentes e, ao mesmo tempo, permite que os usuários mantenham seu próprio CI
- O tempo liberado com o encerramento do Earthly CI será investido em recursos pedidos pela comunidade da Earthly
- métricas do Satellite, incluindo uso de CPU, memória, disco e I/O de rede
- histórico de builds na interface web tanto para builds locais quanto para builds no Satellites
- Auto-skip, que pula imediatamente quando arquivos alterados não afetam o build
- recurso para executar remotamente builds de Dockerfile no Satellites como alternativa rápida ao
docker build - self-hosted Satellites, uma versão melhor suportada do self-hosted remote Buildkit
- recurso para distribuir um único build entre vários Satellites e aumentar a velocidade
- Compute v2, um Satellites totalmente distribuído e serverless
- O Earthly Satellites é um runner remoto de build que funciona com qualquer CI e pode ser usado via Earthly Cloud
- O Earthly é um framework de build open source que oferece consistência de build com a proposta de escrever uma vez e executar em qualquer lugar, além de facilitar a reprodução local de falhas de CI
1 comentários
Comentários do Hacker News
Um texto que mostra bem por que não se deve entregar todo o valor central ao abrir o código. Como o Earthly era open source, os usuários do Earthly Satellite já desfrutavam de 95% do valor do Earthly CI.
Gosto muito de open source, mas, se o modelo de negócios inclui open source, é preciso ter um diferencial. Além de simplesmente ser muito rápido, é preciso haver um motivo para as pessoas tirarem o cartão de crédito, ou até passarem pelo processo contábil de pedido de compra.
O GitLab limita CI/CD a clientes pagantes, Travis/CircleCI limitam tempo de build ou créditos, o Azure DevOps é diabólico, e o ArgoCD é complexo. O GitHub Actions é ok se você tiver hardware para rodar os runners, e, em empresas, o bando do Jenkins costuma ser familiar.
Como ex-diretor de DevOps, a primeira coisa que eu perguntaria é: “qual funcionalidade me faz comprar em vez de hospedar eu mesmo?” Se eu tenho capacidade técnica para operar por conta própria, vocês precisam me convencer de por que eu deveria pagar a vocês, quando posso operar minha nuvem e meu pipeline de DevOps de acordo com o nosso negócio.
Não estou dizendo para esconder funcionalidades essenciais ao funcionamento do software, mas sim deixar como pagas funcionalidades de negócio, como suporte ou integrações de nível enterprise. Também parece possível um modelo em camadas em que usuários avançados paguem menos, já que dão mais suporte a si mesmos.
Talvez fosse possível converter os usuários restantes em pagantes, mas seria uma aposta bem grande. Um bom contraexemplo recente talvez seja o Docker, mas isso exigiu abandonar o open source estrito e fazer mudanças controversas de licença e produto.
É muito frustrante não poder ler o código fora do “open core”, contribuir com correções de bugs ou auto-hospedar, e os aspectos que distinguem licenças open source de licenças source available não são muito necessários para mim.
Não quero jogar água fria, mas isto é literalmente quase um produto copiado e colado.
Existem Jenkins, Google Borg, Cloud Foundry e Concourse Pipelines, e, vendo a origem, Ex-Google, Ex-VMW e RabbitMQ, isso nem surpreende.
Mesmo que o autor do texto original não estivesse perto das fontes dessas ferramentas, no mínimo era algo como um primo dessa história.
O ciclo de vendas é longo, e integrações exigem aprovação executiva em vários eixos, incluindo segurança e rede.
Eles construíram algo bom, mas o problema upstream é tão multifacetado que pareceu uma história sem muito conteúdo, numa área que vive oscilando entre soluções sob medida e produtos genéricos. Há uma mistura que vai de falta de supervisão a microgerenciamento, de imaturidade a experiência excessiva a ponto de não conseguir largar “o jeito de sempre”.
Talvez seja uma opinião impopular, mas vender uma cadeia de ferramentas equivale a tentar ferver o oceano de problemas. Negócios e tecnologia fluem como água, procurando o buraco de menor resistência, e nesse processo às vezes erodem a base do “negócio principal”. Pela minha experiência, as cadeias de ferramentas que funcionavam como diretrizes ou “estratégias de criação”, com guardrails removíveis, foram as que deram maior retorno.
“Ser rápido” não é um argumento de venda. Desenvolvedores não querem pipelines lentos, mas isso não significa que queiram pipelines rápidos.
A velocidade do pipeline depende muito mais de como ele foi configurado do que do overhead do serviço de pipeline, e outros serviços de CI/CD já são muito rápidos. Por exemplo, até o CircleCI não é fácil de vender em comparação com GitHub Actions e GitLab CI/CD; então, como este serviço se diferenciava? Ele agregava valor real em comparação com GitHub/GitLab/CircleCI etc.? Reduzir milissegundos em builds de alguns minutos não é a resposta.
O motivo do fracasso foi que o marketing era escancaradamente malfeito e bastante desonesto.
Se você usa o mesmo nó de build, o tempo de compilação será o mesmo compilando com Jenkins, Actions ou Earthly. Dizer que é 20 vezes mais rápido quando o CI já começa em poucos segundos não significa muita coisa.
Cache e execução paralela são conceitos antigos em CI, e todos os sistemas de build modernos conseguem fazer isso.
O ponto central do CI é feedback, mas não vi muita coisa sobre colaboração ou sobre trazer dados para cima. Não olhei em detalhes, mas isso deveria estar em primeiro plano. Por fim, não quero nunca mais introduzir uma DSL para builds.
CI rápido significa o quê, afinal?
CI é um script de shell que cresceu demais, que executa builds e avisa quando falham. Em geral, a própria ferramenta de build fica tão lenta que o custo dos executores de CI deveria ser praticamente zero em comparação
Se você quer CI rápido, tsc, clang, rustc etc. é que precisam ser rápidos; não o programa que os chama com
execFalando mais dentro do tema: se você vende CI e o negócio fracassou, é porque não conseguiu entregar valor. As pessoas conseguem rodar scripts de build muito bem sem você
Não é que o programa que chama
execseja mais rápido; é sobre um programa que sabe que, para começo de conversa, nem precisa chamarexecNão sei o que foi medido, mas, para dar um exemplo, a página inicial padrão do Jenkins é um desastre em termos de velocidade. Ela tenta mostrar dados de builds recentes de todo o cluster em vários lugares e, mesmo em um cluster não muito grande, pode precisar buscar centenas ou milhares de itens nos nós individuais que rodam cada build
Já derrubei o Jenkins inúmeras vezes só carregando a página inicial, sem alguma configuração específica para bloquear o comportamento padrão
Servidores de CI normalmente têm seu próprio banco de dados e gerenciam todo tipo de entidade de CI, como jobs, artefatos, usuários e segredos. Isso pode crescer bastante e exige cuidado com indexação adequada etc.
CI tem vários executores, e eles são frequentemente provisionados de forma dinâmica. Pense em distribuir imagens de VM ou Docker para nós executores. Espalhar isso rapidamente pelo cluster também não é trivial. Você provavelmente também vai querer distribuir artefatos por todo o cluster, e isso também consome tempo e recursos
CI também precisa, na prática, de sua própria contabilidade interna para garbage collection, relatórios e autodiagnóstico. Em clusters grandes o suficiente, tudo isso pode gerar latências muito altas se não houver um esforço específico para reduzi-las
Já ouviu falar de ccache?
Mas, falando sério, “basta ter tsc/clang/rustc rápidos” é ingênuo demais. Para acelerar builds em um sistema distribuído como CI, também é preciso resolver como distribuir esse cache e como modularizar os builds. Você já deve ter ouvido dizer que uma das coisas mais difíceis em programação é invalidação de cache, e isso é só parcialmente uma piada
Levei muito tempo ajustando um script bem bagunçado do GitHub Actions, porque o ciclo de depuração era de 10 minutos
Que bom que eles só vão encerrar o serviço, e não fechar a empresa inteira. Eu realmente gostava dessa ferramenta, a ponto de olhar a página de vagas com frequência
A sintaxe do Earthfile é uma evolução muito sensata e incremental da sintaxe do Dockerfile, e facilita muitas coisas que eram impossíveis ou muito estranhas usando apenas Dockerfile
Lembro que, quando o Docker introduziu o BuildKit e o buildx, tentou empurrar o Dockerfile como um sistema de build de uso geral, para produzir não só contêineres, mas também artefatos de arquivo etc. A Earthly realmente implementou bem essa ideia
Uso com satisfação, mas ainda não estou pagando
Só com este texto, sinceramente, foi meio difícil entender o que aconteceu. Li algumas vezes e a terminologia ainda me confundiu. Parece que havia pelo menos dois problemas separados
O problema de migrar a configuração de CI do YAML de CI existente, ou seja, do GitHub/GitLab, para o Earthly, que é uma mistura de Makefile/Dockerfile
O problema de migrar os executores de jobs da CI existente para um serviço hospedado pela Earthly
Eu achava que o primeiro era a parte difícil. Trocar de linguagem pode levar meses ou anos
Mas não entendi bem o que o post do blog está dizendo. Achei que essa parte tinha sido validada; não significa que as pessoas conseguiam fazer a transição?
Só que no fim ele diz que não foi validada. Os clientes tinham que fazer não uma, mas duas migrações?
Então como fica agora? Vão manter a sintaxe do Earthly, mas desistir da CI? A parte difícil de migrar não era justamente essa sintaxe? Continuo confuso
O ponto central é que eles presumiram que builds muito mais rápidos seriam a killer feature, mas não validaram essa suposição antes de construir? Ou foi que não segmentaram bem os usuários e não perceberam que clientes que pagam mais tinham necessidades diferentes? Ou simplesmente entregaram de graça algo que resolvia o problema real dos clientes pagantes?
E, considerando que esse texto um tanto confuso foi escrito pelo CEO, fico me perguntando se a confusão é só falta de edição ou se também houve muita confusão real dentro da empresa durante todo esse processo
Muito tempo atrás, Steve Blank escreveu em “Founders and dysfunctional families” [1] que muitos fundadores cresceram em meio ao caos e, por isso, são bons em gerenciar o caos; isso certamente se aplica a mim. Ele acrescentou que a diferença entre sucesso e fracasso pode depender de o fundador também conseguir lidar com um estado sem caos
Fundadores que não conseguem fazer isso tendem a jogar “granadas organizacionais” na própria empresa para voltar ao nível de caos em que são bons. Essa observação me fez parar para pensar várias vezes ao longo dos anos
[1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
Com o tempo, a CI das pessoas vira um modelo híbrido que encapsula todas as formas como cada empresa constrói e distribui seu software. Pense em uma situação em que a CI é usada indevidamente como um executor de automações arbitrárias, como o Airflow
A migração começa com as pessoas primeiro fazendo engenharia reversa do que já sabiam antes, e só depois disso é que conseguem destrinchar tudo e expressar de outra forma
Ninguém quer parar o mundo para organizar isso
Este texto é confuso porque o autor está perto demais do problema, e precisaria explicá-lo pela perspectiva de alguém de fora antes de entrar nos detalhes. Ainda assim, parece que as informações necessárias estão lá
No fim, parece que eles criaram uma camada de encapsulamento entre os sistemas de build específicos de cada linguagem e o sistema de build contínuo que os executa
Para comparar, existe algo como o Bazel, que faz tudo, mas, para adotá-lo por completo, é preciso apostar tudo em substituir os sistemas de build específicos de cada linguagem pela linguagem de build do Bazel, e muitas vezes também mover arquivos de código-fonte de lugar para fazê-lo funcionar
Isso pode parecer estranho em comparação com o uso dos sistemas de build próprios da linguagem, mas pode ser natural para programadores C, já que C não tem um sistema de build próprio. Java também passou por vários sistemas de build lamentáveis e infelizmente acabou se fixando no Gradle
Sistemas de build específicos de linguagem acabam não fazendo tudo, porque cada linguagem tem convenções e ecossistemas diferentes. Os mais modernos sabem qual é o escopo em que são bons e permanecem nele
Por isso, as ferramentas que realmente entendem várias linguagens e artefatos muitas vezes são scripts de shell, makefiles, Dockerfiles ou o próprio sistema de build contínuo. Às vezes, é até feito manualmente. A camada que eles querem melhorar é exatamente essa
Só que o insight fundamental sobre por que a abordagem deles é melhor ainda não está muito claro
Há algum tempo dei uma olhada rápida no Earthly por causa do trabalho. Eu precisava escrever integrações para várias plataformas de CI, como GitLab, Azure DevOps, Jenkins e talvez até GitHub Actions.
No fim, escolhemos o Dagger, um produto muito parecido: outro bom frontend para o BuildKit que se integrava a vários sistemas de CI, e cuja DSL usada na época para definir pipelines parecia melhor.
Mas acabei me arrependendo profundamente dessa decisão. Os desenvolvedores do Dagger basicamente abandonaram aquela linguagem e seguiram na direção de lançar SDKs para linguagens de programação populares. Todos imperativos, todos Turing-completos e, na minha opinião, pouco adequados para esse domínio.
Então agora estamos de volta ao inferno, integrando manualmente com todos esses sistemas, e fico hesitante em confiar esse tipo de ferramenta a uma startup novamente.
Para mim, esse ainda é o caso de uso mais atraente de algo como o Earthly. “Dar push e ver o que acontece” é praticamente o padrão em quase todos os sistemas de CI, e é um fluxo de trabalho horrível.
Se você precisa dar suporte a equipes que usam diferentes plataformas de CI/CD em uma grande organização, algo como o Earthly pode reduzir bastante a dor. Mas o atrativo não está em adicionar mais um CI, e sim exatamente em dar suporte às plataformas de CI existentes.
O principal problema da antiga implementação em CUE era tentar compatibilizar o solucionador de grafo acíclico direcionado do BuildKit com o solucionador de grafo acíclico direcionado do CUE, e os dois funcionavam em direções opostas.
Cerca de três anos atrás, tentei ajudar a resolver esse problema como especialista em CUE. Acho que, para o Dagger, SDKs são uma solução muito melhor.
Gostando ou não, uma boa parte da indústria está se movendo nessa direção. O Pulumi é outro exemplo. Fui convencido por infraestrutura de nuvem imperativa, e builds também parecem se encaixar nisso até certo ponto.
Como observação adicional, pretendemos explorar uma nova configuração CUE + Dagger, mas ela funcionará de forma diferente do antigo motor do Dagger.
O ponto central é que movemos a camada declarativa de uma configuração CUE estática para consultas GraphQL dinâmicas. E, a partir do schema GraphQL, geramos bibliotecas cliente para várias linguagens.
Assim, você não só pode construir um grafo acíclico direcionado de forma declarativa como antes, como também pode fazer isso em qualquer linguagem de sua preferência. Também é possível executar o DAG diretamente em GraphQL puro. Veja https://play.dagger.cloud, que dá para testar direto no navegador.
Uma analogia útil é SQL. SQL é uma linguagem declarativa, mas normalmente é usada junto com outras linguagens, muitas vezes imperativas.
Espero que essa explicação ajude você a considerar o Dagger mais uma vez.
A expressão “builds 2 a 20 vezes mais rápidos” aparece várias vezes ao longo do texto. Comparado a quê? Sem uma linha de base, essa frase é papo de marketing sem valor.
A parte “por que não simplificar a stack? Em vez de pagar para um fornecedor de CI e para nós, por que não pagar só para nós?” acontece porque o CI pelo qual eles “pagam” vem junto com o resto da stack. GitLab e GitHub têm muito mais do que um simples produto de CI.
Também entendo a parte “pessoas novas olhavam o Earthly CI com ceticismo, achavam que todos os CIs eram iguais e só a sintaxe mudava, e não olhavam mais a fundo”.
Não nos importamos muito com CI em si; apenas precisamos dele e que funcione direito.
Se um app já tem um manifesto de CI funcionando, para um app novo usamos o mesmo manifesto, só fazendo alguns localizar/substituir. Pode haver dor na primeira criação, mas, olhando os exemplos, não parece particularmente mais fácil do que fazer a mesma coisa no GitLab.
Sinceramente, se tivessem incluído um conversor que pegasse uma configuração de CI do GitLab ou GitHub e gerasse um Earthfile na hora, acho que pelo menos teriam conseguido fazer as pessoas testarem.