Unser schnellstes CI ist gescheitert

 (earthly.dev)
1 Punkte von GN⁺ 2023-09-13 | 1 Kommentare | Auf WhatsApp teilen
  • Statt im Markt für CI/CD-Tools direkt mit etablierten Anbietern zu konkurrieren, konzentrierte sich Earthly auf Build-Geschwindigkeit, stellt Earthly CI ein und fokussiert sich wieder auf Earthly und Satellites
  • Die ursprüngliche Vision war, Build-System und CI in einem zu vereinen und verteilt auszuführen, um automatische Parallelität, Caching und lokale Reproduzierbarkeit zugleich zu bieten
  • Earthly und Earthly Satellites konnten sich jeweils mit Build-Konsistenz und 2- bis 20-mal schnelleren CI-Pipelines bewähren, doch ein vollständiges CI-Ersatzprodukt erzielte nicht genügend Umstellung
  • Neue Kunden sahen vor allem die Migrationskosten und den Aufwand zum Umschreiben von Skripten, während bestehende Satellites-Kunden mit ihrer vorhandenen CI-Kombination wie GitHub Actions bereits 95 % des Werts von Earthly CI erhielten
  • Earthly CI wird am 1. Oktober 2023 eingestellt, und Earthly investiert stattdessen in Satellites, damit Nutzer schnelle Builds erhalten, ohne ihre bestehende CI aufzugeben

Einstellung von Earthly CI und neue Fokussierung

  • Earthly stellt Earthly CI ein und richtet das Unternehmen neu auf Earthly und Earthly Satellites aus
  • Künftig konzentriert sich der Nutzen auf zwei Bereiche
    • lokale Builds und Reproduzierbarkeit
    • Earthly Satellites, die sich zusammen mit bestehender CI nutzen lassen
  • Earthly CI zielte auf schnelles CI, konnte am Markt aber keine ausreichenden Signale für frühe Akzeptanz erzeugen

Die ursprüngliche Vision vom „schnellsten CI“

  • Earthly startete im April 2020 mit dem Ziel, CI/CD-Tools zu verbessern
  • Ausgangspunkt waren zwei Fragen
    • Wie würde CI aussehen, wenn es auch auf einem Laptop laufen könnte?
    • Wie würde das schnellste CI-System der Welt aussehen?
  • Earthlys Antwort darauf war, dass Build-System und CI identisch sein müssten und zugleich verteilt laufen sollten
  • Das Ziel war, Build-Schritte, die von Änderungen nicht betroffen sind, nicht zu wiederholen, automatische parallele Ausführung zu bieten und jeden Teil eines Builds auf dem Laptop zuverlässig reproduzierbar zu machen

Wie ein kleines Team mit etablierten CI-Anbietern konkurriert

  • Für ein frühes Startup ist es schwer, bei Reifegrad, Funktionsumfang und Integrationen mit etablierten Anbietern zu konkurrieren, die mehr Kapital, Personal, Ruf und über zehn Jahre Vorsprung haben
  • Earthlys Strategie war deshalb nicht, den Gesamtmarkt zu überzeugen, sondern einer kleinen Zahl von Teams mit besonders schmerzhaftem Problem eine 10-mal bessere Lösung zu geben
  • Frühe Validierung bedeutet eher, dass eine kleine Nutzergruppe das Produkt trotz Bugs und Einschränkungen mit Begeisterung verwendet
  • Wenn ein MVP nicht genügend Validierung erhält, führt das bloße Hinzufügen weiterer Funktionen leicht in einen Wettbewerb, in dem die etablierten Anbieter im Vorteil sind

Der Drei-Stufen-Plan zu Earthly CI

  • Earthly baute nicht sofort Earthly CI als Endziel, sondern teilte die Validierung in mehrere eigenständige Produkte und Etappen auf

  • Stufe 1: Earthly

    • Der erste Meilenstein war Earthly
    • Earthly bot zunächst die Build-Syntax und das Erlebnis einer On-Demand-Build-Ausführung
    • Der zentrale Nutzen war Build-Konsistenz, also dass Builds unabhängig von der Ausführungsumgebung gleich laufen
    • Anfangs lief es lokal und in anderer CI, später wurde es in Tausenden Repositories verwendet
    • Genannt werden VMware, Adobe, Namely, Roche, ExpressVPN und Bluecore als Nutzer
    • Es war ein bootstrapped Ein-Personen-Projekt mit Bugs und Einschränkungen, doch die tatsächliche Nutzung durch Anwender war ein Validierungssignal

  • Stufe 2: Earthly Satellites

    • Der zweite Meilenstein war Earthly Satellites
    • Satellites sind Remote-Runner, die sich von einem Laptop oder jeder beliebigen CI aus aufrufen lassen
    • Der zentrale Nutzen war Build-Geschwindigkeit, die CI-Pipelines durch Caching und Parallelität um das 2- bis 20-Fache beschleunigt
    • Da Earthly Open Source war, konnten Nutzer schon vor dem kommerziellen Service ähnliche Effekte erzielen, indem sie selbst Buildkit-basierte Remote-Runner betrieben
    • Als die verwalteten Satellites erschienen, begannen Nutzer das Produkt zu verwenden, um Remote-Runner nicht mehr selbst verwalten zu müssen
    • Frühe Satellites waren fehlerhaft, ineffizient und instabil, doch weil es nur wenige Alternativen mit vergleichbarer CI/CD-Geschwindigkeit gab, kamen Nutzer trotzdem dazu

  • Stufe 3: Earthly CI

    • Der dritte Meilenstein war Earthly CI
    • Earthly CI war eine vollständige CI-Plattform auf Basis von Earthly und Satellites und sollte mit CI wie GitHub Actions, CircleCI und Jenkins konkurrieren
    • Earthly zielte auf Build-Konsistenz, Earthly CI auf Build-Geschwindigkeit, daher ging man davon aus, dass das kostenlose Earthly die Monetarisierung von Earthly CI nicht kannibalisieren würde
    • Später erwies sich jedoch gerade der Unterschied in der Value Proposition zwischen Konsistenz und Geschwindigkeit als Problem

