El CI más rápido que construimos: fracasó

 (earthly.dev)
1 puntos por GN⁺ 2023-09-13 | 1 comentarios | Compartir por WhatsApp
  • En lugar de competir de frente con los proveedores establecidos en el mercado de herramientas CI/CD, Earthly se enfocó en la velocidad de build; ahora cierra Earthly CI y vuelve a concentrarse en Earthly y Satellites
  • La visión original era unificar el sistema de builds y el CI en uno solo y ejecutarlo de forma distribuida, para ofrecer paralelismo automático, caché y reproducibilidad local al mismo tiempo
  • Earthly y Earthly Satellites validaron respectivamente la consistencia de builds y pipelines de CI de 2 a 20 veces más rápidos, pero un producto de reemplazo total de CI no logró generar suficiente conversión
  • Los nuevos clientes veían como muy alto el costo de migración y la carga de reescribir scripts, mientras que los clientes actuales de Satellites ya obtenían el 95% del valor de Earthly CI usando combinaciones de CI existentes como GitHub Actions
  • Earthly CI se descontinuará el 1 de octubre de 2023, y Earthly invertirá en Satellites para que los usuarios obtengan builds rápidos sin dejar su CI actual

Cierre de Earthly CI y reenfoque

  • Earthly descontinuará Earthly CI y reorganiza la empresa alrededor de Earthly y Earthly Satellites
  • A partir de ahora, el valor en el que se enfocará se reduce a dos puntos
    • builds locales y reproducibilidad
    • Earthly Satellites para usar junto con CI existentes
  • Earthly CI apuntaba a ser un CI rápido, pero no logró generar suficientes señales de adopción temprana en el mercado

La visión original del “CI más rápido”

  • Earthly empezó en abril de 2020 con el objetivo de mejorar las herramientas de CI/CD
  • El punto de partida fueron dos preguntas
    • cómo se vería un CI si pudiera ejecutarse también en una laptop
    • cómo se vería el sistema de CI más rápido del planeta
  • La respuesta a la que llegó Earthly fue que el sistema de builds y el CI debían ser lo mismo, y además debían estar distribuidos
  • El objetivo era no repetir pasos de build no afectados por los cambios, ofrecer ejecución paralela automática y permitir reproducir de forma confiable en una laptop cualquier parte del build

Cómo un equipo pequeño compite con proveedores de CI ya establecidos

  • Para una startup en etapa inicial es difícil competir, en madurez, cantidad de funciones e integración, con proveedores establecidos que tienen capital, personal, reputación y más de 10 años de ventaja
  • La estrategia de Earthly no fue convencer a todo el mercado, sino dar una solución 10 veces mejor a unos pocos equipos que sufren intensamente un problema específico
  • La validación inicial se parece más a tener un grupo pequeño de usuarios que usa el producto con entusiasmo aunque todavía tenga bugs y limitaciones
  • Cuando un MVP no obtiene suficiente validación, simplemente seguir agregando funciones suele arrastrarte a una competencia donde los proveedores establecidos tienen ventaja

