แทนค่าบริการ Heroku เดือนละ 3,000 ดอลลาร์ด้วยเซิร์ฟเวอร์เดือนละ 55 ดอลลาร์

 (disco.cloud)
13 คะแนน โดย GN⁺ 2025-10-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แพลตฟอร์มหางานภาคไม่แสวงหากำไร Idealist ย้ายไปใช้ dedicated server ราคาประหยัดเพื่อแก้ปัญหา ต้นทุนสภาพแวดล้อม staging ที่สูง บน Heroku
  • บน Heroku มีโครงสร้างคิดค่าบริการแยกตามแต่ละ environment ทำให้แต่ละ staging environment มีค่าใช้จ่ายราว 500 ดอลลาร์ต่อเดือน
  • เพื่อทดแทนสิ่งนี้ ทีมได้ตั้งหลาย environment บน Hetzner CCX33 server (55 ดอลลาร์ต่อเดือน) เพียงเครื่องเดียว และใช้ Disco เพื่อคงประสบการณ์ git push และการทำงานอัตโนมัติ แบบเดียวกับ Heroku
  • staging environment จำนวน 6 ชุดทำงานได้อย่างเสถียรบนเซิร์ฟเวอร์เครื่องเดียว โดยใช้ CPU 2% และใช้หน่วยความจำ 14GB จากทั้งหมด 32GB จึงยังมีทรัพยากรเหลือเฟือ
  • ผลลัพธ์คือ staging environment เปลี่ยนจาก “ภาระด้านต้นทุน” ไปเป็น “ทรัพยากรที่สร้างเพิ่มได้อย่างอิสระ” ทำให้วัฒนธรรมการทดลองและการ deploy ของทีมพัฒนาดีขึ้นอย่างมาก

ประสบการณ์จริงกับกลยุทธ์ลดค่าใช้จ่าย Heroku แบบใช้งานได้จริง

ปัญหา: staging environment เดือนละ 500 ดอลลาร์

  • Idealist.org เป็นแพลตฟอร์มหางานภาคไม่แสวงหากำไรขนาดใหญ่ที่มีผู้เข้าชมหลายล้านคนต่อเดือน จึงจำเป็นต้องมี staging environment ที่เกือบเหมือน production จริง
  • บน Heroku ค่าใช้จ่ายของ staging environment หนึ่งชุดที่ประกอบด้วย web/worker dyno และ addon ที่จำเป็นอย่าง Postgres อยู่ที่ราว 500 ดอลลาร์/เดือน
  • แค่คงไว้ 2 ชุดคือ dev และ main ก็เกิดต้นทุนคงที่เกิน 1,000 ดอลลาร์แล้ว
  • รูปแบบการตั้งราคาของ Heroku คือ คิดค่าบริการตาม environment ต่อให้ลดจำนวน dyno ก็ประหยัดได้ไม่มาก และยิ่งมีแอปมากค่าใช้จ่ายก็ยิ่งพุ่งสูง

การทดลอง: ย้ายมาที่เซิร์ฟเวอร์เครื่องเดียว

  • เพื่อทดสอบการลดต้นทุนอย่างจริงจัง ทีมเริ่มจากเช่า Hetzner CCX33 server (55 ดอลลาร์ต่อเดือน) เพียงเครื่องเดียว
  • ใช้ Disco solution เพื่อนำรูปแบบ deploy ด้วย git push แบบเดิมของ Heroku มาใช้บนเซิร์ฟเวอร์ได้ตรง ๆ
  • ทุก staging environment ใช้ Postgres instance แบบใช้ร่วมกัน บนเซิร์ฟเวอร์เดียวกัน จึงลดภาระค่าใช้จ่ายฐานข้อมูลแบบ managed ได้มาก
  • ในมุมของการทดสอบ วิธีนี้ยังเหมาะเพราะสามารถรีเซ็ต ฐานข้อมูลแยกตามนักพัฒนา ได้อย่างง่ายดาย