Hürden bei der Umstellung nach dem Launch

  • Earthly CI wurde gelauncht, in TechCrunch vorgestellt, und es wurden Blogposts für Reddit und Hacker News vorbereitet
  • In den ersten ein bis zwei Wochen nach dem Launch trugen sich rund 50 E-Mail-Adressen in die Warteliste ein und übertrafen damit das Ziel
  • Zwischen neuen Kunden und bestehenden Earthly-Nutzern zeigte sich ein klarer Unterschied
    • Neue Kunden sahen oft nur: „CI unterscheidet sich eigentlich nur in der Syntax“, und prüften die Differenzierung von Earthly CI nicht genauer
    • Die Gespräche drehten sich meist um die Migrationskosten durch das Umschreiben bestehender Skripte und die nötige Anpassung
    • Bestehende Earthly-Nutzer hatten die Umstellung auf Earthfiles bereits hinter sich und die Vorteile von Earthly erlebt, weshalb sie intern eher zu Fürsprechern werden konnten
  • Bei neuen Kunden fehlte Earthly der Ruf, die versprochenen Vorteile in großem Maßstab liefern zu können, und in einem kurzen Zoom-Call ließ sich die Erfahrung bestehender Nutzer, dass es „10-mal einfacher“ sei, schwer belegen

Warum selbst bestehende Kunden nicht zu Earthly CI wechselten

  • Bestehende Earthly-Satellites-Kunden nutzten Satellites meist bereits in ihrem CI/CD-Setup
  • Earthly ging davon aus, dass der Bedarf an Earthly CI validiert sei, weil der CI-Anbieter nur noch Pipeline-Trigger übernehme und die eigentliche Ausführung auf Satellites stattfinde
  • Tatsächlich erhielten Satellites-Kunden aber bereits 95 % des Werts von Earthly CI
  • Im Vergleich zu einer Kombination aus GitHub Actions + Satellites war Earthly CI nicht deutlich genug besser, um einen Wechsel zu rechtfertigen
  • Bei bestehenden Earthly-Nutzern schien die Umstellung leicht, weil sie bereits Earthfiles nutzten, tatsächlich gab es aber weitergehende Anforderungen
    • GitHub-Plugin-Ökosystem
    • codecov action
    • manuelle Trigger
    • Trigger auf Basis der Erstellung von git tags
    • Auswahl der Maschinen-Größe
    • Abbrechen alter Builds
    • das Vertrauen, Build-Secrets anzuvertrauen
  • Das MVP von Earthly CI war das schnellste CI, erfüllte aber einige zentrale Anforderungen nicht
  • Einige besonders motivierte Nutzer probierten Earthly CI aus, doch in größeren Organisationen mit Budget breitete es sich nicht über zwei bis drei Personen hinaus aus
  • Manche Earthly-CI-Nutzer wechselten später zu Satellites, um das GitHub-Ökosystem zusammen mit der Geschwindigkeit von Satellites zu bekommen

Warum Demo-Anfragen sogar ein negatives Signal waren

  • Earthly führte mehr als 100 Gespräche mit potenziellen Kunden, konnte aber in direkten Gesprächen kaum jemanden dazu bewegen, Earthly CI, Satellites oder Earthly tatsächlich zu nutzen
  • Umgekehrt wurde Earthly täglich übernommen und wuchs stark, wenn Nutzer über die Website, Product-Led Growth, Empfehlungen oder Content-Marketing von selbst kamen
  • Entwickler-Tools, besonders solche mit Integrationsaufwand, ließen sich mit klassischem Direktvertrieb nur schwer validieren
  • Das stärkste negative Qualifikationssignal waren potenzielle Kunden, die eine Demo verlangten
  • Teams, die tatsächlich konvertierten, luden Earthly herunter, lasen die Dokumentation, schrieben selbst ein Earthfile und meldeten sich danach — ohne eine Demo zu benötigen
  • Entwickler-Tools mit Integrationsaufwand werden nach dem Zeitplan der Nutzer eingeführt; man kann sie kaum aggressiv verkaufen oder schnell vorantreiben