El plan de 3 etapas hacia Earthly CI

  • En vez de construir de inmediato Earthly CI, que era su meta final, Earthly lo dividió en varios productos independientes para intentar validar cada etapa

  • Etapa 1: Earthly

    • El primer hito fue Earthly
    • Earthly ofreció primero una sintaxis de builds y una experiencia de ejecución de builds on-demand
    • Su valor principal era la consistencia de builds, es decir, que el build se ejecutara igual sin importar el entorno
    • Al inicio corría en local y en otros CI, y después terminó usándose en miles de repositorios
    • VMware, Adobe, Namely, Roche, ExpressVPN y Bluecore figuran entre sus usuarios
    • Era un proyecto bootstrappeado por una sola persona, con bugs y restricciones, pero el hecho de que la gente realmente lo usara fue una señal de validación

  • Etapa 2: Earthly Satellites

    • El segundo hito fue Earthly Satellites
    • Satellites es un runner remoto que puede invocarse desde una laptop o desde cualquier CI
    • Su valor principal era la velocidad de build, acelerando pipelines de CI de 2 a 20 veces gracias a caché y paralelismo
    • Como Earthly era open source, los usuarios podían obtener efectos parecidos incluso antes de que existiera el servicio comercial, operando por su cuenta runners remotos basados en Buildkit
    • Cuando apareció Satellites administrado, los usuarios empezaron a usar el producto para evitar gestionar ellos mismos el runner remoto
    • Los primeros Satellites tenían bugs, eran ineficientes e inestables, pero atrajeron usuarios porque había pocas alternativas que ofrecieran ese nivel de velocidad en CI/CD

  • Etapa 3: Earthly CI

    • El tercer hito fue Earthly CI
    • Earthly CI era una plataforma completa de CI que combinaba Earthly y Satellites, y buscaba competir con CI como GitHub Actions, CircleCI y Jenkins
    • Como Earthly apuntaba a la consistencia de builds y Earthly CI a la velocidad, Earthly pensó que Earthly gratuito no canibalizaría la monetización de Earthly CI
    • Pero más adelante la diferencia entre la propuesta de valor de consistencia vs. velocidad terminó convirtiéndose en un problema

Las barreras de conversión que quedaron expuestas tras el lanzamiento

  • Earthly CI tuvo su lanzamiento, fue cubierto por TechCrunch y también se prepararon posts para Reddit y HackerNews
  • En la primera o segunda semana después del lanzamiento, se registraron alrededor de 50 correos en la lista de espera, superando la meta
  • Había una diferencia clara entre clientes nuevos y usuarios existentes de Earthly
    • Los clientes nuevos solían pensar que “todos los CI son parecidos y solo cambia la sintaxis”, así que muchas veces no analizaban a fondo la diferenciación de Earthly CI
    • La conversación casi siempre terminaba girando en torno al costo de migración de reescribir scripts existentes y adaptarse
    • Los usuarios ya existentes de Earthly ya habían terminado la transición a Earthfile y ya conocían sus beneficios, así que estaban listos para ser promotores internos en sus organizaciones
  • Frente a clientes nuevos, Earthly no tenía suficiente reputación como para demostrar que podía entregar a gran escala los beneficios que prometía, y en una llamada corta por Zoom era difícil probar la experiencia de “10 veces más fácil” que reportaban los usuarios existentes

Por qué ni siquiera los clientes actuales migraron a Earthly CI

  • La mayoría de los clientes actuales de Earthly Satellites ya usaban Satellites en su CI/CD
  • Earthly interpretó eso como una validación de la necesidad de Earthly CI, porque el proveedor de CI solo se encargaba de disparar el pipeline y la ejecución real ocurría en Satellites
  • Pero los clientes de Satellites ya obtenían el 95% del valor de Earthly CI
  • Frente a una configuración de GitHub Actions + Satellites, Earthly CI no era lo suficientemente mejor como para justificar el cambio
  • Parecía que para los usuarios actuales de Earthly el cambio sería fácil porque ya usaban Earthfile, pero en realidad los requisitos eran más amplios
    • ecosistema de plugins de GitHub
    • action de codecov
    • triggers manuales
    • triggers basados en creación de tags de git
    • selección de tamaño de máquina
    • cancelación de builds antiguos
    • confianza para entregar secretos de build
  • El MVP de Earthly CI era el CI más rápido, pero no cumplía algunos requisitos clave
  • Algunos usuarios entusiastas sí probaron Earthly CI, pero no llegó a expandirse ampliamente dentro de organizaciones más grandes con presupuesto, más allá de 2 o 3 personas
  • Algunos usuarios de Earthly CI luego se cambiaron a Satellites para quedarse con la velocidad de Satellites y al mismo tiempo aprovechar el ecosistema de GitHub

