อย่าเช่าคลาวด์ แต่จงเป็นเจ้าของมันเอง

 (blog.comma.ai)
11 คะแนน โดย GN⁺ 2026-02-06 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • CommaAI ทำการฝึกโมเดลและประมวลผลข้อมูลทั้งหมดในดาต้าเซ็นเตอร์ของตนเอง และกำลังดูแลโครงสร้างพื้นฐานมูลค่าประมาณ 5 ล้านดอลลาร์ ด้วยตัวเอง
  • การพึ่งพาคลาวด์อาจนำไปสู่ ต้นทุนที่สูงขึ้นและการสูญเสียการควบคุม ขณะที่การบริหารคอมพิวต์เองทำให้ คุณภาพงานวิศวกรรมดีขึ้น และ ลดต้นทุน ได้
  • ดาต้าเซ็นเตอร์ประกอบด้วยกำลังไฟประมาณ 450kW, GPU 600 ตัว, สตอเรจ SSD 4PB, และมี โครงสร้างการระบายความร้อนกับเครือข่ายที่เรียบง่าย
  • ซอฟต์แวร์สแต็กถูกออกแบบด้วย Ubuntu + Salt, สตอเรจ minikeyvalue(mkv), ตัวจัดตารางงาน Slurm, PyTorch distributed training, และคอมพิวต์แบบกระจาย miniray
  • comma.ai ใช้สถาปัตยกรรมนี้เพื่อ ทำให้การฝึกโมเดลขับขี่อัตโนมัติเป็นอัตโนมัติทั้งหมด และลดต้นทุนได้ประมาณ 5 เท่าเมื่อเทียบกับคลาวด์

เหตุผลที่บริหารดาต้าเซ็นเตอร์เอง

  • หากพึ่งพาคลาวด์ จะเกิด ต้นทุนที่เพิ่มขึ้นและการผูกติดกับผู้ให้บริการ
    • บริษัทคลาวด์ออกแบบให้เริ่มใช้งานได้ง่าย แต่ย้ายออกได้ยาก
    • เมื่อใช้งานต่อเนื่องก็มีแนวโน้มจะติดอยู่กับโครงสร้างต้นทุนที่สูง
  • การบริหารคอมพิวต์เองช่วยส่งเสริม ความพึ่งพาตนเองทางเทคนิคและวัฒนธรรมวิศวกรรมที่มีประสิทธิภาพ
    • คลาวด์ต้องบริหารผ่าน API และระบบชำระเงินเป็นหลัก แต่ดาต้าเซ็นเตอร์ต้องแก้ปัญหาทางเทคนิคจริงที่เน้น พลังงาน การประมวลผล และแบนด์วิดท์
  • ในมุมของวิศวกรรม ML ด้วยเช่นกัน ข้อจำกัดของทรัพยากรจะผลักดันให้เกิดการปรับโค้ดให้เหมาะสมและการปรับปรุงที่ระดับรากฐาน
    • บนคลาวด์มักแก้ปัญหาด้วยการเพิ่มงบประมาณ แต่บนโครงสร้างพื้นฐานของตนเองนั้น การเพิ่มประสิทธิภาพเป็นสิ่งจำเป็น
  • ในด้านต้นทุน comma.ai ลงทุนประมาณ 5 ล้านดอลลาร์ และประเมินว่าหากทำงานเดียวกันบนคลาวด์จะต้องใช้เงิน มากกว่า 25 ล้านดอลลาร์