A/B-Test: von „CI“ zu „build“

  • Die damalige Botschaft auf Earthlys Website lautete „Earthly makes CI super simple“, und der Großteil des Hero-Bereichs betonte CI
  • Gavin Johnson schlug einen A/B-Test vor, bei dem das Wort „CI“ auf der Website durch „build“ ersetzt wurde
  • Der Text änderte sich zu „Earthly makes builds super simple“
  • Durch diese eine Wortänderung verdoppelte sich die Conversion der zentralen CTA „Get Earthly“
  • Danach wurden die Zweifel an Earthly CI selbst größer

Lehren aus der Erfahrung mit ShiftLeft

  • ShiftLeft, das vor Earthly gestartet wurde, heißt heute Qwiet.ai
  • Die frühe Vision war ein Security-Agent, der in Produktion installiert wird, um Cloud-Apps vor Angriffen zu schützen, die Schwachstellen im Source Code ausnutzen
  • Das Produkt benötigte einen Code-Analyzer für mehrere Programmiersprachen, Agents für verschiedene Laufzeiten und ein verteiltes Backend, das alles zusammenführt — in der Komplexität vergleichbar damit, als würde ein kleines Startup gleichzeitig drei Firmen bauen
  • Nach über einem Jahr Arbeit gab es eine End-to-End-Funktion für eine Programmiersprache, doch die Marktreaktion war schwach
  • Die Zielkunden für Security-Produkte waren stark regulierte Enterprise-Unternehmen, und das Produkt musste sowohl in CI/CD als auch in die Produktion eingebracht werden, was den Einführungsweg sehr schwierig machte
  • Damals nahm man an, zusätzliche Funktionen könnten die schwierige Einführung überwinden; nach weiteren anderthalb Jahren Entwicklung wollte der Markt das Produkt aber immer noch nicht
  • Erst spät wurde klar, dass sich das komplexe Produkt in zwei verschiedene Produkte aufteilen ließ
    • ein Code-Introspector für Security-Experten
    • ein eigenständiger Code-Analyzer, 40-mal schneller als andere Code-Analyzer am Markt
  • Die größte Reue war, nicht früher aufgehört zu haben, obwohl die Signale da waren

Zu welchem Schluss Earthly kam

  • Earthly fasste die Situation so zusammen
    • Menschen wollen schnellere Builds
    • Menschen hassen es, ihre CI umzustellen
    • Neue CI hat das Stigma, nicht differenziert zu sein, und Nutzer springen schon ab, sobald sie auf der Website „CI“ sehen
    • Design-Partner-artige Zusammenarbeit über direkten Kundenkontakt funktioniert wegen der hohen wahrgenommenen Migrationskosten nicht
    • Das MVP von Earthly CI konnte keine ausreichend große Gruppe früher Anwender aufbauen
    • Die Reaktion wird besser, wenn man sagt, dass sich mit Earthly Satellites schnellere Builds erreichen lassen, ohne die bestehende CI zu ersetzen
  • Das Kernproblem war nicht ein Mangel an Funktionen in Earthly CI
  • Ein vielversprechendes frühes Produkt müsste eine Gruppe anziehen, die fehlende Funktionen in Kauf nimmt, um den Nutzen zu erhalten; bei Earthly CI gab es dafür nicht genügend Signale
  • Deshalb stellt Earthly Earthly CI ein und konzentriert sich auf Earthly und Earthly Satellites, die funktionieren

Zeitplan für die Einstellung und Umstieg der Nutzer

  • Earthly CI wird am 1. Oktober 2023 eingestellt
  • Earthly CI war zwar als Beta- bzw. experimentelle Phase gekennzeichnet, dennoch unterstützt Earthly die Nutzer beim Umstieg
  • Da Earthly mit jeder CI zusammenarbeitet, sieht Earthly die Migration weg von Earthly CI als einfach an
  • Wer weiterhin schnelle Builds möchte, kann Earthly Satellites anbinden; dafür gibt es auch einen kostenlosen Tarif
  • Unterstützung beim Umstieg gibt es direkt in der Earthly Slack community

