CI ที่เร็วที่สุดที่เราสร้างขึ้น ล้มเหลว

 (earthly.dev)
1 คะแนน โดย GN⁺ 2023-09-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Earthly ซึ่งเลือกโฟกัสที่ ความเร็วในการบิลด์ แทนการเผชิญหน้ากับผู้เล่นรายเดิมในตลาดเครื่องมือ CI/CD โดยตรง ได้ยุติ Earthly CI และหันกลับไปโฟกัสที่ Earthly และ Satellites อีกครั้ง
  • วิสัยทัศน์เดิมคือ รวมระบบบิลด์และ CI เข้าด้วยกันเป็นหนึ่งเดียว และทำให้รันแบบกระจาย เพื่อมอบทั้งการทำงานขนานอัตโนมัติ, แคช และการทำซ้ำผลลัพธ์บนเครื่องโลคัลได้อย่างสม่ำเสมอ
  • Earthly และ Earthly Satellites ได้รับการพิสูจน์แล้วในด้าน ความสม่ำเสมอของการบิลด์ และ CI pipeline ที่เร็วขึ้น 2–20 เท่า ตามลำดับ แต่ผลิตภัณฑ์ที่ตั้งใจมาแทน CI แบบเต็มรูปแบบกลับไม่สร้างการเปลี่ยนผ่านได้มากพอ
  • ลูกค้าใหม่มองว่าต้นทุนการย้ายระบบและภาระในการเขียนสคริปต์ใหม่สูงมาก ขณะที่ลูกค้า Satellites เดิมก็ได้รับคุณค่า 95% ของ Earthly CI อยู่แล้วจากการใช้ร่วมกับ CI เดิมอย่าง GitHub Actions
  • Earthly CI จะยุติในวันที่ 1 ตุลาคม 2023 และ Earthly จะลงทุนกับ Satellites ในแนวทางที่ให้ผู้ใช้ยังคงใช้ CI เดิมต่อไปพร้อมได้บิลด์ที่เร็วขึ้น

การยุติ Earthly CI และการกลับมาโฟกัสใหม่

  • Earthly ยุติ Earthly CI และจัดระเบียบบริษัทใหม่โดยมี Earthly และ Earthly Satellites เป็นแกนหลัก
  • ต่อจากนี้คุณค่าที่จะโฟกัสจะถูกจำกัดเหลือ 2 เรื่อง
    • การบิลด์บนเครื่องโลคัลและ ความสามารถในการทำซ้ำผลลัพธ์
    • Earthly Satellites ที่ใช้งานร่วมกับ CI เดิมได้
  • Earthly CI ตั้งเป้าจะเป็น CI ที่รวดเร็ว แต่ไม่สามารถสร้างสัญญาณการยอมรับช่วงแรกในตลาดได้มากพอ

วิสัยทัศน์ดั้งเดิมของ “CI ที่เร็วที่สุด”

  • Earthly เริ่มต้นในเดือนเมษายน 2020 โดยมีเป้าหมายเพื่อปรับปรุงเครื่องมือ CI/CD
  • จุดตั้งต้นมาจาก 2 คำถาม
    • ถ้า CI สามารถรันบนโน้ตบุ๊กได้ มันควรมีหน้าตาอย่างไร
    • ระบบ CI ที่เร็วที่สุดในโลกควรมีหน้าตาอย่างไร
  • คำตอบที่ Earthly พบคือ ระบบบิลด์กับ CI ควรเป็นสิ่งเดียวกัน และในขณะเดียวกันก็ต้องทำงานแบบกระจายได้
  • เป้าหมายคือไม่ต้องรันขั้นตอนบิลด์ซ้ำในส่วนที่ไม่ได้รับผลกระทบจากการเปลี่ยนแปลง ให้การทำงานขนานแบบอัตโนมัติ และทำให้ทุกส่วนของบิลด์สามารถทำซ้ำบนโน้ตบุ๊กได้อย่างเชื่อถือได้

วิธีที่ทีมเล็กจะแข่งกับผู้ให้บริการ CI รายเดิม

  • สตาร์ทอัพระยะแรกแข่งขันกับผู้เล่นเดิมที่มีเงิน คน ชื่อเสียง และเวลาออกตัวมากกว่า 10 ปี ได้ยาก ทั้งในด้านความสมบูรณ์ของผลิตภัณฑ์ จำนวนฟีเจอร์ และขอบเขตของการเชื่อมต่อ
  • กลยุทธ์ที่ Earthly เลือกคือ แทนที่จะพยายามโน้มน้าวทั้งตลาด ก็จะมอบทางออกที่ดีกว่าเดิม 10 เท่าให้กับ ทีมจำนวนน้อยที่เจอปัญหาเฉพาะอย่างรุนแรง
  • การพิสูจน์ช่วงแรกมีลักษณะใกล้เคียงกับการมีผู้ใช้กลุ่มเล็ก ๆ ที่ยังใช้งานอย่างกระตือรือร้น แม้ผลิตภัณฑ์จะยังมีบั๊กและข้อจำกัด
  • เมื่อ MVP ไม่สามารถพิสูจน์ตัวเองได้มากพอ การเพิ่มฟีเจอร์เข้าไปเรื่อย ๆ มักดึงเกมการแข่งขันกลับไปเข้าทางผู้เล่นเดิม