Por qué las solicitudes de demo terminaron siendo una señal negativa

  • Earthly tuvo más de 100 llamadas con potenciales clientes, pero en conversaciones cara a cara le resultó difícil convencerlos de usar Earthly CI, Satellites o incluso Earthly
  • En cambio, cuando los usuarios llegaban por su cuenta a través del sitio web, crecimiento impulsado por producto, boca a boca o content marketing, la adopción de Earthly ocurría todos los días y además iba en aumento
  • Las herramientas para desarrolladores, en especial las que requieren trabajo de integración, eran difíciles de validar con un enfoque tradicional de ventas directas
  • El criterio negativo más fuerte de calificación era que el cliente potencial pidiera una demo
  • Los equipos que realmente convertían llegaban después de descargar Earthly, leer la documentación y escribir su propio Earthfile; no necesitaban una demo
  • Las herramientas para desarrolladores que requieren trabajo de integración se adoptan según el calendario del usuario, y es difícil venderlas a la fuerza o acelerar artificialmente el proceso

El test A/B de cambiar “CI” por “build”

  • En ese momento, el mensaje del sitio web de Earthly era “Earthly makes CI super simple”, y gran parte de la pantalla principal enfatizaba CI
  • Gavin Johnson propuso hacer una prueba A/B cambiando la palabra “CI” por “build” en el sitio
  • El texto pasó a ser “Earthly makes builds super simple”
  • Ese solo cambio de una palabra hizo que la conversión de la página del CTA principal, “Get Earthly”, se duplicara
  • Después de ese resultado, crecieron las dudas sobre Earthly CI en sí

La lección aprendida de la experiencia con ShiftLeft

  • ShiftLeft, iniciada antes de Earthly, hoy se llama Qwiet.ai
  • La visión inicial era un agente de seguridad instalado en producción para proteger apps en la nube de ataques que explotan vulnerabilidades en el código fuente
  • Ese producto requería un analizador de código compatible con varios lenguajes de programación, agentes para cada runtime y un backend distribuido que integrara todo, algo parecido a que una startup pequeña construyera al mismo tiempo la complejidad de tres empresas distintas
  • Después de más de un año de trabajo, lograron que funcionara de punta a punta en un solo lenguaje de programación, pero la respuesta del mercado fue mala
  • El cliente objetivo de ese producto de seguridad eran empresas grandes y fuertemente reguladas, y además había que meter el producto tanto en CI/CD como en producción, así que la ruta de adopción era muy difícil
  • En ese momento pensaron que agregar más funciones podría superar la dificultad de adopción, y siguieron construyendo otro año y medio, pero el mercado no lo quería
  • Más tarde se dieron cuenta de que podían dividir ese producto complejo en dos productos distintos
    • un introspector de código para especialistas en seguridad
    • un analizador de código independiente 40 veces más rápido que otros analizadores del mercado
  • El mayor arrepentimiento fue no haberse detenido antes, cuando ya había señales

La conclusión a la que llegó Earthly

  • Earthly resumió la situación así
    • la gente quiere builds más rápidos
    • la gente odia cambiar de CI
    • sobre un CI nuevo pesa el estigma de no estar realmente diferenciado, y los usuarios se van en cuanto ven la palabra “CI” en el sitio web
    • la participación tipo design partner mediante contacto directo con clientes no funciona cuando la percepción del costo de migración es tan alta
    • el MVP de Earthly CI no logró formar un grupo suficientemente fuerte de primeros adoptantes
    • la respuesta mejora cuando se dice que con Earthly Satellites se pueden obtener builds más rápidos sin cambiar el CI existente
  • El problema central no era la falta de funciones en Earthly CI
  • Si fuera un producto inicial prometedor, debería existir un grupo dispuesto a tolerar la falta de funciones con tal de obtener sus beneficios, pero en Earthly CI no aparecieron señales suficientes de ese nivel
  • Por eso Earthly decidió descontinuar Earthly CI y concentrarse en Earthly y Earthly Satellites, que sí estaban funcionando

Calendario de cierre y transición de usuarios

  • Earthly CI se descontinuará el 1 de octubre de 2023
  • Earthly CI estaba marcado como beta/experimental, pero Earthly dará soporte a la transición de usuarios
  • Como Earthly funciona con cualquier CI, Earthly considera que migrar fuera de Earthly CI es sencillo
  • Si se quiere seguir teniendo builds rápidos, se puede conectar Earthly Satellites, que además tiene un plan gratuito
  • El soporte para la transición se ofrecerá directamente en la comunidad de Slack de Earthly