Künftige Investitionen in Satellites

  • Earthly Satellites zeigen Wachstumssignale, weil sie nicht nur schnelle und konsistente Builds liefern, sondern es Nutzern auch erlauben, ihre eigene CI beizubehalten
  • Die durch das Ende von Earthly CI frei gewordene Zeit fließt in Funktionen, die die Earthly-Community angefragt hat
    • Satellite metrics einschließlich CPU-, Speicher-, Festplatten- und Netzwerk-I/O-Nutzung
    • Build history in der Web-UI sowohl für lokale Builds als auch für Satellites-Builds
    • Auto-skip, das sofort überspringt, wenn geänderte Dateien keinen Einfluss auf den Build haben
    • eine Funktion, um Dockerfile-Builds als schnelle Alternative zu docker build remote auf Satellites auszuführen
    • self-hosted Satellites als besser unterstützte Version von self-hosted remote Buildkit
    • die Verteilung eines einzelnen Builds auf mehrere Satellites zur weiteren Beschleunigung
    • Compute v2 als vollständig verteilte serverlose Satellites
  • Earthly Satellites sind Remote-Build-Runner, die mit jeder CI zusammenarbeiten und über Earthly Cloud genutzt werden können
  • Earthly ist ein Open-Source-Build-Framework, das einmal geschriebene Builds überall konsistent ausführbar macht und hilft, CI-Fehler auf dem lokalen Rechner einfach zu reproduzieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-13