แผน 3 ขั้นสู่ Earthly CI

  • Earthly ไม่ได้สร้าง Earthly CI ซึ่งเป็นเป้าหมายสุดท้ายขึ้นมาทันที แต่แยกออกเป็นหลายผลิตภัณฑ์อิสระเพื่อลองพิสูจน์ทีละขั้น

  • ขั้นที่ 1: Earthly

    • ไมล์สโตนแรกคือ Earthly
    • Earthly มอบทั้งไวยากรณ์การบิลด์และประสบการณ์การรันบิลด์แบบ on-demand ก่อน
    • คุณค่าหลักคือ ความสม่ำเสมอของการบิลด์ ที่ทำให้การบิลด์ทำงานแบบเดียวกันไม่ว่าจะอยู่ในสภาพแวดล้อมไหน
    • ในช่วงแรกมันถูกรันทั้งบนโลคัลและบน CI อื่น ๆ และต่อมาก็ถูกใช้งานในหลายพันรีโพซิทอรี
    • VMware, Adobe, Namely, Roche, ExpressVPN และ Bluecore ถูกยกมาเป็นตัวอย่างผู้ใช้
    • มันเริ่มจากโปรเจกต์ของนักพัฒนาคนเดียวแบบไม่มีเงินทุน แม้มีบั๊กและข้อจำกัด แต่การที่มีคนใช้งานจริงก็เป็นสัญญาณการพิสูจน์

  • ขั้นที่ 2: Earthly Satellites

    • ไมล์สโตนที่สองคือ Earthly Satellites
    • Satellites คือ remote runner ที่เรียกใช้งานได้จากโน้ตบุ๊กหรือ CI ใดก็ได้
    • คุณค่าหลักคือความเร็วในการบิลด์ที่ทำให้ CI pipeline เร็วขึ้น 2–20 เท่า ผ่านแคชและการทำงานขนาน
    • เพราะ Earthly เป็นโอเพนซอร์ส ผู้ใช้จึงสามารถรัน remote runner ที่อิง Buildkit เองเพื่อให้ได้ผลลัพธ์ใกล้เคียงกัน แม้ก่อนจะมีบริการเชิงพาณิชย์
    • เมื่อ managed Satellites ออกมา ผู้ใช้ก็เริ่มใช้ผลิตภัณฑ์เพื่อไม่ต้องดูแล remote runner เอง
    • Satellites รุ่นแรกมีทั้งบั๊ก ความไม่มีประสิทธิภาพ และความไม่เสถียร แต่เพราะมีทางเลือกไม่มากที่ให้ความเร็ว CI/CD ระดับเดียวกัน จึงยังมีผู้ใช้เข้ามา

  • ขั้นที่ 3: Earthly CI

    • ไมล์สโตนที่สามคือ Earthly CI
    • Earthly CI คือแพลตฟอร์ม CI แบบครบชุดที่รวม Earthly และ Satellites เข้าด้วยกัน โดยตั้งใจจะแข่งกับ CI อย่าง GitHub Actions, CircleCI และ Jenkins
    • Earthly มุ่งที่ความสม่ำเสมอของการบิลด์ ส่วน Earthly CI มุ่งที่ความเร็วของการบิลด์ จึงมองว่า Earthly เวอร์ชันฟรีจะไม่ไปกินรายได้ของ Earthly CI
    • แต่ภายหลัง ความต่างของคุณค่าระหว่าง ความสม่ำเสมอ กับ ความเร็ว กลับกลายเป็นปัญหา

อุปสรรคในการเปลี่ยนผ่านที่เห็นชัดหลังเปิดตัว

  • Earthly CI ได้ เปิดตัว, ถูกพูดถึงใน TechCrunch และยังเตรียมบล็อกโพสต์สำหรับ Reddit และ HackerNews ไว้ด้วย
  • ในช่วง 1–2 สัปดาห์แรกหลังเปิดตัว มีอีเมลลง waiting list ราว 50 รายการ ซึ่งมากกว่าเป้าหมาย
  • ระหว่างลูกค้าใหม่กับผู้ใช้ Earthly เดิมมีความต่างที่ชัดเจน
    • ลูกค้าใหม่จำนวนมากมองว่า “CI ก็คล้ายกันหมด ต่างกันแค่ไวยากรณ์” และไม่ลงลึกกับความแตกต่างของ Earthly CI
    • บทสนทนาส่วนใหญ่จึงลงเอยที่ ต้นทุนการย้ายระบบ จากการต้องเขียนสคริปต์ใหม่และปรับตัว
    • ผู้ใช้ Earthly เดิมนั้นผ่านการย้ายมาใช้ Earthfile แล้ว และเคยเห็นประโยชน์ของ Earthly มาก่อน จึงพร้อมจะเป็นผู้สนับสนุนภายในองค์กร
  • สำหรับลูกค้าใหม่ Earthly ยังไม่มีชื่อเสียงมากพอว่าให้ประโยชน์ตามที่สัญญาได้ในวงกว้าง และก็ยากที่จะพิสูจน์ประสบการณ์แบบ “ง่ายกว่า 10 เท่า” ผ่านการคุย Zoom สั้น ๆ

ทำไมแม้แต่ลูกค้าเดิมก็ไม่ย้ายมา Earthly CI

  • ลูกค้า Earthly Satellites เดิมส่วนใหญ่ใช้ Satellites อยู่แล้วใน CI/CD ของตัวเอง
  • Earthly มองว่าการที่ผู้ให้บริการ CI ทำหน้าที่แค่ trigger pipeline ส่วนการรันจริงเกิดขึ้นบน Satellites เป็นการพิสูจน์ความจำเป็นของ Earthly CI
  • แต่ในความเป็นจริง ลูกค้า Satellites ได้รับคุณค่า 95% ของ Earthly CI อยู่แล้ว
  • เมื่อเทียบกับการใช้ GitHub Actions + Satellites แล้ว Earthly CI ไม่ได้ดีกว่ามากพอที่จะมีเหตุผลให้ย้าย
  • แม้จะดูเหมือนว่าผู้ใช้ Earthly เดิมน่าจะย้ายได้ง่ายเพราะใช้ Earthfile อยู่แล้ว แต่ความต้องการจริงมีมากกว่านั้น
    • ระบบนิเวศปลั๊กอินของ GitHub
    • codecov action
    • manual trigger
    • trigger จากการสร้าง git tag
    • การเลือกขนาดเครื่อง
    • การยกเลิกบิลด์เก่า
    • ความเชื่อมั่นพอจะฝาก build secrets ไว้ได้
  • Earthly CI MVP เป็น CI ที่เร็วที่สุด แต่ยังไม่ตอบโจทย์ข้อกำหนดสำคัญบางอย่าง
  • มีผู้ใช้สายฮาร์ดคอร์บางรายลองใช้ Earthly CI แต่ก็ไม่ขยายไปสู่การใช้งานกว้างในองค์กรที่มีงบประมาณและมีคนใช้งานเกิน 2–3 คน
  • ผู้ใช้ Earthly CI บางรายภายหลังเปลี่ยนไปเป็นผู้ใช้ Satellites เพื่อให้ได้ทั้งระบบนิเวศ GitHub และความเร็วจาก Satellites

ทำไมคำขอเดโมกลับเป็นสัญญาณลบ

  • Earthly คุยกับลูกค้าที่มีโอกาสเป็นลูกค้ามากกว่า 100 ครั้ง แต่การพูดคุยแบบตัวต่อตัวกลับโน้มน้าวให้ใช้งาน Earthly CI, Satellites หรือ Earthly ไม่ได้ง่ายนัก
  • ในทางกลับกัน เมื่อผู้ใช้เข้ามาเองผ่านเว็บไซต์, product-led growth, การบอกต่อ และ content marketing การนำ Earthly ไปใช้กลับเกิดขึ้นทุกวันและเติบโตอย่างชัดเจน
  • เครื่องมือสำหรับนักพัฒนา โดยเฉพาะเครื่องมือที่ต้องมีงานเชื่อมต่อระบบ มักพิสูจน์ยากผ่านการขายตรงแบบดั้งเดิม
  • เกณฑ์คัดกรองเชิงลบที่ชัดที่สุดคือ ลูกค้าที่มีโอกาสเป็นลูกค้าซึ่งขอเดโม
  • ทีมที่เปลี่ยนมาใช้งานจริงมักดาวน์โหลด Earthly ไปอ่านเอกสาร เขียน Earthfile เอง แล้วจึงค่อยติดต่อกลับมา โดยไม่ต้องการเดโม
  • เครื่องมือสำหรับนักพัฒนาที่ต้องอาศัยงานเชื่อมต่อระบบจะถูกนำมาใช้ตามจังหวะเวลาของผู้ใช้เอง และยากจะเร่งขายหรือผลักดันแบบฝืน ๆ