องค์ประกอบของดาต้าเซ็นเตอร์

  • พลังงานไฟฟ้า

    • ใช้ไฟสูงสุด 450kW และค่าไฟในปี 2025 อยู่ที่ 540,112 ดอลลาร์
    • ค่าไฟในซานดิเอโกอยู่ที่ 40 เซนต์/kWh ซึ่งสูงกว่าค่าเฉลี่ยโลกประมาณ 3 เท่า
    • มีการกล่าวถึงแผน ผลิตไฟฟ้าใช้เองในอนาคต

  • การระบายความร้อน

    • ใช้ ระบบระบายความร้อนด้วยอากาศภายนอก ซึ่งประหยัดไฟกว่าระบบ CRAC
      • ใช้ พัดลมดูดอากาศเข้าและระบายอากาศออกขนาด 48 นิ้ว อย่างละ 2 ตัวเพื่อหมุนเวียนอากาศ
      • ใช้ PID control loop ปรับอุณหภูมิและความชื้นอัตโนมัติ (รักษาไว้ที่ <45%)
      • การใช้พลังงานอยู่ในระดับหลายสิบ kW

  • เซิร์ฟเวอร์และสตอเรจ

    • ประกอบด้วย TinyBox Pro จำนวน 75 เครื่อง (รวม 600 GPU) ซึ่งผลิตขึ้นเอง
      • อุปกรณ์แต่ละเครื่องมี 2 CPU + 8 GPU ใช้สำหรับการฝึกและการประมวลผลทั่วไป
      • การผลิตเองทำให้ บำรุงรักษาได้ง่าย
    • สตอเรจใช้ฐาน Dell R630/R730 รวมทั้งหมด 4PB SSD
      • เป็นโครงสร้าง ไม่ทำซ้ำข้อมูล (non-redundant) และมี ความเร็วอ่าน 20Gbps ต่อโหนด
    • เครือข่ายประกอบด้วย สวิตช์ Z9264F 100Gbps จำนวน 3 ตัว และ สวิตช์ Infiniband 2 ตัว

โครงสร้างพื้นฐานซอฟต์แวร์

  • การตั้งค่าพื้นฐาน

    • เซิร์ฟเวอร์ทั้งหมดใช้ Ubuntu + PXE boot และบริหารด้วย Salt
    • ใช้โครงสร้างมาสเตอร์เดี่ยวและรักษา อัตราการพร้อมใช้งาน 99%

  • สตอเรจแบบกระจาย — minikeyvalue (mkv)

    • เก็บข้อมูลการขับขี่สำหรับการฝึกไว้บน สตอเรจแบบไม่ซ้ำข้อมูล 3PB
      • มี ความเร็วอ่าน 1TB/s และสามารถฝึกจากข้อมูลโดยตรงได้โดยไม่ต้องแคช
    • มี อาร์เรย์ 300TB สำหรับแคช และ อาร์เรย์เก็บข้อมูลแบบซ้ำ สำหรับโมเดลและเมตริก
    • แต่ละอาร์เรย์ถูกบริหารด้วย เซิร์ฟเวอร์มาสเตอร์เดี่ยว

  • การจัดการงาน — Slurm

    • ใช้จัดตารางงานสำหรับ งานฝึก PyTorch และ งานกระจายแบบ miniray

  • การฝึกแบบกระจาย — PyTorch + FSDP

    • มีพาร์ทิชันสำหรับการฝึก 2 ชุดที่เชื่อมต่อกันด้วย เครือข่าย Infiniband
    • ใช้เฟรมเวิร์กการฝึกที่พัฒนาขึ้นเองเพื่อ ทำให้ training loop เป็นอัตโนมัติ
    • มี บริการติดตามการทดลองโมเดล

  • คอมพิวต์แบบกระจาย — miniray

    • เป็น task scheduler แบบโอเพนซอร์สน้ำหนักเบา ที่รัน โค้ด Python บนเครื่องที่ว่างอยู่
      • ง่ายกว่า Dask และใช้ เซิร์ฟเวอร์กลาง Redis สำหรับจัดการงาน
      • worker ที่เป็น GPU จะทำ inference ของโมเดลผ่าน Triton Inference Server
    • สามารถขยายแบบขนานได้ถึง หลายร้อยเครื่อง
      • ตัวอย่าง: สถิติ Controls Challenge ทำได้ด้วยการใช้ดาต้าเซ็นเตอร์เพียง 1 ชั่วโมง

  • การจัดการโค้ด — โมโนรีโปบนพื้นฐาน NFS

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