Dirección futura de inversión en Satellites

  • Earthly Satellites está mostrando señales de crecimiento porque no solo ofrece builds rápidos y consistentes, sino que además permite a los usuarios conservar su propio CI
  • El tiempo liberado por el cierre de Earthly CI se invertirá en funciones que la comunidad de Earthly ha venido pidiendo
    • Satellite metrics, incluyendo uso de CPU, memoria, disco y network I/O
    • Build history en la web UI tanto para builds locales como para builds en Satellites
    • Auto-skip para omitir de inmediato builds cuando los archivos modificados no afectan el resultado
    • ejecución remota en Satellites de builds con Dockerfile como alternativa rápida a docker build
    • self-hosted Satellites, una versión mejor soportada de self-hosted remote Buildkit
    • capacidad de distribuir un solo build entre varios Satellites para acelerar aún más
    • Compute v2, Satellites totalmente distribuidos y serverless
  • Earthly Satellites es un runner remoto de builds que funciona con cualquier CI y puede usarse a través de Earthly Cloud
  • Earthly es un framework open source de builds que ofrece consistencia de builds de escribir una vez y ejecutar en cualquier lugar, y ayuda a reproducir fácilmente fallas de CI en la computadora local

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-13
Opiniones en Hacker News

  • Es un texto que muestra bien por qué no debes entregar todo tu valor central al volver algo open source. Como Earthly era open source, los usuarios de Earthly Satellite ya disfrutaban del 95% del valor de Earthly CI.
    Me gusta mucho el open source, pero si tu modelo de negocio lo incluye, necesitas un diferenciador. Más allá de ser simplemente extremadamente rápido, la gente necesita una razón para sacar la tarjeta de crédito o, más aún, pasar por el proceso contable de órdenes de compra.
    GitLab restringe CI/CD a clientes de pago, Travis/CircleCI limitan el tiempo de build o los créditos, Azure DevOps es diabólico y ArgoCD es complejo. GitHub Actions está bien si tienes hardware para correr los runners, y en enterprise la pandilla de Jenkins suele resultar familiar.
    Como exdirector de DevOps, lo primero que pregunto es: “¿Qué funcionalidad hace que lo compre en vez de hostearlo yo mismo?”. Si tengo la capacidad técnica para operarlo por mi cuenta y puedo manejar mi nube y mi pipeline de DevOps ajustados a nuestro negocio, tienes que convencerme de por qué debería pagarles.
    No quiero decir que haya que ocultar funciones esenciales para que el software funcione, sino dejar como pagas funciones de negocio como soporte o integraciones de nivel enterprise. También parece viable un modelo por niveles en el que los usuarios avanzados paguen menos porque se dan más soporte a sí mismos.

    • No estoy seguro de que la limitación de funciones haya funcionado tradicionalmente bien en el ámbito de las herramientas para desarrolladores. La tasa de abandono de herramientas es tan alta que, si Earthly debilitara deliberadamente el producto, la mayoría de los desarrolladores probablemente se pasarían a una alternativa gratuita aunque fuera inferior, por ejemplo taskfile.
      Podrían convertir a los usuarios restantes en clientes de pago, pero sería una apuesta bastante grande. Un buen caso reciente con giro positivo podría ser Docker, pero eso requirió abandonar el open source estricto y hacer cambios de licencia y producto muy polémicos.
    • Al leer lo de que “en enterprise la pandilla de Jenkins suele resultar familiar”, pensé que éramos la última organización así, pero me da una tranquilidad extraña saber que esta configuración profana es más o menos un estándar.
    • Los runners de GitLab CI se pueden hostear por cuenta propia y también están disponibles en la versión comunitaria gratuita.
    • Puede ser controversial, pero me gustaría que, en los servicios, el enfoque comercial de código disponible (source available) se volviera más mainstream y recibiera menos críticas que el “open core”.
      Es muy frustrante no poder leer código fuera del “open core”, contribuir correcciones de bugs o autoalojarlo, y los factores que distinguen a las licencias open source de las licencias de código disponible no me hacen mucha falta.
    • Si alguien manejara bien la patronización de applicationset, creo que podría envolver ArgoCD en un producto. D2iQ ya lo hace con Flux, pero nosotros salimos de D2iQ antes de siquiera probarlo.

  • No quiero echar un balde de agua fría, pero esto es, literalmente, casi un producto copiado y pegado.
    Están Jenkins, Google Borg, Cloud Foundry y Concourse Pipelines; y si ves de dónde vienen, ex-Google, ex-VMW, RabbitMQ, tampoco sorprende.
    Aunque el autor original no haya estado cerca de las fuentes de esas herramientas, al menos es algo así como un primo de esa historia.
    El ciclo de ventas es largo, y la integración requiere aprobación ejecutiva en varios ejes, incluyendo seguridad y networking.
    Hicieron algo bueno, pero el problema aguas arriba es tan complejo que me pareció una historia con poca sustancia en un espacio que va y viene constantemente entre lo personalizado y el producto genérico. Hay de todo, desde falta de supervisión hasta micromanagement, desde inmadurez hasta exceso de experiencia al punto de no poder soltar “la forma de siempre”.
    Puede ser una opinión impopular, pero vender una toolchain equivale a intentar hervir un océano de problemas. El negocio y la tecnología fluyen como el agua hacia el hueco de menor resistencia, y en el proceso a veces erosionan los cimientos del “negocio central”. En mi experiencia, las toolchains que funcionan como lineamientos o como una “estrategia de crianza”, con guardrails desmontables, son las que más recompensa dan.

    • Más fundamentalmente, este producto no tenía suficientes razones ni siquiera para usarlo, mucho menos para pagar por él.
      “Ser rápido” no es un argumento de venta. Los desarrolladores no quieren pipelines lentos, pero eso no significa que quieran pipelines rápidos.
      La velocidad del pipeline depende mucho más de cómo lo configures que del overhead del servicio de pipelines, y otros servicios de CI/CD ya son muy rápidos. Por ejemplo, CircleCI tampoco es fácil de vender frente a GitHub Actions y GitLab CI/CD; entonces, ¿cómo se diferenciaba este servicio? ¿Aportaba valor real frente a GitHub/GitLab/CircleCI, etc.? Reducir milisegundos en builds de varios minutos no es la respuesta.

  • Fracasó porque el marketing era descaradamente flojo y bastante deshonesto.
    Si usas el mismo nodo de build, el tiempo de compilación será el mismo ya sea que compiles con Jenkins, Actions o Earthly. Afirmar que es 20 veces más rápido cuando CI arranca en pocos segundos no significa mucho.
    El caching y la ejecución en paralelo son conceptos viejos en CI, y todos los sistemas de build modernos pueden hacerlo.
    El núcleo de CI es el feedback, pero no vi mucho en cuanto a colaboración o a elevar los datos hacia arriba. No lo miré en detalle, pero eso debería estar en primer plano. Por último, no quiero volver a introducir jamás un DSL para builds.

    • Configurar caching y paralelización con GitHub Actions, Jenkins, Docker y Make es mucho más difícil que hacerlo solo con Earthly.
    • ¿Puedes explicar un poco más qué quieres decir con “feedback”? Me da curiosidad qué tipo de feedback esperas de CI.

  • ¿Qué significa exactamente CI rápido?
    CI es un script de shell que se volvió demasiado grande: ejecuta builds y avisa cuando fallan. En general, las herramientas de build en sí se vuelven tan lentas que, en comparación, el costo de los ejecutores de CI debería ser casi cero.
    Si quieres un CI rápido, tsc, clang, rustc y similares tienen que ser rápidos; no es que el programa que los llama con exec tenga que volverse más rápido.
    Para decirlo más en tema: si estás vendiendo CI y el negocio fracasó, es porque no aportaste valor. La gente puede ejecutar sus scripts de build perfectamente sin ti.

    • Al darle una leída rápida al artículo, parece que aquí se refieren a un CI que maneja automáticamente cosas como el caché de artefactos de build, para no tener que recompilar todo el repositorio en cada commit.
      No se trata de que el programa que llama a exec sea más rápido, sino de un programa que sabe que, para empezar, no hace falta llamar a exec.
    • Ojalá fuera tan simple como decir que “CI es un script de shell sobredimensionado que ejecuta builds y avisa cuando fallan”.
      No sé qué midieron, pero por dar un ejemplo, la página de inicio predeterminada de Jenkins es un desastre en términos de velocidad. Intenta mostrar por todas partes datos de builds recientes de todo el clúster, y aun en clústeres no demasiado grandes puede tener que traer cientos o miles de elementos desde los nodos individuales que ejecutan cada build.
      He matado Jenkins incontables veces con solo cargar la página de inicio, sin una configuración específica que bloquee el comportamiento predeterminado.
      Un servidor de CI normalmente tiene su propia base de datos y administra todo tipo de entidades de CI, como jobs, artefactos, usuarios y secretos. Puede crecer bastante y hay que cuidar bien cosas como la indexación adecuada.
      En CI hay varios ejecutores, y con frecuencia se aprovisionan dinámicamente. Piensa en distribuir imágenes de VM o de Docker a los nodos ejecutores. Distribuir eso rápidamente por un clúster tampoco es fácil. También querrás distribuir artefactos por todo el clúster, y eso también consume tiempo y recursos.
      CI en la práctica también necesita su propia contabilidad interna para garbage collection, reportes y autodiagnóstico. En un clúster lo suficientemente grande, todo eso puede generar latencias muy altas si no se trabaja específicamente para reducirlas.
      ¿Has oído hablar de ccache?
      Pero, en serio, decir que “solo necesitas tsc/clang/rustc rápidos” es demasiado ingenuo. Para hacer rápidos los builds en un sistema distribuido como CI, también hay que resolver cómo distribuir ese caché y cómo modularizar los builds. Seguro has oído que una de las cosas más difíciles en programación es la invalidación de caché; bueno, eso es solo parcialmente una broma.
    • La única parte de la propuesta de Earthly que realmente me resonó fue poder ejecutar CI en local. Cuando estás depurando CI, poder correrlo en tu propia máquina te permite encontrar el problema mucho más rápido.
      Me tomó mucho tiempo ajustar un script bastante desordenado de GitHub Actions porque el ciclo de depuración era de 10 minutos.
    • Sí y no. Hacer caching y saber cuándo ejecutar tsc/clang/rustc también mejora el rendimiento.
    • La parte difícil en CI es identificar trabajos que no necesitas hacer. Ahí es donde puedes ahorrar tiempo.

  • Me alegra que simplemente cierren el servicio y no bajen la persiana de toda la empresa. Me gustaba tanto esta herramienta que revisaba seguido su página de empleos.
    La sintaxis de Earthfile es una evolución muy razonable e incremental de la sintaxis de Dockerfile, y facilita muchas cosas que solo con Dockerfile eran imposibles o muy incómodas.
    Recuerdo que cuando Docker introdujo BuildKit y buildx, intentó impulsar Dockerfile como un sistema de build de propósito general, es decir, no solo para contenedores sino también para generar artefactos de archivos y cosas similares. Earthly implementó muy bien esa idea en la práctica.

    • Te convendría probar Dagger. Creo que es mejor que Earthly.
      Lo uso con satisfacción, aunque todavía no estoy pagando por él.

  • Con solo este texto, sinceramente me costó un poco entender qué pasó. Lo leí varias veces y aun así los términos me siguen confundiendo. Parece que había al menos dos problemas separados
    El problema de migrar la configuración de CI desde el YAML de CI existente, es decir, GitHub/GitLab, a Earthly, una especie de híbrido entre Makefile y Dockerfile
    El problema de migrar los ejecutores de trabajos desde el CI existente al servicio alojado por Earthly
    Pensé que lo primero era lo difícil. Cambiar de lenguaje puede llevar meses o años
    Pero no sé bien qué dice el post. ¿No significa que esa parte la habían validado y que la gente sí podía hacer la transición?
    Pero al final dice que no estaba validado. ¿Los clientes tenían que hacer no una, sino dos migraciones?
    Entonces, ¿qué pasa ahora? ¿Mantienen la sintaxis de Earthly pero abandonan el CI? ¿No era esa sintaxis la parte difícil de migrar? Sigo confundido

    • Me alegra no ser el único. Me interesan tanto el desarrollo de productos como las herramientas para desarrolladores, pero después de leer un texto algo confuso quedé en un estado de “me alegro por ustedes, o lo lamento”
      ¿La idea central es que asumieron que builds mucho más rápidos eran la función estrella, pero no validaron esa suposición antes de construirla? ¿O que no segmentaron bien a los usuarios y no se dieron cuenta de que las necesidades de los clientes grandes eran distintas? ¿O que simplemente regalaron lo que resolvía el problema real de los clientes pagos?
      Y dado que este texto algo confuso lo escribió el CEO, me pregunto si la confusión se debe solo a falta de edición, o si realmente hubo mucha confusión dentro de la empresa durante todo el proceso
      Hace mucho, Steve Blank escribió en “Founders and dysfunctional families” [1] que muchos fundadores crecen en medio del caos y por eso son buenos gestionándolo, y eso sin duda aplica a mí también. Agregó que la diferencia entre el éxito y el fracaso puede depender de si el fundador también puede manejar un estado sin caos
      Los fundadores que no pueden hacerlo tienden a lanzar “granadas organizacionales” dentro de su propia empresa para devolverla al nivel de caos en el que se sienten competentes. Esa observación me hizo detenerme a pensar varias veces a lo largo de los años
      [1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
    • Este no es un problema de migración de sintaxis
      El CI de la gente, con el tiempo, se convierte en un modelo híbrido que encapsula todas las formas en que cada empresa construye y despliega su software. Piensa en una situación en la que el CI se usa indebidamente como un ejecutor de automatizaciones arbitrarias, tipo Airflow
      La migración empieza por hacer ingeniería inversa de lo que la gente ya sabía antes, y solo después se puede desarmar todo eso y expresarlo de otra manera
      Nadie quiere detener el mundo para ordenar eso

  • Este texto es confuso porque el autor está demasiado cerca del problema, y necesitaba explicarlo desde la perspectiva de alguien externo antes de entrar en detalles. Aun así, parece que la información necesaria está ahí
    En resumen, parece que crearon una capa de encapsulación entre los sistemas de build específicos de cada lenguaje y el sistema de builds continuos que los ejecuta
    Como comparación, existe algo como Bazel: Bazel hace de todo, pero para adoptarlo por completo hay que apostar todo a reemplazar los sistemas de build específicos de cada lenguaje por el lenguaje de build de Bazel, y a menudo incluso mover archivos fuente de lugar para que funcione
    Esto puede resultar extraño comparado con usar el sistema de build propio del lenguaje, pero puede ser natural para programadores de C, cuyo lenguaje no tiene un sistema de build propio. Java también pasó por varios sistemas de build lamentables y, por desgracia, terminó asentándose en Gradle
    Los sistemas de build específicos de cada lenguaje no terminan haciendo todo, porque cada lenguaje tiene convenciones y ecosistemas distintos. Los modernos saben qué hacen bien y se mantienen dentro de ese alcance
    Por eso, las herramientas que realmente entienden varios lenguajes y artefactos suelen ser scripts de shell, makefiles, Dockerfiles o el propio build continuo. Incluso se hace a mano. Esa es precisamente la capa que ellos intentan mejorar
    Sin embargo, todavía no queda claramente captada la idea fundamental de por qué su enfoque sería mejor

  • Hace un tiempo revisé Earthly brevemente por trabajo. Teníamos que escribir integraciones para varias plataformas de CI, como GitLab, Azure DevOps, Jenkins y quizá hasta GitHub Actions.
    Al final elegimos Dagger, un producto muy parecido: otro buen frontend para BuildKit que se integraba con varios sistemas de CI, y porque el DSL que usaba entonces para definir pipelines me parecía mejor.
    Pero terminé arrepintiéndome mucho de esa decisión. Los desarrolladores de Dagger básicamente abandonaron ese lenguaje y se fueron por el camino de sacar SDK para lenguajes de programación populares. Todos imperativos, todos Turing-completos y, en mi opinión, no encajan bien en este ámbito.
    Así que ahora estoy de vuelta en el infierno, integrándome a mano con todos estos sistemas, y dudo en volver a confiarle este tipo de herramientas a una startup.
    Para mí, esta sigue siendo la parte más atractiva de un producto como Earthly. “Hacer push y ver qué pasa” es el estándar de casi todos los sistemas de CI, y es un flujo de trabajo horrible.
    Si en una organización grande tienes que dar soporte a equipos que usan distintas plataformas de CI/CD, algo como Earthly puede reducir bastante el sufrimiento. Pero el atractivo no está en agregar otro CI, sino precisamente en dar soporte a las plataformas de CI existentes.

    • CI/CD y el aprovisionamiento son, por naturaleza, tareas donde el orden importa, así que personalmente prefiero el enfoque con SDK antes que la implementación con CUE.
      El principal problema de la antigua implementación con CUE era que intentaba hacer encajar el solucionador de grafos acíclicos dirigidos de BuildKit con el solucionador de grafos acíclicos dirigidos de CUE, y ambos funcionaban en direcciones opuestas.
      Hace unos 3 años intenté ayudar a resolver este problema como experto en CUE. Creo que, para Dagger, los SDK son una solución mucho mejor.
      Nos guste o no, una parte considerable de la industria se está moviendo en esta dirección. Pulumi es otro ejemplo. La infraestructura cloud imperativa me convenció, y las compilaciones también parecen encajar hasta cierto punto en esto.
      Como nota adicional, tengo previsto explorar una nueva configuración de CUE + Dagger, pero funcionará de manera distinta al antiguo motor de Dagger.
    • Hablando como CEO de Dagger: sí, ofrecemos SDK para lenguajes populares, y esos lenguajes son imperativos. Pero Dagger sigue siendo un sistema declarativo, así que las partes que te gustaban de la versión inicial siguen ahí.
      La clave es que movimos la capa declarativa de una configuración CUE estática a consultas GraphQL dinámicas. Y a partir del esquema GraphQL generamos bibliotecas cliente para varios lenguajes.
      Así que no solo puedes construir declarativamente un grafo acíclico dirigido como antes, sino que además puedes hacerlo en el lenguaje que prefieras. También puedes ejecutar el DAG directamente en GraphQL puro. Puedes verlo en https://play.dagger.cloud, que se puede probar directamente desde el navegador.
      Una analogía útil es SQL. SQL es un lenguaje declarativo, pero normalmente se usa junto con otros lenguajes, a menudo imperativos.
      Espero que esta explicación ayude y te anime a considerar Dagger una vez más.

  • La frase “compilaciones entre 2 y 20 veces más rápidas” aparece varias veces en todo el artículo. ¿Comparadas con qué? Sin una línea base, esa frase es puro blablá de marketing sin valor.

    • Comparadas con builds que corren en otras plataformas sin caché y sin paralelización.

  • La parte de “¿por qué no simplificar el stack? ¿Por qué pagarle a un proveedor de CI y también a nosotros, en vez de pagarnos solo a nosotros?” se debe a que el CI por el que “pagan” viene incluido con el resto del stack. GitLab y GitHub ofrecen mucho más que un simple producto de CI.
    También entiendo la parte de “la gente nueva veía Earthly CI con escepticismo, pensaba que todos los CI eran iguales y que solo cambiaba la sintaxis, y no seguía mirando”.
    A nosotros no nos interesa demasiado el CI en sí; simplemente lo necesitamos y queremos que funcione bien.
    Si una app ya tiene un manifiesto de CI que funciona, para una app nueva usamos el mismo manifiesto cambiando algunas cosas puntuales con buscar y reemplazar. Puede doler al crearlo por primera vez, pero viendo los ejemplos no parece necesariamente más fácil que hacer lo mismo en GitLab.
    Sinceramente, si hubieran incluido un convertidor que tomara una configuración de GitLab o GitHub CI y generara un Earthfile al vuelo, al menos podrían haber logrado que la gente lo probara.