A/B test ที่เปลี่ยนจาก “CI” เป็น “build”

  • ตอนนั้นข้อความบนเว็บไซต์ Earthly คือ “Earthly makes CI super simple” และพื้นที่ส่วนใหญ่ของหน้าแรกก็เน้นเรื่อง CI
  • Gavin Johnson เสนอให้ทำ A/B test โดยเปลี่ยนคำว่า “CI” บนเว็บไซต์เป็น “build”
  • ข้อความจึงเปลี่ยนเป็น “Earthly makes builds super simple”
  • การเปลี่ยนแค่คำเดียวนี้ทำให้ conversion ของหน้า CTA หลัก “Get Earthly” เพิ่มขึ้นเป็นสองเท่า
  • หลังเห็นผลนี้ ความสงสัยที่มีต่อ Earthly CI เองก็เพิ่มขึ้น

บทเรียนจากประสบการณ์กับ ShiftLeft

  • ShiftLeft ซึ่งเริ่มก่อน Earthly ปัจจุบันใช้ชื่อว่า Qwiet.ai
  • วิสัยทัศน์ช่วงแรกคือ security agent ที่ติดตั้งในโปรดักชันเพื่อปกป้อง cloud app จากการโจมตีที่อาศัยช่องโหว่ในซอร์สโค้ด
  • ผลิตภัณฑ์นี้ต้องใช้ทั้งตัววิเคราะห์โค้ดที่รองรับหลายภาษาโปรแกรม, agent ตาม runtime และ backend แบบกระจายที่รวมทุกอย่างเข้าด้วยกัน ซึ่งซับซ้อนพอ ๆ กับที่สตาร์ทอัพเล็ก ๆ จะสร้างผลิตภัณฑ์เทียบเท่า 3 บริษัทพร้อมกัน
  • หลังพยายามมากกว่าหนึ่งปี ก็ทำงานแบบ end-to-end ได้ในภาษาโปรแกรมหนึ่งภาษา แต่การตอบรับจากตลาดไม่ดี
  • กลุ่มเป้าหมายของผลิตภัณฑ์ความปลอดภัยคือองค์กรขนาดใหญ่ที่มีข้อกำกับดูแลสูง และต้องนำผลิตภัณฑ์เข้าไปทั้งใน CI/CD และในโปรดักชัน ทำให้เส้นทางการนำไปใช้ยากมาก
  • ตอนนั้นมองว่าถ้าเพิ่มฟีเจอร์อีกก็จะเอาชนะความยากในการนำไปใช้ได้ จึงพัฒนาต่ออีกปีครึ่ง แต่ตลาดก็ยังไม่ต้องการ
  • กว่าจะรู้ตัวก็สายไปว่า ผลิตภัณฑ์ที่ซับซ้อนนี้สามารถแยกออกเป็น 2 ผลิตภัณฑ์ต่างหากได้
    • code introspector สำหรับผู้เชี่ยวชาญด้านความปลอดภัย
    • code analyzer แบบแยกอิสระที่ เร็วกว่า 40 เท่า เมื่อเทียบกับตัววิเคราะห์โค้ดอื่นในตลาด
  • สิ่งที่เสียใจที่สุดคือไม่ได้หยุดให้เร็วกว่านี้ตั้งแต่ตอนที่สัญญาณเริ่มปรากฏ

สิ่งที่ Earthly สรุปจากสถานการณ์

  • Earthly สรุปสถานการณ์ไว้ดังนี้
    • ผู้คนต้องการบิลด์ที่เร็วขึ้น
    • ผู้คนไม่ชอบการย้าย CI
    • CI ใหม่มักติดภาพจำว่าไม่แตกต่าง และผู้ใช้ก็มักออกจากเว็บไซต์ทันทีที่เห็นคำว่า “CI”
    • การทำงานกับลูกค้าแบบ design partner ผ่านการติดต่อโดยตรงใช้ไม่ได้ เพราะผู้ใช้รับรู้ต้นทุนการย้ายระบบว่าสูงมาก
    • Earthly CI MVP ไม่สามารถสร้างกลุ่มผู้ใช้ช่วงแรกได้มากพอ
    • เมื่อบอกว่าสามารถได้บิลด์ที่เร็วขึ้นด้วย Earthly Satellites โดยไม่ต้องเปลี่ยน CI เดิม การตอบรับกลับดีขึ้น
  • ปัญหาหลักไม่ใช่เรื่องฟีเจอร์ของ Earthly CI ยังไม่ครบ
  • หากเป็นผลิตภัณฑ์ช่วงแรกที่มีแนวโน้มดีจริง ควรมีกลุ่มผู้ใช้ที่ยอมทนกับฟีเจอร์ที่ยังขาดเพื่อแลกกับประโยชน์ที่ได้รับ แต่ Earthly CI ไม่ได้แสดงสัญญาณระดับนั้นมากพอ
  • ดังนั้น Earthly จึงตัดสินใจยุติ Earthly CI และโฟกัสกับ Earthly และ Earthly Satellites ที่กำลังได้ผลอยู่

กำหนดการยุติและการย้ายของผู้ใช้

  • Earthly CI จะยุติในวันที่ 1 ตุลาคม 2023
  • แม้ Earthly CI จะถูกระบุว่าอยู่ในขั้นเบตาและทดลองใช้งาน แต่ Earthly จะช่วยสนับสนุนการย้ายของผู้ใช้
  • Earthly มองว่าการย้ายออกจาก Earthly CI ทำได้ง่าย เพราะ Earthly ทำงานร่วมกับ CI ใดก็ได้
  • หากยังต้องการบิลด์ที่เร็วต่อไป ก็สามารถเชื่อมต่อ Earthly Satellites ได้ และ Satellites ก็มี free tier ด้วย
  • การช่วยเหลือเรื่องการย้ายจะทำผ่าน Earthly Slack community โดยตรง