เหตุผลที่ใช้ Disco: แตกต่างจาก Docker Compose อย่างไร

  • การรันแค่ docker-compose up บนเซิร์ฟเวอร์อย่างเดียว ยังให้ประสบการณ์นักพัฒนาที่ไม่ดีพอ
  • Disco ให้ข้อดีดังต่อไปนี้
    • มีกระบวนการ deploy ด้วย git push แบบเดียวกับ Heroku
    • รองรับ zero-downtime deploy อัตโนมัติ สำหรับทุก deployment
    • ออกและต่ออายุ ใบรับรอง SSL อัตโนมัติ สำหรับ URL ของแต่ละ branch
    • มีเว็บ UI ที่ใช้งานเข้าใจง่ายสำหรับ จัดการ log และ environment
  • จึงยังได้ความสะดวกในการ deploy โดยไม่ต้องสร้างและดูแลระบบอัตโนมัติขึ้นมาเอง

การเพิ่มจำนวน staging environment และประสิทธิภาพการใช้ทรัพยากรเซิร์ฟเวอร์

  • การใช้ Disco ทำให้ ขยาย staging environment ได้ง่ายมาก
  • บนเซิร์ฟเวอร์เครื่องเดียว ทีมรัน environment ต่อไปนี้พร้อมกันได้
    • main branch
    • feature-freeze branch
    • throwaway environment ชั่วคราวสำหรับ PR
    • environment ระยะยาวสำหรับการพัฒนาฟีเจอร์ขนาดใหญ่ เป็นต้น
  • ปัจจุบันรัน 6 staging environment ที่แยกอิสระจากกัน ได้โดยไม่มีปัญหา
  • ถ้าเป็นบน Heroku จะต้องจ่ายถึง 3,000 ดอลลาร์ต่อเดือน แต่บน Hetzner ใช้เพียง CPU 2%, หน่วยความจำ 14GB (จาก 32GB) ในโครงสร้างต้นทุนต่ำนี้

Trade-off และข้อพิจารณาในโลกความจริง

  • นี่ไม่ใช่ทางเลือกทดแทนแบบสมบูรณ์ และมี ภาระด้านการดูแลระบบ เพิ่มขึ้นบางส่วน
  • งานโครงสร้างพื้นฐานอย่างการตั้งค่า DNS และ CDN สำหรับแต่ละ environment ใหม่ ยังไม่ได้ทำเป็นอัตโนมัติ
  • มี ความรับผิดชอบด้านปฏิบัติการ เพิ่มขึ้น เช่น monitoring เซิร์ฟเวอร์, security update และการรับมือเมื่อเกิดปัญหา
  • เนื่องจาก Hetzner มี region ในสหรัฐฯ จำกัด จึงอาจไม่เหมาะกับ production service ที่ให้บริการผู้ใช้ในสหรัฐฯ
  • หากเซิร์ฟเวอร์ล่ม ก็ต้องยอมรับ trade-off ด้านความพร้อมใช้งาน ที่อาจต้องติดตั้งใหม่
  • ทีมต้องใช้เวลางานวิศวกรรมประมาณหนึ่งวันเพื่อปรับแอปให้เข้ากับ Docker networking