ไปป์ไลน์การฝึกแบบบูรณาการ

  • งานที่ซับซ้อนที่สุดของ comma คือการ ฝึกโมเดลการขับขี่ด้วยวิธี on-policy
  • สำหรับการฝึกแบบนี้ จำเป็นต้องรันการขับขี่จำลองโดยใช้ น้ำหนักโมเดลล่าสุด เพื่อ สร้างข้อมูลสำหรับการฝึก
  • สามารถรันไปป์ไลน์ทั้งหมดได้ด้วยคำสั่งเดียวด้านล่าง
    • ./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
  • การรันการฝึกข้างต้นใช้โครงสร้างพื้นฐานทั้งหมดที่อธิบายไว้ก่อนหน้า
  • แม้จะเป็นเพียงคำสั่งสั้น ๆ คำสั่งเดียว แต่ทำหน้าที่ประสานองค์ประกอบจำนวนมากเข้าด้วยกัน

บทสรุป

  • comma.ai บรรลุทั้ง การลดต้นทุนและความพึ่งพาตนเองทางเทคนิค ด้วยการบริหารดาต้าเซ็นเตอร์เอง
  • ด้วยแนวทางเดียวกันนี้ ทั้งองค์กรและบุคคลก็อาจสร้างโครงสร้างพื้นฐานของตนเองได้

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

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

 
kaydash 2026-02-06

หน่วยความจำแพงนี่นา!
 
harryhan2435 2026-02-12

555555555555555555
 