ทิศทางการลงทุนต่อไปใน Satellites

  • Earthly Satellites กำลังเห็นสัญญาณการเติบโต เพราะไม่ได้ให้แค่บิลด์ที่เร็วและสม่ำเสมอ แต่ยังเปิดทางให้ผู้ใช้ คง CI เดิมไว้ได้
  • เวลาที่ได้กลับคืนมาจากการยุติ Earthly CI จะถูกนำไปลงทุนกับฟีเจอร์ที่ชุมชน Earthly ขอมา
    • Satellite metrics ที่รวมการใช้ CPU, หน่วยความจำ, ดิสก์ และ network I/O
    • Build history บนเว็บ UI สำหรับทั้งการบิลด์บนโลคัลและบน Satellites
    • Auto-skip ที่ข้ามทันทีเมื่อไฟล์ที่เปลี่ยนไม่มีผลต่อการบิลด์
    • ความสามารถในการรัน Dockerfile build แบบรีโมตบน Satellites เพื่อเป็นทางเลือกที่เร็วกว่า docker build
    • self-hosted Satellites ซึ่งเป็นเวอร์ชันที่รองรับได้ดีกว่าของ self-hosted remote Buildkit
    • ความสามารถในการกระจายบิลด์เดียวไปยัง Satellites หลายตัวเพื่อเพิ่มความเร็ว
    • Compute v2 ซึ่งเป็น Satellites แบบ serverless กระจายเต็มรูปแบบ
  • Earthly Satellites คือ remote build runner ที่ทำงานร่วมกับ CI ใดก็ได้ และใช้งานผ่าน Earthly Cloud ได้
  • Earthly คือโอเพนซอร์ส build framework ที่ให้ความสม่ำเสมอของการบิลด์แบบเขียนครั้งเดียวรันได้ทุกที่ และช่วยให้จำลอง CI failure กลับมาบนเครื่องโลคัลได้ง่าย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-13