Insight และการเปลี่ยนแปลงที่ได้รับ

  • หลังใช้งานมานานกว่า 6 เดือน โครงสร้างพื้นฐานนี้ก็กลายเป็น สถาปัตยกรรมถาวร
  • การเปลี่ยนแปลงที่สำคัญที่สุดไม่ใช่แค่การลดต้นทุน แต่คือการที่ staging environment ถูกมองใหม่ว่าเป็น ทรัพยากรที่มีอย่างอุดมสมบูรณ์และใช้ได้อย่างอิสระ
  • นักพัฒนาจึงสามารถสร้าง environment แยกตาม pull request ได้อย่างอิสระทุกครั้งที่ต้องการ โดยไม่ต้องขออนุมัติหรือกังวลเรื่องค่าใช้จ่าย
  • ภายในทีมได้ข้อสรุปว่า ไม่ใช่แค่ภาระด้านต้นทุนเท่านั้น แต่ การลังเลที่จะใช้งานต่างหากที่เป็นความสูญเสียที่แท้จริง
    • "ภาระทางการเงินเคยเป็นตัวจำกัดความเร็วในการพัฒนาและการทดลอง"

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

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

 
GN⁺ 2025-10-22
ความคิดเห็นบน Hacker News

  • พอเห็นภาพหน้าจอ htop ก็สังเกตได้เลยว่าไม่มี swap เลย เลยอยากแนะนำให้เปิด earlyoom เพื่อป้องกันไม่ให้ทั้งเซิร์ฟเวอร์ล่มตอนที่บริการกินหน่วยความจำผิดปกติ เพราะ OOM killer ของเคอร์เนล Linux มักทำงานช้าเกินไป นอกจากนี้ยังเปิด zram เพื่อบีบอัด RAM แล้วทำ overprovisioning แบบโปรได้ด้วย ซอฟต์แวร์ที่รันระยะยาวมักมี memory leak บ่อย และการบีบอัดช่วยได้ค่อนข้างมีประสิทธิภาพ ผมสรุปวิธีใช้กับเซิร์ฟเวอร์ bare metal ของ Hetzner ด้วย Ansible ไว้ใน gist แล้ว และมันก็ใช้กับ VM ได้เหมือนกัน

    • ไม่เห็นด้วยอย่างยิ่ง ถ้าแตะ swap เมื่อไร แอปส่วนใหญ่จะเริ่มมีปัญหาร้ายแรงทันที เรื่องนี้เป็นที่รู้กันดี และอินสแตนซ์ AWS EC2 ก็ปิด swap เป็นค่าเริ่มต้นเหมือนกัน แน่นอนว่า AWS เองก็อยากขาย RAM เพิ่ม แต่ swap ไม่เหมาะกับความคาดหวังของยุคนี้แล้ว ในยุค 90 เราอาจรอคลิกละ 2–3 วินาทีได้ แต่ตอนนี้ถ้าไม่ตอบสนองคนก็คิดว่ามันตายแล้วและรีบรีบูตทันที

    • อีกทางเลือกคือเพิ่มหน่วยความจำ แล้วปรับ oom_score แยกตามแอป โดยให้แอปที่ไม่สำคัญมีน้ำหนักในการโดน kill สูงขึ้น และแอปสำคัญมีค่าน้ำหนักติดลบ เช่น OpenSSH ตั้ง oom_score_adj เป็น -1000 อยู่แล้ว นอกจากนี้การปิด overcommit แทบทั้งหมดบนเซิร์ฟเวอร์ staging/production ก็มีประโยชน์มาก โดยคำนวณค่า min_free และ reserve ตามสูตรจากขนาด RAM เราใช้งานเซิร์ฟเวอร์จริงกว่า 50,000 เครื่องมานานเกิน 10 ปีโดยไม่มี swap และเห็นผลจริง OOM จะเกิดเฉพาะตอนคำนวณความต้องการหน่วยความจำผิดพลาดระหว่าง deploy โค้ดเท่านั้น หรือเวลาไม่ทำตามแนวปฏิบัติที่ดีของ Java ซึ่งเล่าได้ยาวอีกเรื่องหนึ่ง ยังมีวิธีใช้ cgroup จำกัดหน่วยความจำรายแอปด้วยแต่ขอข้ามไป ถ้าเป็นเซิร์ฟเวอร์ in-memory ล้วนที่ไม่ต้องเขียนดิสก์เลย ก็แนะนำให้ตั้งไม่ให้เกิด OOM ไปเลยแล้วให้ self-heal อัตโนมัติได้ด้วย การตั้งค่า panic reboot (kernel.panic, vm.panic_on_oom ฯลฯ) ก็มีประโยชน์ เพราะเปิดโอกาสให้ DRAC/iLO จับข้อความ crash ได้ทัน และในระบบ NFS diskless ก็ยังใช้เป็นตัวทริกเกอร์ให้ทั้งฟาร์มรีสตาร์ตเพื่อกู้ระบบได้โดยตั้งใจด้วย

    • ขอบคุณสำหรับข้อมูลดี ๆ ตอนนี้ผมควบคุมด้วย threshold ของ RAM จาก systemd อยู่ แต่อยากรู้ว่า earlyoom จะเป็นตัวเลือกที่ดีกว่าสำหรับป้องกันไม่ให้อินสแตนซ์ทั้งตัวไม่ตอบสนองเพราะโปรเซสทำงานเพี้ยนหรือเปล่า

    • ผมคิดว่าการมี swap ไว้น้อยมาก ๆ เผื่อฉุกเฉิน เช่น 1GB เป็นความคิดที่ดี

    • ผมไม่ได้ใช้ swap มาตั้งแต่ปี 2010 แล้ว

  • เมื่อวานเห็น Nate Berkopec เขียนเรื่องคล้ายกันเกี่ยวกับประสิทธิภาพของ rails โดยบอกว่า Heroku แพงกว่าตามประสิทธิภาพถึง 25–50 เท่า มันดูเหมือนไม่มีความตั้งใจจะแข่งด้านราคาเลยจริง ๆ และถ้าให้ไลเซนส์สแตกซอฟต์แวร์ทั้งหมดในราคาสมเหตุสมผลแบบ Sidekiq ได้ ถึงต้องแยกฮาร์ดแวร์เองก็น่าจะดีกว่ามาก 1GB RAM dyno ราคา $50 ในปี 2025 นี่แทบจะเรียกว่าปล้นกันชัด ๆ โดยเฉพาะเมื่อแอป rails มาตรฐานไม่ได้มี resource profile ใหญ่ขึ้นจากเดิม แถมยังมีประสิทธิภาพขึ้นด้วยซ้ำ แต่ราคากลับแพงขึ้นและคุณภาพลดลง มันน่าขำที่นักพัฒนาจำนวนมากยังรันแอปบน heroku ด้วยค่าใช้จ่ายหลายร้อยดอลลาร์ต่อเดือน ทั้งที่เครื่องจริงช้ากว่า MacBook สำหรับพัฒนาเสียอีก สุดท้ายก็ไม่ต่างจากแนวโน้มทั่วไปของโลกทุกวันนี้ คือแทนที่จะทำสินค้าดี ๆ ในราคาสมเหตุสมผลให้คนทั่วไปใช้ กลับเน้นแต่ลูกค้าระดับบนที่มีเงินที่สุดและขึ้นราคาอย่างเดียว

    • มันไม่ได้เป็นแค่ปัญหาเรื่องขึ้นราคา ผมคิดว่า Heroku กับผู้ให้บริการคลาวด์ได้ประโยชน์จากผลทางจิตวิทยาเรื่องจุดอ้างอิงราคา ตอนผู้ใช้เริ่มใช้บริการจะตั้ง anchor ไว้กับราคาตอนนั้น และหลังจากนั้นความคาดหวังก็เปลี่ยนแบบเชิงเส้น ทั้งที่ประสิทธิภาพฮาร์ดแวร์จริงดีขึ้นแบบทวีคูณ ราคา Heroku แทบไม่เปลี่ยนมาอย่างน้อย 7 ปี แต่ฮาร์ดแวร์ก้าวหน้าไปมาก ความรู้สึกว่ามันเป็นการหลอกลวงจริง ๆ จึงเกิดจากการเอาจุดอ้างอิงปี 2025 ไปเทียบกับราคาราวกลางทศวรรษ 2010 ผู้ให้บริการคลาวด์รายใหญ่จะสร้างอุปสรรคอย่างการล็อกประสิทธิภาพฮาร์ดแวร์ใหม่ไว้หรืออัปเดต SKU ส่วน Heroku ไม่มีแรงกดดันจากคู่แข่งแบบนั้นจึงตรึงราคาไว้ และบทความแบบนี้ก็มักจะโผล่มาทุกครั้งที่วิศวกรรุ่นใหม่เริ่มสัมผัสได้ว่าฮาร์ดแวร์สมัยนี้แรงขึ้นแค่ไหน

    • คุณบอกว่า 1GB RAM dyno ราคา $50 คือการปล้น แต่ AWS ก็ไม่ได้ต่างกันมาก $50/เดือน ได้ m7a.medium ที่มี 1vCPU กับ RAM 4GB แม้ RAM จะมากกว่า แต่ก็พอเข้าใจได้ว่า AWS หาเงินเข้ากระเป๋าได้ยังไง

    • ผมเห็นด้วยกับความเห็นที่ว่าอยากให้มีโมเดลไลเซนส์สแตกซอฟต์แวร์ครบชุดในราคาถูกแบบ Sidekiq เราเลยทำ canine.sh เป็นโอเพนซอร์ส เพราะคิดว่าไม่มีเหตุผลที่ผู้ให้บริการ PaaS จะต้องบวกมาร์จินสูงเกินไปซ้ำบนคลาวด์ที่มีมาร์จินอยู่แล้ว

    • ก็เหมือนกับการบอกว่าการเปลี่ยนน้ำมันเครื่องที่อู่แถวบ้าน หรือสเต๊กในร้านอาหาร แพงกว่าทำกินเองนั่นแหละ

  • คลาวด์ทำให้เราลืมไปว่าเซิร์ฟเวอร์เครื่องเดียวทำอะไรได้มากแค่ไหน แม้แต่สภาพแวดล้อม staging เองก็ยังดูไม่ค่อยสมเหตุสมผลที่จะเอาไปไว้บนคลาวด์แพง ๆ แต่ทุกวันนี้คลาวด์ก็มีความซับซ้อนจากหลายองค์ประกอบที่พัวพันกัน เลยพอเข้าใจได้ว่าทำไมถึงยังจำเป็น

    • การสอนพื้นฐานคลาวด์ให้กับนักพัฒนาหลายคน และมีผู้เชี่ยวชาญคลาวด์ไว้ไม่กี่คน ถือว่าคุ้มค่าในเชิงต้นทุนอยู่พักใหญ่ ถ้าทำให้ staging/prod คล้ายกันก็จะจับความผิดพลาดได้เร็วขึ้น สุดท้ายแล้ววันหนึ่งค่าใช้จ่ายคลาวด์จะมากกว่าค่าแรงคน และตอนนั้นการหนีออกจากคลาวด์จะคุ้มจริง ๆ ผมคิดว่าพอเปลี่ยนไปใช้เซิร์ฟเวอร์ของตัวเอง เมื่อไรทีมกับฮาร์ดแวร์รวมกันถูกกว่าคลาวด์ จุดนั้นจะมาถึงแน่นอน

    • รู้สึกว่าคลาวด์ทำให้นักพัฒนากลัว Linux server กันไปหมด มาร์จินส่วนใหญ่น่าจะเป็นค่าความกังวลของนักพัฒนา แต่การ self-host จริง ๆ แล้วทั้งง่ายและสนุก ผมไม่เคยรู้สึกว่าบริการอย่าง Heroku หรือ Vercel มีเสน่ห์อะไร และเชื่อว่าไม่มีประสบการณ์ไหนดีกว่าการลองตั้งเซิร์ฟเวอร์เองตั้งแต่ต้น ผมแนะนำให้นักพัฒนาทุกคนลองทำดู

    • การทำสำเนาสภาพแวดล้อม prod แบบเต็มให้ใกล้ของจริงช่วยได้มาก ขั้นตอน deploy ก็คล้ายกัน ประหยัดเวลา และทดสอบได้ใกล้เคียง prod จริงมากกว่า

    • เอาแนวคิดนี้ไปทำเป็นเว็บสอน infrastructure ก็น่าจะสนุกดี เช่น ให้ทรัพยากร X บนคลาวด์ แล้วต้องตั้งค่าให้รับโหลดที่กำหนดได้ พร้อมมีคะแนนประสิทธิภาพไว้แข่งกันระหว่างคนใช้

    • ราวปี 2006 เครื่องเล็กสุดของ AWS ยังมีขนาดประมาณเดสก์ท็อปสำหรับนักพัฒนาที่ถือว่าโอเค และต้องเช่าเกิน 2 ปีถึงจะคุ้มเท่าซื้อเครื่องเอง ทุกวันนี้เครื่องของ AWS อยู่ระดับมือถือหรือโน้ตบุ๊กราคาถูก และเช่าแค่ 3–6 เดือนก็คุ้มกว่าซื้อฮาร์ดแวร์เองแล้ว ถ้าไม่ได้ส่วนลด 75% การทำ on-premise จะประหยัดทั้งคนทั้งเงินมากกว่าคลาวด์

  • สวัสดีครับ ผมกำลังพัฒนาโอเพนซอร์ส PaaS ชื่อ Disco ร่วมกับเพื่อนชื่อ Antoine Leclair ช่วงนี้มีการพูดถึงเรื่อง self-hosting และการหนีออกจากคลาวด์กันเยอะมาก ถ้ามีคำถามอะไรก็ยินดีคุยเสมอ

    • ยิ่งน่าประทับใจขึ้นอีกถ้านึกถึงที่คุณบอกว่า "การใช้ทรัพยากรเซิร์ฟเวอร์ต่ำมาก" แล้วจำไว้ว่า load average ใน htop นับต่อ CPU core เช่นถ้ามี 8 คอร์ load average 0.1 ก็เท่ากับใช้ความจุ CPU รวมประมาณ 1.25% อ่านบล็อกแล้วสนุกมาก ผมเองก็ได้ประโยชน์จากแพตเทิร์นแบบนี้เยอะ

    • อยากรู้ว่าเมื่อเทียบกับเครื่องมืออย่าง Coolify แล้ว Disco มีอะไรที่โดดเด่นกว่าบ้าง ตอนนี้ผมโฮสต์บริการส่วนใหญ่บน Hetzner VPS อยู่แล้ว เลยอยากรู้จุดแข็งเฉพาะของ Disco

  • ที่ Hack Club เราก็มีประสบการณ์คล้ายกัน องค์กรไม่แสวงกำไรของเรามุ่งช่วยนักเรียนมัธยมให้เริ่มต้นกับการเขียนโค้ดและอิเล็กทรอนิกส์ แต่ก่อนเราใช้ Heroku แต่ไม่ใช่แค่เรื่องค่าใช้จ่าย ยังมีคำถามว่าแอปยูทิลิตีเล็ก ๆ นี้คุ้มกับค่าใช้จ่าย $15/เดือนจริงหรือเปล่า ปีนี้เราเปลี่ยนมา self-host ด้วย Coolify และรันบริการ 300 ตัวบนเซิร์ฟเวอร์ Hetzner ราคา $300/เดือนเพียงเครื่องเดียว ผลคือเราปล่อยโค้ดได้มากขึ้นมาก บทเรียนสำคัญที่สุดคือ ถ้าคุณต้องการ uptime แค่ 99% ไม่ใช่ 99.99% โลกของตัวเลือกจะกว้างขึ้นมาก เครื่องมือสำหรับนักพัฒนาส่วนใหญ่มักหมกมุ่นกับ 99.99% แต่ถ้า 99% ก็พอ คุณสามารถทำงานได้อย่างมีประสิทธิภาพมาก ผมสนใจ Disco ขึ้นมาเลยและตั้งใจว่าจะลองแน่นอน

    • ขอบคุณมาก ถ้ามีอะไรสงสัยเกี่ยวกับบริการของ Disco ก็มาถามใน Discord ได้เสมอ เรามีกรณีคล้ายกันอยู่สองกรณี คือบูตแคมป์/โรงเรียนสอนพัฒนาในเปอร์โตริโกที่ให้ deploy โปรเจ็กต์จบของนักเรียนทั้งหมดลงบน VPS เครื่องเดียว และที่ Recurse Center ก็กำลังโฮสต์เว็บโปรเจ็กต์ 75 ตัวบน Raspberry Pi เครื่องเดียว (ลิงก์)

    • และถ้าต้องการ 99.99% จริง ๆ ผมคิดว่าควรหลีกเลี่ยง hyperscaler อยู่ดี ตัวอย่างคือเหตุขัดข้องของ AWS หลายชั่วโมงเมื่อไม่นานมานี้

    • 300 บริการเลยเหรอ อยากรู้ว่าบริการแต่ละตัวทำหน้าที่อะไรบ้าง

  • จากสถานการณ์ตอนนี้ ผมเห็นว่า self-hosting เป็นทางออกที่น่าสนใจมาก แต่ก็มีสิ่งหนึ่งที่อยากพูดถึงตัวบทความเอง คือบทความนี้ให้ความรู้สึกเหมือนถูก AI ช่วยเรียบเรียงหนักมาก และในส่วน "Bridging the Gap: Why Not Just Docker Compose?" ก็เหมือนคัดลอกคำต่อคำมาจากหัวข้อ "Powerful simplicity" บนหน้า landing page ของผลิตภัณฑ์ Disco ด้วย บล็อกโพสต์นี้ยังเป็นกรณีศึกษาเพียงชิ้นเดียวที่แสดงอยู่บนหน้าแรกของพวกเขาอีกต่างหาก

    • ถูกต้องทุกประการ ผมอยากยกเหตุผลสามข้อขึ้นมาแต่คงไม่ทำหรอกนะ (ล้อเล่น) ไลบรารีของเราเป็นโอเพนซอร์ส และเราภูมิใจที่ Idealist ประหยัดค่าใช้จ่ายได้ ถ้าการภูมิใจถือเป็นการโปรโมต งั้นผมก็ภูมิใจเต็มที่เลย

    • คุณบอกว่าบทความการตลาดเป็นปัญหา แต่อยากรู้ว่าทำไมถึงมองว่าเป็นปัญหา มันผิดกฎของ Hacker News หรือคุณคิดว่าการตลาดทุกอย่างต้องติดป้ายบอก เพราะในโลกนี้แทบไม่มีอะไรที่ไม่ใช่การตลาดเลย

    • การเขียนบล็อกโพสต์เชิงการตลาดเกี่ยวกับการแข่งขันด้านราคา แต่กลับไม่เปิดเผยราคาบนหน้าเว็บตัวเอง และให้แค่จองประชุมเท่านั้น สำหรับผมแล้วนี่คือ red flag ใหญ่ที่สุดในเรื่องราคา

    • ผมเองก็รีบไปหาว่าโมเดลรายได้เป็นยังไงทันที แต่สุดท้ายก็ได้แค่ความรู้สึกว่าน่าจะเปิดเผยเร็ว ๆ นี้

    • นี่ไม่ใช่ครั้งแรกที่มีบทความที่มีองค์ประกอบทางการตลาดเข้ามาปน และผมก็สงสัยว่าอะไรคือปัญหาของการตลาดผ่านบทความกรณีศึกษา แบบนี้ถือว่าค่อนข้างเบาด้วยซ้ำ ถึงจะเป็นการตลาดแต่ก็ยังอ่านแล้วน่าสนใจและมีประโยชน์

  • ราคา Heroku นี่บ้าจริง ๆ ราวสิบปีก่อนตอนผมอยู่สตาร์ตอัปแห่งหนึ่ง ผมตกใจมากที่เห็นพวกเขาจ่ายเกิน $10,000 ต่อเดือน เพียงเพื่อรันบริการที่สร้าง QR code เป็น HTML table แล้วแสดงในอีเมล ตกเฉลี่ยอันละ $0.15 หัวหน้าทีมพัฒนายังไม่เคยทำ code profiling มาก่อนด้วยซ้ำ เลยลดลงได้ถึง $0.01 ต่อชิ้น แต่ถึงอย่างนั้นก็ยังน่าเหลือเชื่ออยู่ดี

    • ผมไม่เข้าใจจริง ๆ ว่าทำไมการสร้าง QR code หนึ่งอันถึงต้องเสียเงินขนาดนั้น ทั้งที่ใช้ edge cloud hosting ก็น่าจะทำได้ฟรีด้วยซ้ำ

  • ผมไม่ค่อยเข้าใจว่าทำไมต้องมี staging server ถึง 6 เครื่อง (เครื่องละ $500) ถ้าเป็นเพราะทีมใหญ่จริง ค่าเซิร์ฟเวอร์ $3,000 ก็ดูเล็กน้อยเมื่อเทียบกับค่าแรงรวมเกิน $100,000 ต่อปีไม่ใช่เหรอ? ผมลองดู idealist.org แล้ว มันก็แค่ job board เอง เลยรู้สึกว่าเยอะเกินไป

    • staging server ทั้ง 6 เครื่องมีไว้สำหรับ main, dev และอีกหลาย branch เพื่อให้ QA ที่ไม่ใช่นักพัฒนาสามารถเข้าไปตรวจได้โดยตรง ทุกครั้งที่ทำ staging deploy ก็จะมี Performance-M dyno, Standard dyno หลายตัว, RabbitMQ, ฐานข้อมูล และอื่น ๆ รวมกันจนค่าใช้จ่ายโตเร็วมาก บริการของ Idealist มีผู้ใช้วันละ 100,000 คน จึงมีเทคโนโลยีจำนวนมากอยู่เบื้องหลังเรื่องความน่าเชื่อถือและความเร็ว

    • อ่านดูแล้วเหมือนว่าพวกเขาทำ staging server หลายตัวเพื่อใช้เป็น dev environment ที่ให้นักพัฒนาแต่ละคนรันหลายบริการพร้อมกันได้ เลยต้องมีหลายเครื่อง

    • หลายคนมักมองข้ามการคิดต้นทุนคนทำงานจริง ๆ (man-day) ตอนประเมินค่าใช้จ่าย

  • ผมอยากเลิกใช้ Heroku แต่ยังอยากได้ตัวเลือกที่แทบไม่ต้องดูแลระบบเอง แค่ deploy เว็บ Django กับ dump ฐานข้อมูลไว้บ้าง มีอะไรที่เหมาะที่สุดไหม

    • Render.com น่าจะใกล้เคียงที่สุดและผมก็พอใจกับมันมาก workflow แทบเหมือน Heroku แต่ถูกกว่า และก็โอเคมากทั้งเรื่องการรีสตาร์ตตอนกลางคืนกับการรองรับ Python เวอร์ชันใหม่ล่าสุด

    • แนะนำให้ลองเรียน Docker Swarm ด้วย การ deploy คือแค่ push คอนเทนเนอร์ครั้งเดียวแล้วสั่งคำสั่งเดียว ผมยังทำเครื่องมือ CLI ฟรีชื่อ rove.dev เองด้วย ใช้ดู diff ทั้งของ deployment และ service หรือจะมอง PaaS แบบ VM ก็ได้ อย่าง Semaphore, Dokku, Dokploy

    • เลือก VPS ที่คุณต้องการตามราคา/ประสิทธิภาพ/ตำแหน่งที่ตั้ง/การซัพพอร์ต แล้วค่อยใส่เครื่องมือ deploy ที่ชอบอย่าง Coolify หรือ Dokploy เข้าไป ผมเพิ่งย้าย Django/Postgres จาก Google App Engine ไปบน Coolify + Mythic Beasts ได้ง่ายมาก ถึงจะไม่ได้จับงานพวกนี้นานจนฝีมือขึ้นสนิมแล้วก็ยังย้ายได้สบาย

    • ผมคิดว่าแค่มีเซิร์ฟเวอร์บน hetzner สักเครื่อง แล้วตั้ง nginx กับ service ของ systemctl ก็น่าจะพอแล้ว

    • PythonAnywhere(ลิงก์) ก็โอเคนะ

  • โปรเจ็กต์เจ๋งมาก ผมดูเอกสารแล้วเหมือน GitHub integration จะเป็นข้อบังคับของ Disco ใช่ไหม แล้วสามารถ deploy Docker image ที่มีอยู่แล้วใน registry ของผมได้ตรง ๆ โดยไม่ต้องมีขั้นตอน build แยกต่างหากไหม คล้ายกับ --skip-push --version latest ของ Kamal

    • ใช่ครับ ตอนนี้ยังต้องใช้ GitHub integration อยู่ แต่ Disco ก็สามารถดึง Docker image ที่มีอยู่แล้วมา deploy ได้โดยตรงเหมือนกัน (เรา self-host RabbitMQ แบบนี้อยู่) ตัวอย่างการ deploy image ของ Meilisearch ดูได้ที่ ตรงนี้ และ tutorial นี้ ปกติคุณใช้วิธี build แล้ว push เข้า registry อยู่หรือเปล่า อยากฟังกระบวนการ deploy ของคุณแบบละเอียดกว่านี้ด้วย