GN⁺ 2026-02-06
ความคิดเห็นจาก Hacker News

  • ในอุตสาหกรรมที่เราอยู่ การเป็นเจ้าของ vs คลาวด์ อยู่คนละสุดของสเปกตรัม
    ① คลาวด์มีภาระด้านเงินลงทุนเริ่มต้น (capex) และบุคลากรต่ำ แต่ ค่าใช้จ่ายในการดำเนินงาน (opex) สูงและผันผวนมาก
    ② Managed Private Cloud คือสิ่งที่เราทำ โดยดูแลให้บนพื้นฐานโอเพนซอร์ส และถูกกว่า AWS ราว 50%
    ③ Rented Bare Metal เป็นโมเดลที่ช่วยรับภาระการจัดหาเงินทุนสำหรับฮาร์ดแวร์ ทำให้ถูกกว่า AWS 90%
    ④ การซื้อเองแล้วทำ colocation จะถูกที่สุดถ้ามีความสามารถทางเทคนิคและมีขนาดถึงระดับหนึ่ง
    ผู้ให้บริการอย่าง Hetzner ดำเนินงานโดยยึด ROI 3 ปีเป็นเกณฑ์ และตัวเลือก 3~4 เหมาะกับบริษัทที่มีขนาดใหญ่หรือมีอินฟราเป็นหัวใจหลัก
    สำหรับสตาร์ตอัป ตัวเลือก 1 เป็นจริงได้มากกว่า และสำหรับธุรกิจขนาดกลางถึงเล็ก ตัวเลือก 2 สมเหตุสมผลกว่า (lithus.eu)

    • ปัญหาคือโครงสร้างต้นทุนของคลาวด์ไม่ได้เกิดจากราคาฮาร์ดแวร์อย่างเดียว แต่เกิดจากการชักนำให้ใช้ สถาปัตยกรรมที่ซับซ้อน จนเกิดความไร้ประสิทธิภาพมากขึ้น
      ‘managed services’ ของ AWS มีโครงสร้างที่ยิ่งผู้ใช้ทำให้เซิร์ฟเวอร์มีประสิทธิภาพมากขึ้น รายได้ของ AWS ก็ยิ่งลดลง
      ถ้าเป็นแค่การวาง Java server 4 ตัวบน EC2 กับฐานข้อมูลแบบทำซ้ำ ก็มีประสิทธิภาพกว่ามากแล้ว
      สุดท้ายแล้ว ค่า AWS ที่แพงเกินจริงมักเกิดขึ้นเมื่อมีการใช้บริการจำนวนมากเกินจำเป็น

    • (derek@ จาก Carolina Cloud) พวกเราก็ชอบโมเดลแบบ (4) เหมือนกัน แต่ผู้ใช้ที่ขาดทักษะทางเทคนิคมักต้องอยู่กับตัวเลือก 1~3 และ ติดอยู่ในโครงสร้างต้นทุนสูงของ public cloud
      แม้จะบอกว่า ‘จ่ายตามการใช้งาน’ แต่จริง ๆ แล้วมี ค่าพื้นฐานและค่าขั้นต่ำ ติดมาด้วย ทำให้แพงกว่ามาก (carolinacloud.io)

    • Hetzner เป็นตัวเลือกที่น่าสนใจ
      แม้จะมีภาระที่ต้องดูแลบริการอย่าง Postgres หรือ VPN เอง แต่ถ้างบเกิน 10,000~15,000 ดอลลาร์ต่อเดือน ก็ได้เปรียบกว่า AWS
      มีความเสี่ยงอยู่บ้าง แต่ก็คุ้มค่าที่จะรับไว้

    • ฉันเช่า bare-metal server เดือนละ 500 ดอลลาร์ และใช้เวลาบริหารจัดการเพียงไม่กี่ชั่วโมงต่อปี
      อาจเป็นเพราะความต้องการของฉันเรียบง่าย แต่ก็ยังรู้สึกว่าดีกว่าคลาวด์ที่ซับซ้อนเกินจำเป็นมาก

    • ฉันย้ายไปใช้ colocation ตั้งแต่ 2 ปีก่อน และตอนนี้ได้ ความจุมากขึ้นในต้นทุนเพียง 30%
      ยังได้ประโยชน์จากการที่ราคา RAM/สตอเรจลดลงตามเวลา
      เพียงแต่ต้องใส่ใจเรื่อง compliance management มากขึ้นเล็กน้อย

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

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

    • ถ้าอย่างนั้นทำไมถึงยังไม่มี ทางเลือกคลาวด์ที่แข่งขันด้านราคาได้?
      AWS และ Azure ครองตลาดจนไม่มีแรงจูงใจให้ลดราคา ส่วน Google ก็มีความเสี่ยงเรื่องการปิดบริการสูง

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

    • ดาต้าเซ็นเตอร์แบบ on-prem มี ภาระด้านปฏิบัติการ สูง และกินทรัพยากรวิศวกรรมมาก
      เพราะแบบนี้การถกเถียงนี้จึงวนกลับมาอยู่เรื่อย ๆ

    • นวัตกรรมที่แท้จริงของคลาวด์คือ “ทำให้ต้นทุนในระดับบริการชัดเจน”
      จากเดิมที่ต้องถามว่า “ต้องไปขอใครนะ?” ก็กลายเป็นเข้าถึงได้ผ่าน API
      บริบทที่เกี่ยวข้องสรุปไว้ดีใน บทความนี้

  • แม้แต่ในพื้นที่ที่ควบคุมอุณหภูมิได้ง่ายอย่างซานดิเอโก การใช้ การระบายความร้อนด้วยอากาศภายนอก ก็ยังมีความเสี่ยง
    ความชื้นและมลพิษทำให้เซิร์ฟเวอร์เสียเร็วขึ้น
    ทางเลือกอย่าง enthalpy wheel cooler (kyotocooling) มีประสิทธิภาพกว่า และใช้ไฟน้อยเมื่อเทียบกับประสิทธิภาพการระบายความร้อน
    การระบายความร้อนด้วยอากาศภายนอกมีความเสี่ยงสูงที่จะทำให้อายุอุปกรณ์สั้นลง จึงต้องระวัง

    • ก็มีกรณีที่ได้ผลค่อนข้างดีเช่นกัน ถ้ามีการกรองอากาศและคงความชื้นไว้ต่ำกว่า 45%

    • ไม่เคยรู้เลยว่าต้องใส่ใจเรื่องพวกนี้ด้วย
      เพราะแบบนี้ฉันเลยใช้ คลาวด์ ไปเลย — มันช่วยเลี่ยง ‘ความเสี่ยงที่เราไม่รู้ว่ามีอยู่’

  • การใช้ออนพรีเมสและคลาวด์ ควบคู่กัน คือทางเลือกที่เป็นจริงที่สุด
    อินฟราหลักมอบให้คลาวด์ที่เชื่อถือได้ ส่วนงานอย่าง Slurm jobs ก็รันบนเซิร์ฟเวอร์ของตัวเอง
    colocation ก็ยังเป็นตัวเลือกที่ใช้ได้อยู่ และ HPC สำหรับงานวิจัยก็น่าพิจารณาเช่นกัน
    ในนอร์เวย์ แม้แต่บริษัทเอกชนก็สามารถใช้ HPC สำหรับงานวิจัยแบบมีค่าใช้จ่ายได้

    • ฉันเคยดูแล server farm สองแห่งในอิตาลี โดยมีพนักงาน 5 คน และรักษา uptime ได้เกือบ 100%
      ใช้งบปีละ 800,000 ยูโร แต่ประหยัดค่าใช้จ่ายคลาวด์ได้ 7~8 ล้านยูโร

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

    • ถ้าเช่าพื้นที่กับบริษัทอย่าง Equinix หรือ Global Switch พวกเขาจะดูแลเรื่องไฟฟ้า การระบายความร้อน สายเคเบิล ฯลฯ ให้ทั้งหมด
      การมีห้องเซิร์ฟเวอร์เองสองแห่งก็เป็นสิ่งที่ทำได้จริงมากพอสมควร

    • เรายังคงใช้ Azure สำหรับบริการฝั่งผู้ใช้อยู่
      เว็บเซอร์วิสที่ไม่ต้องใช้ GPU คลาวด์มีประสิทธิภาพมากกว่า
      และ GitHub ก็ยังใช้งานเป็นบริการที่เชื่อถือได้อยู่

    • (พูดติดตลก) เคยมีครั้งหนึ่งที่ Postgres daemon ไปพันกับ Slurm pool แล้วทำให้ Rust ทำงานหลุดควบคุม
      สุดท้ายก็ทำให้เสถียรได้ แต่ในมุมของวิศวกรฮาร์ดแวร์ โลกของซอฟต์แวร์มันชวนสับสนมาก

  • ช่วงเริ่มต้นโปรเจกต์ ควรเริ่มจาก AWS เดือนละ 250 ดอลลาร์ และเมื่อไปถึงระดับ 30,000 ดอลลาร์ต่อเดือน ค่อยย้ายไป colocation
    หัวใจสำคัญคือ ความสามารถในการคำนวณต้นทุน — วิศวกรที่ดีควรใช้สิ่งนี้เป็นหลักฐานเพื่อเสนอผู้บริหารได้

    • นอกเหนือจากการคำนวณแบบตรงไปตรงมา ยังต้องคิดด้วยว่าจะดึงดูด คนแบบไหน และอยากสร้างธุรกิจแบบไหน
      ถ้าเป็นบริษัทที่ฝึกโมเดล ML อินฟราของตัวเองอาจเหมาะกว่า

    • แต่ในบริษัทส่วนใหญ่ วิศวกรแทบไม่มีส่วนร่วมในการเลือกแพลตฟอร์ม
      99.999999% ของกรณีคือผู้บริหารตัดสินใจไว้แล้วและแค่แจ้งลงมา

  • ตอนเริ่มทำงานใหม่ ๆ คลาวด์เป็นตัวเลือกที่แน่นอน แต่ตอนนี้ on-prem กลับมาเป็นกระแสอีกครั้ง
    อีก 10 ปีข้างหน้า กระแสอาจกลับไปอีกทางก็ได้

    • จากประสบการณ์ของฉัน ทีมที่ผลักดัน on-prem มัก ประเมินความเหนื่อยล้าจากการบำรุงรักษาต่ำเกินไป เสมอ
      ในที่แบบสตาร์ตอัปที่ต้องพัฒนาให้เร็ว มันกลับกลายเป็นตัวถ่วง
      ในทางกลับกัน บริษัทที่เข้าสู่โหมดดูแลรักษาระบบแล้ว on-prem กลับมีประสิทธิภาพ
      ยิ่งอายุมากขึ้น “ทำให้เสร็จเร็วและอยู่ในงบ” จะยิ่งสำคัญขึ้น และเสน่ห์ของการดูแลอินฟราเองก็ลดลง

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

    • วงจรแบบนี้มีอยู่เสมอ
      จากเมนเฟรม → PC → ห้องเซิร์ฟเวอร์ → คลาวด์ → edge computing เป็น การสลับไปมาระหว่างการรวมศูนย์ ↔ การกระจายศูนย์
      สุดท้ายเมื่อเทคโนโลยีและลำดับความสำคัญเปลี่ยน มันก็ย้อนกลับมาอีก
      ถ้าวันหนึ่งประโยค “เครือข่ายก็คือคอมพิวเตอร์” กลับมาอีกครั้ง ก็แปลว่าครบรอบอีกหนึ่งวงแล้ว

    • (มุกตลก) ลำดับถัดไปอาจเป็นขั้นของ อวกาศ (Skynet) ก็ได้

  • เหตุผลที่บริษัทส่วนใหญ่หลีกเลี่ยง on-prem คือ การบริหารความเสี่ยง
    บริษัทที่ดีจะโฟกัสความเสี่ยงไปที่ความสามารถในการแข่งขันหลักของตัวเอง
    จึงไม่ควรตัดสินแค่เรื่องต้นทุน แต่ต้องมองเป็น ต้นทุนที่ปรับตามความเสี่ยง

    • แต่ทุกวันนี้ก็ยังน่าสงสัยว่าบริษัทต่าง ๆ มีความสามารถ ประเมินความเสี่ยงนั้นได้อย่างแม่นยำจริงหรือไม่
      เพราะความสามารถในการแข่งขันด้านราคาก็เป็นหนึ่งในปัจจัยสร้างความแตกต่างเช่นกัน

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

    • สุดท้ายแล้ว โดยมากมันคือ ศึกที่ Opex ชนะ Capex

  • ข้อดีที่แท้จริงของ on-prem คือ อิสรภาพ การควบคุม และความเป็นส่วนตัว
    มันไม่ใช่แค่เรื่องเงิน แต่เหมือนกับคำถามว่าจะเป็นเจ้าของบ้านหรือเช่าบ้าน

    • แต่ในบทความต้นฉบับเอง เรื่องต้นทุนก็ถูกพูดถึงเป็นข้อสุดท้าย และข้อดีอื่นต่างหากที่เป็นแกนหลัก

  • หลักคิดแบบ MBA ในยุค 2010s คือ “ย้ายทุกอย่างขึ้นคลาวด์”
    การโยนความเสี่ยงและต้นทุนไปให้บุคคลที่สามถูกมองว่าเป็นคำตอบที่ถูกต้อง
    แต่ในความเป็นจริง ดาต้าเซ็นเตอร์ของเราถูกกว่ามาก และ อัตราการขึ้นราคาของค่าสมัครใช้ซอฟต์แวร์ ก็สูงกว่าฮาร์ดแวร์มาก

    • แน่นอนว่า AWS มี ดาต้าเซ็นเตอร์แบบซ้ำซ้อน อยู่ทั่วโลก ทำให้ระดับความเสถียรต่างกัน
      แต่เมื่อคำนึงถึงต้นทุนแรงงานและค่าบริหารจัดการแล้ว การเทียบกันแบบดูเฉพาะต้นทุนตรง ๆ ก็ไม่มีความหมาย
      เพราะพายุทอร์นาโดครั้งเดียวก็อาจทำให้บริษัทพังได้ สุดท้ายจึงต้องตัดสินจาก คุณค่าที่เทียบกับความเสี่ยง