ความคิดเห็นบน Hacker News

  • เป็นบทความที่แสดงให้เห็นชัดเจนว่า ทำไมตอนเปิดซอร์สจึงไม่ควรมอบคุณค่าหลักทั้งหมดออกไป เพราะ Earthly เป็นโอเพนซอร์ส ผู้ใช้ Earthly Satellite จึงได้รับคุณค่าของ Earthly CI ไปแล้วถึง 95%
    ผมชอบโอเพนซอร์สมาก แต่ถ้าโอเพนซอร์สเป็นส่วนหนึ่งของโมเดลธุรกิจ ก็จำเป็นต้องมี จุดแตกต่าง ต้องมีเหตุผลให้ผู้คนหยิบบัตรเครดิต หรือไปไกลถึงขั้นดึงกระบวนการใบสั่งซื้อของฝ่ายบัญชีออกมาใช้งาน มากกว่าแค่เร็วมาก ๆ
    GitLab จำกัด CI/CD ไว้ให้ลูกค้าที่จ่ายเงิน, Travis/CircleCI จำกัดเวลา build หรือเครดิต, Azure DevOps ก็เหมือนปีศาจ, ส่วน ArgoCD ก็ซับซ้อน GitHub Actions ใช้ได้ดีถ้ามีฮาร์ดแวร์ไว้รัน runner และในองค์กรระดับ enterprise หลายแห่งก็คุ้นเคยกับฝูง Jenkins อยู่แล้ว
    ในฐานะอดีตผู้อำนวยการ DevOps คำถามแรกที่ผมจะถามคือ “ฟีเจอร์อะไรที่ทำให้ผมต้องซื้อแทนที่จะโฮสต์เอง” ถ้าผมมีความสามารถทางเทคนิคพอจะรันเองได้ และสามารถจัดการคลาวด์กับ DevOps pipeline ให้เหมาะกับธุรกิจของเราได้ ก็ต้องโน้มน้าวให้ได้ว่าทำไมผมควรจ่ายเงินให้คุณ
    ไม่ได้หมายความว่าควรซ่อนฟีเจอร์ที่จำเป็นต่อการทำงานของซอฟต์แวร์ แต่หมายถึงการเก็บฟีเจอร์เชิงธุรกิจ เช่น support หรือการเชื่อมต่อระดับ enterprise ไว้เป็นแบบเสียเงิน โครงสร้างแบบเป็น tier ก็อาจเป็นไปได้ โดยผู้ใช้ขั้นสูงที่ช่วยเหลือตัวเองได้มากกว่าก็จ่ายน้อยกว่า

    • ไม่แน่ใจว่าในสายเครื่องมือนักพัฒนา การจำกัดฟีเจอร์ เคยได้ผลดีตามธรรมเนียมหรือไม่ เพราะอัตราการเลิกใช้เครื่องมือสูงมาก ถ้า Earthly ตั้งใจทำให้ผลิตภัณฑ์อ่อนลง นักพัฒนาส่วนใหญ่น่าจะย้ายไปใช้ทางเลือกฟรีที่อาจด้อยกว่า เช่น taskfile
      อาจเปลี่ยนผู้ใช้ที่เหลือให้เป็นผู้ใช้แบบจ่ายเงินได้ก็จริง แต่เป็นการเดิมพันที่ค่อนข้างใหญ่ ตัวอย่างพลิกเกมที่ดีเมื่อไม่นานมานี้อาจเป็น Docker แต่กรณีนั้นต้องผ่านกระบวนการเลิกยึดโอเพนซอร์สแบบเคร่งครัด และเปลี่ยนไลเซนส์/ผลิตภัณฑ์ที่ก่อข้อถกเถียงมาก
    • พอเห็นประโยคที่ว่า “ในองค์กรระดับ enterprise หลายแห่งก็คุ้นเคยกับฝูง Jenkins อยู่แล้ว” ผมก็รู้สึกโล่งใจแบบแปลก ๆ เพราะนึกว่ามีแค่องค์กรเราองค์กรสุดท้ายที่ยังใช้ ชุดประกอบอันไม่ศักดิ์สิทธิ์ นี้ ที่ไหนได้มันกลายเป็นมาตรฐานในระดับหนึ่ง
    • GitLab CI runner สามารถโฮสต์เองได้ และใช้ได้แม้ในเวอร์ชัน Community ฟรี
    • อาจเป็นประเด็นถกเถียงได้ แต่สำหรับบริการ ผมอยากให้แนวทาง เปิดเผยซอร์สเชิงพาณิชย์ (source available) กลายเป็นกระแสหลักและโดนด่าน้อยกว่า “open core”
      การที่อ่านโค้ดนอก “open core” ไม่ได้, ช่วยแก้บั๊กไม่ได้, หรือโฮสต์เองไม่ได้ เป็นเรื่องน่าหงุดหงิดมาก และปัจจัยที่แยกไลเซนส์โอเพนซอร์สออกจากไลเซนส์แบบเปิดเผยซอร์สก็ไม่ได้จำเป็นสำหรับผมเท่าไร
    • ถ้ามีใครจัดการเรื่อง การทำให้ applicationset เป็นแพตเทิร์น ได้ดี ก็น่าจะห่อ ArgoCD เป็นผลิตภัณฑ์ได้ D2iQ ทำแบบนั้นกับ Flux อยู่แล้ว แต่พวกเราออกจาก D2iQ ก่อนที่จะได้ลองใช้

  • ไม่ได้อยากสาดน้ำเย็นใส่ แต่สิ่งนี้พูดตรง ๆ แล้วใกล้เคียงกับ ผลิตภัณฑ์แบบคัดลอกวาง มาก
    มี Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines อยู่แล้ว และถ้าดูที่มาของทีมว่าเป็นอดีต Google, อดีต VMW, RabbitMQ ก็ไม่น่าแปลกใจ
    แม้ผู้เขียนต้นฉบับจะไม่ได้อยู่ใกล้ต้นทางของเครื่องมือเหล่านั้น อย่างน้อยก็เป็นญาติห่าง ๆ ของเรื่องเดียวกัน
    วงจรการขายยาว และการเชื่อมต่อต้องได้รับความเห็นชอบจากผู้บริหารในหลายมิติ รวมถึงความปลอดภัยและเครือข่าย
    พวกเขาสร้างของดีขึ้นมาก็จริง แต่ปัญหาต้นน้ำซับซ้อนเกินไป จนรู้สึกเหมือนเป็นเรื่องที่ไม่ค่อยมีสาระในพื้นที่ที่แกว่งไปมาระหว่างของทำเฉพาะทางกับสินค้าทั่วไป มีทั้งตั้งแต่การขาดการกำกับดูแลไปจนถึง micromanagement ตั้งแต่ความไม่สุกงอมไปจนถึงประสบการณ์ที่มากเกินจนวาง “วิธีที่ทำกันมาตลอด” ไม่ลง
    อาจเป็นความเห็นที่ไม่เป็นที่นิยม แต่การขาย toolchain แบบนี้เท่ากับพยายามต้มมหาสมุทรของปัญหา ธุรกิจและเทคโนโลยีไหลเหมือนน้ำไปหาช่องที่มีแรงต้านน้อยที่สุด และระหว่างทางก็อาจกัดเซาะฐานของ “ธุรกิจหลัก” ได้ จากประสบการณ์ของผม toolchain ที่ทำตัวเหมือนแนวทางหรือ “กลยุทธ์การเลี้ยงดู” พร้อม guardrail แบบถอดออกได้ ให้ผลตอบแทนมากที่สุด

    • ที่สำคัญกว่านั้น ผลิตภัณฑ์นี้ไม่มีเหตุผลเพียงพอแม้แต่จะใช้ นับประสาอะไรกับ เหตุผลให้จ่ายเงิน
      “เร็ว” ไม่ใช่จุดขาย นักพัฒนาไม่ได้ต้องการ pipeline ที่ช้า แต่ก็ไม่ได้แปลว่าต้องการ pipeline ที่เร็วเป็นพิเศษ
      ความเร็วของ pipeline ขึ้นอยู่กับวิธีจัดโครงสร้าง pipeline มากกว่า overhead ของบริการ pipeline และบริการ CI/CD อื่น ๆ ก็เร็วมากอยู่แล้ว ตัวอย่างเช่น CircleCI ยังขายได้ไม่ง่ายเมื่อเทียบกับ GitHub Actions และ GitLab CI/CD แล้วบริการนี้แตกต่างอย่างไร? เพิ่มคุณค่าจริงเมื่อเทียบกับ GitHub/GitLab/CircleCI ฯลฯ หรือไม่? การลดระดับมิลลิวินาทีใน build ที่กินเวลาหลายนาทีไม่ใช่คำตอบ

  • เหตุผลที่ล้มเหลวคือการตลาดหยาบอย่างโจ่งแจ้งและค่อนข้างไม่ซื่อสัตย์
    ไม่ว่าจะคอมไพล์ด้วย Jenkins, Actions หรือ Earthly ถ้าใช้ build node เดียวกัน เวลา compile ก็จะเท่ากัน การอ้างว่าเร็วกว่า 20 เท่าในสถานการณ์ที่ CI เริ่มทำงานได้ภายในไม่กี่วินาที แทบไม่มีความหมาย
    caching และการรันแบบขนานเป็นแนวคิดเก่าใน CI และ build system สมัยใหม่ทั้งหมดก็ทำได้
    แก่นของ CI คือ feedback แต่แทบไม่เห็นแง่มุมเรื่องการทำงานร่วมกันหรือการดึงข้อมูลขึ้นมาให้เห็นเด่นชัด ผมไม่ได้ดูละเอียดนัก แต่สิ่งนี้ควรอยู่ด้านหน้า สุดท้าย ผมไม่อยากนำ DSL มาใช้กับการ build อีกแล้ว

    • การตั้งค่า caching และ parallelization ด้วย GitHub Actions, Jenkins, Docker, Make ยากกว่าการทำด้วย Earthly เพียงตัวเดียวมาก
    • ช่วยอธิบายเพิ่มได้ไหมว่าคำว่า “feedback” หมายถึงอะไร? อยากรู้ว่าคาดหวัง feedback แบบไหนใน CI

  • CI ที่เร็ว หมายถึงอะไรกันแน่?
    CI ก็คือเชลล์สคริปต์ที่โตเกินไป ซึ่งรันบิลด์แล้วแจ้งให้รู้เมื่อมีความล้มเหลว โดยทั่วไปเครื่องมือบิลด์เองช้าจนค่าใช้จ่ายของตัวรัน CI เมื่อเทียบกันแล้วควรแทบเป็น 0
    ถ้าต้องการ CI ที่เร็ว tsc, clang, rustc ฯลฯ ต้องเร็วต่างหาก ไม่ใช่โปรแกรมที่เรียกสิ่งเหล่านั้นด้วย exec ต้องเร็วขึ้น
    ถ้าพูดให้ตรงประเด็นกว่านี้ ถ้าคุณขาย CI อยู่แต่ธุรกิจล้มเหลว ก็เพราะคุณให้คุณค่าไม่ได้ ผู้คนรันสคริปต์บิลด์ได้ดีแม้ไม่มีคุณ

    • ผมลองกวาดตาอ่านบทความเร็ว ๆ ดู เหมือนว่าสิ่งที่พูดถึงตรงนี้คือ CI ที่จัดการเรื่องอย่างการแคชผลลัพธ์จากการบิลด์ให้อัตโนมัติ เพื่อไม่ต้องคอมไพล์ทั้ง repository ใหม่ทุกคอมมิต
      ไม่ได้พูดว่าโปรแกรมที่เรียก exec เร็วกว่า แต่พูดถึงโปรแกรมที่รู้ตั้งแต่แรกว่าไม่จำเป็นต้องเรียก exec
    • ถ้าจะบอกว่า “CI คือเชลล์สคริปต์ที่โตเกินไป ซึ่งรันบิลด์แล้วแจ้งเมื่อมีความล้มเหลว” ก็อยากให้มันง่ายแบบนั้นจริง ๆ
      ไม่รู้ว่าวัดอะไรมาบ้าง แต่ยกตัวอย่างหนึ่ง หน้า landing page เริ่มต้นของ Jenkins เป็นหายนะด้านความเร็ว มันพยายามแสดงข้อมูลบิลด์ล่าสุดของทั้งคลัสเตอร์ไปทั่ว และแม้แต่ในคลัสเตอร์ที่ไม่ได้ใหญ่มาก ก็อาจต้องดึงรายการหลายร้อยถึงหลายพันรายการจากแต่ละโหนดที่รันบิลด์แต่ละงาน
      แค่โหลด landing page โดยไม่มีการตั้งค่าเฉพาะเพื่อกันพฤติกรรมเริ่มต้นนี้ ผมก็เคยทำ Jenkins ล่มมาแล้วนับครั้งไม่ถ้วน
      เซิร์ฟเวอร์ CI มักมีฐานข้อมูลของตัวเอง และจัดการเอนทิตี CI สารพัดอย่าง เช่น งาน ผลลัพธ์จากการบิลด์ ผู้ใช้ และ secret ต่าง ๆ มันอาจใหญ่ได้พอสมควร และต้องดูแลเรื่องอย่างการทำ index ให้เหมาะสม
      CI มี runner หลายตัว และตัวเหล่านี้มักถูก provision แบบไดนามิก ลองคิดว่าต้องกระจาย VM หรือ Docker image ไปยังโหนด runner การกระจายสิ่งนี้ไปทั่วคลัสเตอร์ให้เร็วก็ไม่ใช่งานง่าย ผลลัพธ์จากการบิลด์ก็คงอยากกระจายไปทั่วคลัสเตอร์เช่นกัน ซึ่งก็ใช้ทั้งเวลาและทรัพยากร
      ในทางปฏิบัติ CI ยังต้องมีงานดูแลบัญชีภายในของตัวเองสำหรับ garbage collection, การรายงาน และ self-diagnostics ด้วย ในคลัสเตอร์ที่ใหญ่พอ ถ้าไม่พยายามลด latency เป็นพิเศษ ทุกอย่างนี้อาจสร้าง latency สูงมากได้
      เคยได้ยิน ccache ไหม?
      แต่พูดจริง ๆ นะ การบอกว่า “แค่มี tsc/clang/rustc ที่เร็วก็พอ” นั้นไร้เดียงสาเกินไป การจะทำให้บิลด์เร็วในระบบกระจายอย่าง CI ต้องแก้ด้วยว่าจะแจกจ่ายแคชนี้อย่างไร และจะแยกบิลด์เป็นโมดูลอย่างไร คุณคงเคยได้ยินว่าหนึ่งในสิ่งที่ยากที่สุดในการเขียนโปรแกรมคือ cache invalidation ซึ่งเป็นมุกเพียงบางส่วนเท่านั้น
    • ส่วนเดียวในข้อเสนอของ Earthly ที่โดนใจผมคือการที่สามารถ รัน CI บนเครื่อง local ได้ เวลา debug CI ถ้ารันบนคอมพิวเตอร์ตัวเองได้ ก็หาปัญหาได้เร็วขึ้นมาก
      ผมใช้เวลานานกับการปรับสคริปต์ GitHub Actions ที่ค่อนข้างรก เพราะรอบการ debug คือ 10 นาที
    • ทั้งใช่และไม่ใช่ การแคชและการรู้ว่าเมื่อไรควรรัน tsc/clang/rustc ก็ช่วยปรับปรุงประสิทธิภาพได้เช่นกัน
    • ส่วนที่ยากของ CI คือการหา งานที่ไม่จำเป็นต้องทำ ตรงนั้นแหละที่ประหยัดเวลาได้

  • ดีใจที่เขาแค่ปิดบริการ ไม่ได้ปิดทั้งบริษัท เครื่องมือนี้ผมชอบมาก ถึงขั้นเข้าไปดูหน้ารับสมัครงานอยู่บ่อย ๆ
    ไวยากรณ์ของ Earthfile เป็นวิวัฒนาการที่สมเหตุสมผลและค่อยเป็นค่อยไปมากของไวยากรณ์ Dockerfile และทำให้หลายอย่างที่ทำด้วย Dockerfile อย่างเดียวไม่ได้ หรือทำได้แบบฝืนมาก กลายเป็นเรื่องง่าย
    จำได้ว่าตอน Docker นำ BuildKit กับ buildx เข้ามา พวกเขาพยายามผลัก Dockerfile ให้เป็นระบบบิลด์อเนกประสงค์ คือใช้สร้างไม่ใช่แค่คอนเทนเนอร์ แต่รวมถึงผลลัพธ์เป็นไฟล์ต่าง ๆ ด้วย Earthly ทำไอเดียนั้นออกมาได้ดีจริง ๆ

    • ลองใช้ Dagger ดูก็ดี ผมว่าดีกว่า Earthly
      ใช้อย่างพอใจอยู่ แต่ยังไม่ได้จ่ายเงิน

  • เอาตรง ๆ แค่อ่านบทความนี้อย่างเดียวก็เข้าใจยากอยู่ดีว่าเกิดอะไรขึ้น อ่านไปหลายรอบแล้วคำศัพท์ก็ยังสับสนอยู่ ดูเหมือนอย่างน้อยมีปัญหาแยกกันสองอย่าง
    ปัญหาการ ย้ายการตั้งค่า CI จาก CI YAML เดิม คือ GitHub/GitLab ไปเป็น Earthly ซึ่งเป็นลูกผสมระหว่าง Makefile/Dockerfile
    ปัญหาการ ย้ายตัวรันงาน จาก CI เดิมไปเป็นบริการที่ Earthly โฮสต์ให้
    ผมคิดว่าอย่างแรกเป็นเรื่องยาก เพราะการเปลี่ยนภาษาอาจใช้เวลาหลายเดือนหรือหลายปีก็ได้
    แต่ไม่ค่อยแน่ใจว่าบล็อกนี้พยายามจะบอกอะไร คิดว่าตรงส่วนนั้นพวกเขาตรวจสอบความถูกต้องแล้วไม่ใช่หรือ หมายความว่าผู้คนสามารถย้ายมาใช้ได้ไม่ใช่หรือ?
    แต่ตอนท้ายกลับบอกว่ายังไม่ได้ตรวจสอบ ลูกค้าต้องทำการย้ายระบบสองครั้ง ไม่ใช่แค่ครั้งเดียวอย่างนั้นหรือ?
    แล้วตอนนี้จะเป็นอย่างไรต่อ? จะคงไวยากรณ์ของ Earthly ไว้ แต่เลิกทำ CI อย่างนั้นหรือ? ส่วนที่ย้ายยากไม่ใช่ไวยากรณ์นั้นเองหรือ? ยังสับสนอยู่ดี

    • ดีใจที่ไม่ใช่ผมคนเดียวที่รู้สึกแบบนั้น ผมสนใจทั้งฝั่งการพัฒนาผลิตภัณฑ์และฝั่งเครื่องมือสำหรับนักพัฒนา แต่พออ่านบทความที่ค่อนข้างสับสนนี้แล้วก็อยู่ในสภาพประมาณว่า “ดีใจด้วยนะ หรือไม่ก็เสียใจด้วยนะ”
      ประเด็นหลักคือพวกเขาสมมติว่า build ที่เร็วขึ้นมากเป็น killer feature แต่ไม่ได้ตรวจสอบสมมติฐานนั้นก่อนสร้างหรือเปล่า? หรือว่าแบ่งกลุ่มผู้ใช้ไม่ดีพอจนไม่รู้ว่าความต้องการของลูกค้ารายใหญ่ต่างออกไป? หรือว่าเอาสิ่งที่แก้ปัญหาจริงของลูกค้าที่จ่ายเงินไปปล่อยให้ใช้ฟรีเฉย ๆ?
      และพอเห็นว่าบทความที่ค่อนข้างสับสนนี้เขียนโดย CEO ก็เลยสงสัยว่าความสับสนนั้นเป็นแค่เพราะขาดการแก้ไขเรียบเรียง หรือว่าตลอดกระบวนการนั้นภายในบริษัทเองก็มีความสับสนจริง ๆ อยู่มาก
      นานมาแล้ว Steve Blank เขียนในบทความ “Founders and dysfunctional families” [1] ว่าผู้ก่อตั้งจำนวนมากเติบโตมากับความวุ่นวาย จึงเก่งในการจัดการความวุ่นวาย ซึ่งก็ตรงกับผมอย่างชัดเจนด้วย เขาเสริมว่าความแตกต่างระหว่างความสำเร็จกับความล้มเหลวอาจขึ้นอยู่กับว่าผู้ก่อตั้งรับมือกับ สภาวะที่ไม่วุ่นวาย ได้หรือไม่
      ผู้ก่อตั้งที่ทำแบบนั้นไม่ได้มักจะโยน “ระเบิดมือเชิงองค์กร” ใส่บริษัทตัวเอง เพื่อพยายามพากลับไปสู่ระดับความวุ่นวายที่ตัวเองถนัด ข้อสังเกตนั้นทำให้ผมหยุดคิดหลายครั้งตลอดหลายปีหลังจากนั้น
      [1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
    • นี่ไม่ใช่ปัญหาเรื่องการย้ายไวยากรณ์
      CI ของผู้คนเมื่อเวลาผ่านไปจะกลายเป็นโมเดลผสมที่ครอบทุกอย่างเกี่ยวกับวิธีที่แต่ละบริษัทสร้างและ deploy ซอฟต์แวร์ของตัวเอง ให้นึกถึงสถานการณ์ที่ใช้ CI ผิดวัตถุประสงค์เหมือนเป็นตัวรันงานอัตโนมัติแบบใดก็ได้อย่าง Airflow
      การย้ายระบบเริ่มจากการ reverse engineer สิ่งที่คนเคยรู้กันมาก่อน แล้วหลังจากนั้นจึงจะคลี่ทุกอย่างออกมาและแสดงมันในรูปแบบอื่นได้
      ไม่มีใครอยากหยุดโลกเพื่อมาจัดระเบียบเรื่องนั้น

  • บทความนี้สับสนเพราะผู้เขียนอยู่ใกล้ปัญหามากเกินไป และจำเป็นต้องอธิบายจากมุมมองของคนนอกก่อนลงรายละเอียด ถึงอย่างนั้นก็ดูเหมือนว่าข้อมูลที่จำเป็นมีอยู่
    โดยสรุป ดูเหมือนว่าพวกเขาสร้าง ชั้น encapsulation ระหว่างระบบ build เฉพาะภาษา กับระบบ continuous build ที่รันมัน
    ถ้าเปรียบเทียบก็มีของอย่าง Bazel ซึ่ง Bazel ทำได้ทุกอย่าง แต่ถ้าจะนำมาใช้เต็มรูปแบบก็ต้องทุ่มสุดตัวกับการแทนที่ระบบ build เฉพาะภาษาด้วยภาษา build ของ Bazel และบ่อยครั้งก็ต้องย้ายตำแหน่งไฟล์ซอร์สเพื่อให้มันทำงานได้
    สิ่งนี้อาจรู้สึกแปลกเมื่อเทียบกับการใช้ระบบ build ของภาษานั้น ๆ เอง แต่สำหรับโปรแกรมเมอร์ C ซึ่งภาษาไม่มีระบบ build ของตัวเอง มันอาจเป็นเรื่องธรรมชาติ ส่วน Java ก็ผ่านระบบ build ที่น่าเศร้าหลายตัว ก่อนจะลงเอยอย่างน่าเสียดายกับ Gradle
    ระบบ build เฉพาะภาษาจะไม่ได้ทำทุกอย่างในท้ายที่สุด เพราะแต่ละภาษามีขนบและ ecosystem ต่างกัน เครื่องมือสมัยใหม่จะรู้ว่าตัวเองถนัดขอบเขตไหนและอยู่ในขอบเขตนั้น
    ดังนั้นเครื่องมือที่เข้าใจหลายภาษาและ artifact ต่าง ๆ ได้จริงจึงมักเป็น shell script, makefile, Dockerfile หรือระบบ continuous build เอง กระทั่งทำด้วยมือก็มี ชั้นที่พวกเขาพยายามปรับปรุงก็คือตรงนี้เอง
    เพียงแต่ว่า insight พื้นฐานว่าทำไมแนวทางของพวกเขาถึงดีกว่ายังจับได้ไม่ชัดเจน

  • ก่อนหน้านี้เคยดู Earthly ผ่าน ๆ เพราะเรื่องงาน เพราะต้องเขียนการเชื่อมต่อสำหรับแพลตฟอร์ม CI หลายตัว ทั้ง GitLab, Azure DevOps, Jenkins และอาจรวมถึง GitHub Actions ด้วย
    สุดท้ายเลือก Dagger ซึ่งเป็นผลิตภัณฑ์ที่คล้ายกันมาก เป็น BuildKit frontend อีกตัวที่ใช้ได้ดีและเชื่อมกับระบบ CI หลายระบบได้ และตอนนั้น DSL ที่ใช้สำหรับนิยาม pipeline ดูดีกว่า
    แต่สุดท้ายก็มาเสียใจอย่างหนักกับการตัดสินใจนี้ เพราะนักพัฒนา Dagger แทบจะทิ้งภาษานั้นไป แล้วหันไปปล่อย SDK สำหรับภาษาโปรแกรมยอดนิยมจำนวนมากแทน ทั้งหมดเป็นแบบ imperative ทั้งหมดเป็น Turing-complete และในความเห็นผมไม่เหมาะกับโดเมนนี้
    ดังนั้นตอนนี้เลยกลับลงนรกอีกครั้ง ต้องเชื่อมระบบทั้งหมดพวกนี้ด้วยมือ และลังเลที่จะฝากเครื่องมือประเภทนี้ไว้กับสตาร์ทอัพอีก
    สำหรับผม กรณีใช้งานที่น่าสนใจที่สุดของสิ่งอย่าง Earthly ก็ยังเป็นเรื่องนี้อยู่ มาตรฐานของระบบ CI แทบทั้งหมดคือ “push แล้วดูว่าเกิดอะไรขึ้น” ซึ่งเป็น workflow ที่แย่มาก
    ถ้าต้องสนับสนุนทีมในองค์กรขนาดใหญ่ที่ใช้แพลตฟอร์ม CI/CD หลากหลาย สิ่งอย่าง Earthly ช่วยลดความเจ็บปวดได้มากทีเดียว แต่ความน่าสนใจไม่ได้อยู่ที่การเพิ่ม CI อีกตัวหนึ่ง แต่อยู่ที่ การรองรับแพลตฟอร์ม CI ที่มีอยู่เดิม อย่างตรงจุด

    • โดยธรรมชาติแล้ว CI/CD และ provisioning เป็นงานที่ลำดับมีความสำคัญ ดังนั้นโดยส่วนตัวผมชอบ แนวทาง SDK มากกว่า implementation ด้วย CUE
      ปัญหาหลักของ implementation ด้วย CUE แบบเดิมคือพยายามทำให้ตัวแก้ directed acyclic graph ของ BuildKit กับตัวแก้ directed acyclic graph ของ CUE เข้ากัน แต่ทั้งสองทำงานกันคนละทิศทาง
      เมื่อประมาณ 3 ปีก่อน ในฐานะผู้เชี่ยวชาญ CUE ผมเคยพยายามช่วยแก้ปัญหานี้ สำหรับ Dagger ผมคิดว่า SDK เป็นวิธีแก้ที่ดีกว่ามาก
      ไม่ว่าจะชอบหรือไม่ อุตสาหกรรมส่วนใหญ่ก็กำลังขยับไปทางนี้ Pulumi ก็เป็นอีกตัวอย่างหนึ่ง ผมเชื่อแล้วกับโครงสร้างพื้นฐานคลาวด์แบบ imperative และ build ก็ดูเหมือนจะเข้ากับแนวทางนี้ได้ในระดับหนึ่ง
      อีกอย่างคือ ผมตั้งใจจะสำรวจการจัดวาง CUE + Dagger แบบใหม่ แต่จะทำงานต่างจาก Dagger engine แบบเดิม
    • ในฐานะ CEO ของ Dagger ขอพูดว่า เรามี SDK สำหรับภาษายอดนิยม และใช่ ภาษาเหล่านั้นเป็นแบบ imperative แต่ Dagger ยังคงเป็น ระบบแบบ declarative ดังนั้นส่วนที่คุณชอบในเวอร์ชันแรก ๆ ยังอยู่เหมือนเดิม
      แก่นคือเราย้ายชั้น declarative จากการตั้งค่า CUE แบบ static ไปเป็น GraphQL query แบบ dynamic แล้วสร้าง client library หลายภาษาจาก GraphQL schema
      ดังนั้นไม่เพียงแต่ยังประกอบ directed acyclic graph แบบ declarative ได้เหมือนเดิม แต่ยังทำได้ด้วยภาษาใดก็ได้ที่คุณชอบด้วย จะรัน DAG โดยตรงด้วย GraphQL ล้วน ๆ ก็ได้ ดู https://play.dagger.cloud ที่ลองได้ทันทีในเบราว์เซอร์
      อุปมาที่เป็นประโยชน์คือ SQL, SQL เป็นภาษา declarative แต่โดยทั่วไปใช้ร่วมกับภาษาอื่น ซึ่งมักเป็นภาษา imperative
      หวังว่าคำอธิบายนี้จะช่วยให้คุณลองพิจารณา Dagger อีกครั้ง

  • มีคำว่า “build เร็วขึ้น 2–20 เท่า” ปรากฏหลายครั้งตลอดบทความ เทียบกับอะไร? ถ้าไม่มี baseline ประโยคนี้ก็เป็นคำโฆษณาไร้ค่านั่นแหละ

    • เทียบกับ build ที่รันบนแพลตฟอร์มอื่นโดยไม่มี caching และไม่มี parallelization

  • ส่วนที่ว่า “ทำไมไม่ทำให้ stack ง่ายขึ้นล่ะ? อย่าจ่ายเงินทั้งให้ผู้ให้บริการ CI และเรา จ่ายให้เราอย่างเดียวก็พอไม่ใช่หรือ?” ก็เพราะ CI ที่พวกเขา “จ่ายเงินให้” นั้นมาพร้อมกับ stack ส่วนที่เหลือ GitLab กับ GitHub มีอะไรเยอะกว่าผลิตภัณฑ์ CI ธรรมดามาก
    ส่วนที่ว่า “คนใหม่ ๆ มอง Earthly CI อย่างสงสัย คิดว่า CI ทุกตัวเหมือนกัน ต่างกันแค่ syntax แล้วก็ไม่ดูต่อ” ก็เข้าใจได้
    พวกเราไม่ได้สนใจ CI ในตัวมันเองมากนัก แค่ต้องมีและทำงานได้ถูกต้องก็พอ
    ถ้าแอปมี CI manifest ที่ใช้งานได้ แอปใหม่ก็เอา manifest เดิมมา find-and-replace ไม่กี่จุดแล้วใช้ต่อ อาจมีความเจ็บปวดตอนสร้างครั้งแรก แต่ดูจากตัวอย่างแล้วก็ไม่ได้ดูง่ายกว่าการทำสิ่งเดียวกันใน GitLab สักเท่าไร
    พูดตรง ๆ ถ้าใส่ ตัวแปลง ที่รับ config ของ GitLab หรือ GitHub CI แล้วแปลงเป็น Earthfile ได้ทันที อย่างน้อยก็น่าจะทำให้คนลองใช้ได้