Meinungen auf Hacker News

  • Ein Beitrag, der gut zeigt, warum man beim Open-Sourcing nicht den gesamten Kernwert aus der Hand geben sollte. Weil Earthly Open Source war, hatten Nutzer von Earthly Satellite bereits 95 % des Werts von Earthly CI
    Ich mag Open Source sehr, aber wenn Open Source Teil des Geschäftsmodells ist, braucht es ein Differenzierungsmerkmal. Über „extrem schnell“ hinaus muss es einen Grund geben, warum Leute ihre Kreditkarte zücken oder gar den Einkaufsprozess über die Buchhaltung anstoßen
    GitLab beschränkt CI/CD auf zahlende Kunden, Travis/CircleCI begrenzen Build-Zeit oder Credits, Azure DevOps ist teuflisch, und ArgoCD ist komplex. GitHub Actions ist okay, wenn man Hardware für die Runner hat, und in Enterprise-Umgebungen ist man an Jenkins-Herden eher gewöhnt
    Als ehemaliger DevOps Director wäre meine erste Frage: „Welche Funktion bringt mich dazu, zu kaufen, statt selbst zu hosten?“ Wenn ich die technische Fähigkeit habe, es selbst zu betreiben, und meine Cloud sowie meine DevOps-Pipeline passend zu unserem Geschäft führen kann, müsst ihr mich überzeugen, warum ich euch bezahlen sollte
    Das heißt nicht, dass man Funktionen verstecken soll, die für den Betrieb der Software essenziell sind; gemeint sind eher Business-Funktionen wie Support oder Enterprise-Integrationen als kostenpflichtige Angebote. Ein gestaffeltes Modell, bei dem Power-User weniger zahlen, weil sie mehr selbst unterstützen, scheint ebenfalls möglich

    • Ich bin mir nicht sicher, ob Feature-Beschränkungen im Bereich Entwickler-Tools traditionell gut funktioniert haben. Die Abwanderungsrate bei Tools ist so hoch, dass die meisten Entwickler, wenn Earthly das Produkt absichtlich abschwächt, vermutlich zu einer schlechteren, aber kostenlosen Alternative wie taskfile wechseln würden
      Man könnte die verbleibenden Nutzer zwar in zahlende Kunden umwandeln, aber das wäre eine ziemlich große Wette. Ein gutes Gegenbeispiel aus jüngerer Zeit könnte Docker sein, aber dafür musste man striktes Open Source aufgeben und umstrittene Lizenz- und Produktänderungen vornehmen
    • Bei der Stelle „in Enterprise-Umgebungen ist man an Jenkins-Herden gewöhnt“ dachte ich: Ich glaubte, wir seien die letzte Organisation, die so etwas macht; es ist seltsam beruhigend, dass diese unheilige Konfiguration offenbar einigermaßen Standard ist
    • GitLab-CI-Runner kann man selbst hosten und auch in der kostenlosen Community-Version nutzen
    • Das mag kontrovers sein, aber ich wünschte, bei Services würde ein kommerzieller source-available Ansatz mehr zum Mainstream und weniger verteufelt werden als „Open Core“
      Es ist sehr frustrierend, Code außerhalb des „Open Core“ nicht lesen, keine Bugfixes beitragen und ihn nicht selbst hosten zu können; die Unterscheidungsmerkmale zwischen Open-Source-Lizenzen und source-available Lizenzen brauche ich persönlich kaum
    • Wenn jemand das Patterning von applicationset gut löst, könnte man ArgoCD wohl als Produkt verpacken. D2iQ macht das mit Flux bereits, aber wir sind bei D2iQ ausgestiegen, bevor wir es überhaupt ausprobiert haben

  • Ich will ja kein Wasser in den Wein gießen, aber das ist buchstäblich fast ein Copy-Paste-Produkt
    Es gibt Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines, und wenn man sich die Herkunft ansieht – Ex-Google, Ex-VMW, RabbitMQ –, überrascht das auch nicht
    Selbst wenn der Autor des Originals nicht direkt an den Ursprüngen dieser Tools war, ist er zumindest eine Art Cousin dieser Geschichte
    Die Sales-Zyklen sind lang, und Integrationen erfordern Zustimmung von Führungskräften auf mehreren Achsen, inklusive Security und Networking
    Sie haben zwar etwas Gutes gebaut, aber die vorgelagerten Probleme sind so vielschichtig, dass es sich in einem Bereich, der ständig zwischen maßgeschneiderten Lösungen und generischen Produkten pendelt, wie eine eher substanzarme Geschichte anfühlte. Da ist alles dabei: von fehlender Aufsicht bis Micromanagement, von Unerfahrenheit bis zu so viel Erfahrung, dass man die „Art, wie wir es immer gemacht haben“, nicht loslassen kann
    Vielleicht eine unpopuläre Meinung, aber wer eine Toolchain verkauft, versucht im Grunde, ein Meer von Problemen zum Kochen zu bringen. Business und Technik fließen wie Wasser zu der Öffnung mit dem geringsten Widerstand und unterspülen dabei manchmal das Fundament des „Kerngeschäfts“. Meiner Erfahrung nach bringen Toolchains den größten Nutzen, wenn sie wie Leitplanken oder eine „Erziehungsstrategie“ funktionieren und abnehmbare Guardrails haben

    • Noch grundlegender: Dieses Produkt bot nicht genug Gründe, es zu nutzen, geschweige denn dafür zu bezahlen
      „Schnell“ ist kein Verkaufsargument. Entwickler wollen keine langsamen Pipelines, aber das heißt nicht, dass sie schnelle Pipelines wollen
      Die Pipeline-Geschwindigkeit hängt stärker davon ab, wie die Pipeline aufgebaut ist, als vom Overhead des Pipeline-Service, und andere CI/CD-Services sind bereits sehr schnell. CircleCI lässt sich zum Beispiel gegenüber GitHub Actions und GitLab CI/CD schon nicht leicht verkaufen – wodurch hat sich dieser Service unterschieden? Hat er gegenüber GitHub/GitLab/CircleCI usw. echten Mehrwert geboten? Bei Builds von ein paar Minuten Millisekunden einzusparen, ist nicht die Antwort

  • Der Grund für das Scheitern war, dass das Marketing offensichtlich schlampig und ziemlich unehrlich war
    Ob man mit Jenkins, Actions oder Earthly kompiliert: Wenn derselbe Build-Node verwendet wird, ist die Kompilierzeit identisch. Wenn CI in wenigen Sekunden startet, ist die Behauptung, 20-mal schneller zu sein, ziemlich bedeutungslos
    Caching und parallele Ausführung sind alte Konzepte in CI, und moderne Build-Systeme können das alle
    Der Kern von CI ist Feedback, aber bei Zusammenarbeit oder dem Hochziehen von Daten nach oben habe ich nicht viel gesehen. Ich habe es mir nicht im Detail angesehen, aber genau das müsste im Vordergrund stehen. Und schließlich möchte ich nie wieder eine DSL für Builds einführen

    • Caching und Parallelisierung mit GitHub Actions, Jenkins, Docker und Make einzurichten, ist deutlich schwieriger als alles mit Earthly zu machen
    • Kannst du genauer erklären, was du mit „Feedback“ meinst? Ich würde gern wissen, welche Art von Feedback du von CI erwartest

  • Schnelles CI – was soll das überhaupt heißen?
    CI ist ein übergroß gewordenes Shell-Skript, das Builds ausführt und Fehler meldet. Normalerweise sind die Build-Tools selbst so langsam geworden, dass die Kosten für CI-Runner im Vergleich dazu praktisch null sein sollten.
    Wenn man schnelles CI will, müssen tsc, clang, rustc usw. schneller sein – nicht das Programm, das sie per exec aufruft.
    Etwas näher am Thema gesagt: Wenn man CI verkauft und das Geschäft scheitert, dann deshalb, weil man keinen Mehrwert geliefert hat. Leute können ihre Build-Skripte auch ohne euch gut ausführen.

    • Beim schnellen Überfliegen des Artikels scheint hier CI gemeint zu sein, das Dinge wie das Caching von Build-Artefakten automatisch übernimmt, sodass nicht bei jedem Commit das gesamte Repository neu kompiliert werden muss.
      Es geht nicht darum, dass das Programm, das exec aufruft, schneller ist, sondern um ein Programm, das weiß, dass es exec von vornherein gar nicht aufrufen muss.
    • Es wäre schön, wenn CI tatsächlich so einfach wäre, dass man es als „übergroß gewordenes Shell-Skript, das Builds ausführt und Fehler meldet“ beschreiben könnte.
      Ich weiß nicht, was gemessen wurde, aber um ein Beispiel zu nennen: Die Standard-Landing-Page von Jenkins ist in Sachen Geschwindigkeit eine Katastrophe. Sie versucht, überall aktuelle Build-Daten des gesamten Clusters anzuzeigen, und selbst in einem nicht besonders großen Cluster kann sie Hunderte bis Tausende Einträge von den einzelnen Nodes abrufen müssen, auf denen die Builds laufen.
      Allein durch das Laden der Landing-Page ohne spezielle Einstellungen, die das Standardverhalten unterbinden, habe ich Jenkins unzählige Male abgeschossen.
      CI-Server haben normalerweise eine eigene Datenbank und verwalten alle möglichen CI-Entitäten wie Jobs, Artefakte, Benutzer und Secrets. Das kann ziemlich groß werden, und man muss sich ordentlich um Indexierung und Ähnliches kümmern.
      CI hat mehrere Runner, die häufig dynamisch provisioniert werden. Man kann sich vorstellen, dass VM- oder Docker-Images auf Runner-Nodes verteilt werden müssen. Auch das schnell über einen Cluster zu verteilen, ist nicht einfach. Artefakte will man vermutlich ebenfalls im gesamten Cluster verteilen, und auch das kostet Zeit und Ressourcen.
      CI braucht faktisch auch eigene Buchhaltung für Garbage Collection, Reporting und Selbstdiagnose. In einem hinreichend großen Cluster kann all das sehr hohe Latenzen verursachen, wenn man nicht gezielt daran arbeitet, sie zu reduzieren.
      Schon mal von ccache gehört?
      Aber im Ernst: „Man braucht nur schnelle tsc/clang/rustc“ ist viel zu naiv. Um Builds in einem verteilten System namens CI schnell zu machen, muss man auch lösen, wie man diesen Cache verteilt und wie man Builds modularisiert. Du hast sicher schon gehört, dass Cache-Invalidierung eines der schwierigsten Dinge in der Programmierung ist; das ist nur teilweise ein Witz.
    • Der einzige Teil von Earthlys Angebot, der bei mir wirklich verfangen hat, war, dass man CI lokal ausführen kann. Wenn man CI debuggt und es auf dem eigenen Rechner laufen lassen kann, findet man Probleme viel schneller.
      Ich habe lange gebraucht, um ein ziemlich unordentliches GitHub-Actions-Skript hinzubekommen, weil der Debug-Zyklus 10 Minuten dauerte.
    • Teils richtig, teils nicht. Caching zu nutzen und zu wissen, wann tsc/clang/rustc ausgeführt werden müssen, verbessert ebenfalls die Performance.
    • Der schwierige Teil bei CI besteht darin, Arbeiten zu erkennen, die gar nicht nötig sind. Genau dort lässt sich Zeit sparen.

  • Gut, dass sie nur den Dienst einstellen und nicht gleich das ganze Unternehmen dichtmachen. Ich mochte dieses Tool wirklich sehr, so sehr, dass ich regelmäßig auf die Karriereseite geschaut habe.
    Die Earthfile-Syntax ist eine sehr vernünftige, inkrementelle Weiterentwicklung der Dockerfile-Syntax und macht viele Dinge einfach, die mit Dockerfile allein unmöglich oder sehr umständlich waren.
    Ich erinnere mich, dass Docker mit der Einführung von BuildKit und buildx versucht hat, Dockerfile als allgemeines Build-System zu positionieren – also nicht nur zum Erstellen von Containern, sondern auch von Datei-Artefakten usw. Earthly hat diese Idee tatsächlich gut umgesetzt.

    • Schau dir am besten Dagger an. Meiner Ansicht nach ist es besser als Earthly.
      Ich nutze es zufrieden, bezahle aber noch nicht dafür.

  • Allein anhand dieses Artikels war es ehrlich gesagt etwas schwer zu verstehen, was passiert ist. Ich habe ihn mehrmals gelesen, aber die Begriffe bleiben verwirrend. Es scheint mindestens zwei getrennte Probleme gegeben zu haben
    Das Problem, die bestehende CI-YAML, also von GitHub/GitLab, auf Earthly, eine Mischung aus Makefile und Dockerfile, zu migrieren
    Das Problem, die Job-Runner von der bestehenden CI auf einen von Earthly gehosteten Dienst zu migrieren
    Ich dachte, Ersteres sei die schwierige Aufgabe. Eine Sprache zu wechseln kann schließlich Monate oder Jahre dauern
    Aber ich bin mir nicht sicher, was der Blogpost sagen will. Ich dachte, sie hätten diesen Teil validiert; heißt das nicht, dass Leute umsteigen konnten?
    Am Ende heißt es jedoch, es sei nicht validiert gewesen. Mussten Kunden also nicht eine, sondern zwei Migrationen durchführen?
    Und was passiert jetzt? Behalten sie die Earthly-Syntax bei, geben aber CI auf? War nicht genau diese Syntax der schwer zu migrierende Teil? Ich bin immer noch verwirrt

    • Gut zu wissen, dass es nicht nur mir so geht. Ich interessiere mich sowohl für Produktentwicklung als auch für Developer Tools, und nach der Lektüre dieses ziemlich verwirrenden Textes war ich ungefähr bei „freut mich für euch, oder tut mir leid“.
      Ist der Kern, dass sie angenommen haben, deutlich schnellere Builds seien das Killer-Feature, diese Annahme aber vor dem Bau nicht validiert haben? Oder dass sie die Nutzer nicht richtig segmentiert haben und deshalb nicht wussten, dass zahlungskräftige Kunden andere Anforderungen haben? Oder dass sie die eigentlichen Probleme zahlender Kunden einfach kostenlos gelöst haben?
      Und wenn man bedenkt, dass dieser etwas verwirrende Artikel vom CEO geschrieben wurde, frage ich mich, ob die Verwirrung nur an mangelnder Redaktion liegt oder ob es während des gesamten Prozesses auch intern im Unternehmen tatsächlich viel Verwirrung gab
      Vor langer Zeit schrieb Steve Blank in „Founders and dysfunctional families“ [1], dass viele Gründer in chaotischen Verhältnissen aufwachsen und deshalb gut darin sind, Chaos zu managen; das trifft auf mich definitiv auch zu. Er fügte hinzu, dass der Unterschied zwischen Erfolg und Scheitern davon abhängen kann, ob ein Gründer auch einen nicht chaotischen Zustand handhaben kann
      Gründer, die das nicht können, neigen dazu, „organisatorische Handgranaten“ in ihr eigenes Unternehmen zu werfen, um wieder zu dem Chaosniveau zurückzukehren, in dem sie gut sind. Diese Beobachtung hat mich in den folgenden Jahren mehrmals innehalten lassen
      [1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
    • Das ist kein Problem der Syntaxmigration
      Die CI von Leuten wird mit der Zeit zu einem Mischmodell, das die jeweilige Art kapselt, wie ein Unternehmen seine Software baut und ausliefert. Man kann sich das wie den Missbrauch von CI als beliebigen Automatisierungs-Job-Runner à la Airflow vorstellen
      Die Migration beginnt damit, dass man zuerst Reverse Engineering dessen betreibt, was die Leute früher wussten, und erst danach kann man all das auseinandernehmen und anders ausdrücken
      Niemand möchte die Welt anhalten und das aufräumen

  • Der Artikel ist verwirrend, weil der Autor dem Problem zu nahe ist; bevor er ins Detail geht, müsste er es aus der Perspektive eines Außenstehenden erklären. Die nötigen Informationen scheinen aber vorhanden zu sein
    Im Ergebnis scheinen sie eine Kapselungsschicht zwischen sprachspezifischen Build-Systemen und dem Continuous-Build-System geschaffen zu haben, das diese ausführt
    Zum Vergleich gibt es Dinge wie Bazel: Bazel macht alles, aber um es vollständig einzuführen, muss man sich ganz darauf einlassen, die sprachspezifischen Build-Systeme durch Bazels Build-Sprache zu ersetzen, und oft verschiebt man sogar Quelldateien, damit es funktioniert
    Das kann im Vergleich zur Nutzung des Build-Systems der Sprache selbst ungewohnt sein, für C-Programmierer, deren Sprache kein eigenes Build-System hat, aber natürlicher wirken. Auch Java hat nach mehreren bedauerlichen Build-Systemen leider bei Gradle Halt gemacht
    Sprachspezifische Build-Systeme machen am Ende nicht alles, weil jede Sprache andere Konventionen und ein anderes Ökosystem hat. Moderne Systeme kennen ihren Zuständigkeitsbereich und bleiben dabei
    Deshalb sind die Tools, die mehrere Sprachen und Artefakte tatsächlich verstehen, häufig Shell-Skripte, Makefiles, Dockerfiles oder die Continuous-Build-Systeme selbst. Manchmal passiert es sogar von Hand. Genau diese Schicht wollen sie verbessern
    Allerdings ist die grundlegende Einsicht, warum ihr Ansatz besser sein soll, noch nicht klar zu erkennen

  • Ich hatte mir Earthly früher wegen der Arbeit kurz angesehen. Wir mussten Integrationen für mehrere CI-Plattformen schreiben – GitLab, Azure DevOps, Jenkins und vielleicht sogar GitHub Actions.
    Am Ende entschieden wir uns für Dagger, ein sehr ähnliches Produkt: ein weiteres recht gutes BuildKit-Frontend, das sich in verschiedene CI-Systeme integrieren ließ, und dessen damals für Pipeline-Definitionen verwendete DSL besser wirkte.
    Diese Entscheidung habe ich jedoch zutiefst bereut. Denn die Dagger-Entwickler haben diese Sprache faktisch aufgegeben und sind dazu übergegangen, SDKs für populäre Programmiersprachen herauszubringen. Alle sind imperativ, alle sind Turing-vollständig, und meiner Meinung nach passen sie nicht gut in diesen Bereich.
    Deshalb bin ich jetzt wieder in der Hölle gelandet und integriere all diese Systeme von Hand; ich zögere, solche Tools noch einmal einem Startup anzuvertrauen.
    Für mich ist das weiterhin der attraktivste Use Case für etwas wie Earthly. „Pushen und schauen, was passiert“ ist bei fast allen CI-Systemen der Standard, aber ein schrecklicher Workflow.
    Wenn man in einer großen Organisation Teams unterstützen muss, die verschiedene CI/CD-Plattformen nutzen, kann etwas wie Earthly ziemlich viel Schmerz ersparen. Der Reiz liegt aber nicht darin, noch ein weiteres CI hinzuzufügen, sondern ganz genau in der Unterstützung bestehender CI-Plattformen.

    • CI/CD und Provisioning sind ihrem Wesen nach Aufgaben, bei denen die Reihenfolge wichtig ist; persönlich bevorzuge ich daher den SDK-Ansatz gegenüber der CUE-Implementierung.
      Das Hauptproblem der früheren CUE-Implementierung war, dass sie den Solver für gerichtete azyklische Graphen von BuildKit mit dem Solver für gerichtete azyklische Graphen von CUE in Einklang bringen wollte – und die beiden arbeiteten in entgegengesetzte Richtungen.
      Vor etwa drei Jahren habe ich als CUE-Experte versucht, bei der Lösung dieses Problems zu helfen. Für Dagger halte ich SDKs für die deutlich bessere Lösung.
      Ob man es mag oder nicht: Ein erheblicher Teil der Branche bewegt sich in diese Richtung. Pulumi ist ein weiteres Beispiel. Von imperativer Cloud-Infrastruktur bin ich überzeugt, und auch Builds scheinen bis zu einem gewissen Grad dazu zu passen.
      Nebenbei: Ich werde eine neue CUE-+-Dagger-Konfiguration untersuchen, sie wird aber anders funktionieren als die frühere Dagger-Engine.
    • Als CEO von Dagger gesprochen: Ja, wir bieten SDKs für populäre Sprachen an, und diese Sprachen sind imperativ. Aber Dagger ist weiterhin ein deklaratives System, sodass die Teile, die man an den frühen Versionen gut fand, erhalten geblieben sind.
      Der Kern ist, dass wir die deklarative Schicht von statischer CUE-Konfiguration zu dynamischen GraphQL-Queries verschoben haben. Und aus dem GraphQL-Schema haben wir Client-Bibliotheken für mehrere Sprachen generiert.
      Dadurch kann man wie früher gerichtete azyklische Graphen deklarativ aufbauen – nur eben zusätzlich in jeder bevorzugten Sprache. Man kann den DAG auch direkt mit reinem GraphQL ausführen. Sieh dir https://play.dagger.cloud an, das man direkt im Browser ausprobieren kann.
      Eine nützliche Analogie ist SQL. SQL ist eine deklarative Sprache, wird aber meist zusammen mit anderen Sprachen verwendet, häufig imperativen.
      Ich hoffe, diese Erklärung hilft und du ziehst Dagger noch einmal in Betracht.

  • Die Formulierung „2- bis 20-mal schnellere Builds“ taucht im gesamten Artikel mehrfach auf. Im Vergleich wozu? Ohne Baseline ist dieser Satz wertloses Marketing-Geschwätz.

    • Gemeint ist der Vergleich mit Builds auf anderen Plattformen, die ohne Caching und ohne Parallelisierung laufen.

  • Der Abschnitt „Warum den Stack nicht vereinfachen? Warum sowohl einen CI-Anbieter als auch uns bezahlen, statt nur uns?“ erklärt sich dadurch, dass die CI-Lösung, für die sie „bezahlen“, zusammen mit dem restlichen Stack geliefert wird. GitLab und GitHub bieten weit mehr als ein einfaches CI-Produkt.
    Auch den Teil „Neue Leute standen Earthly CI skeptisch gegenüber, dachten, alle CI-Systeme seien gleich und unterschieden sich nur in der Syntax, und sahen dann nicht weiter hin“ kann ich nachvollziehen.
    Wir interessieren uns nicht wirklich für CI an sich; wir brauchen es einfach, und es soll zuverlässig funktionieren.
    Wenn es für eine App ein funktionierendes CI-Manifest gibt, nutzt eine neue App dasselbe Manifest und ersetzt nur ein paar Stellen. Das erste Erstellen kann schmerzhaft sein, aber wenn ich mir die Beispiele ansehe, wirkt es nicht wirklich einfacher, als dasselbe in GitLab zu tun.
    Ehrlich gesagt: Wenn sie einen Konverter eingebaut hätten, der GitLab- oder GitHub-CI-Konfigurationen nimmt und daraus on the fly ein Earthfile macht, hätten sie einen zumindest dazu bringen können, es auszuprobieren.