เรื่องสยองของ Serverless

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

---

รวมกรณีการเรียกเก็บเงินเกินจริงของบริการ Serverless และ SaaS

#1 การถูกเรียกเก็บเงินจำนวนสูงใน Webflow

• ระหว่างใช้งานแพ็กเกจเดือนละ 69 ดอลลาร์ กลับถูกเรียกเก็บเงิน $1,189.42 สำหรับค่าใช้จ่ายรายเดือนโดยไม่มีเหตุผลชัดเจน

#2 กรณี DoS โจมตีเว็บเกม WebGL

• ผู้ดูแลเว็บไซต์อัปโหลดเกม WebGL ขนาดกลางรายหนึ่ง ถูกเรียกเก็บเงินจาก Google Firebase มากกว่า $100,000 ภายในวันเดียว หลังเกิด การโจมตีแบบ DoS

#3 Vercel Pro และการเกินวงเงินใช้จ่าย

• ใช้แพ็กเกจ Vercel Pro ในราคา $20 ต่อเดือน และตั้งวงเงินใช้จ่ายไว้ที่ $120 แต่ก็ยังมีค่าใช้จ่ายเพิ่มเติมแบบไม่คาดคิด

#4 การคิดค่าบริการของโปรเจ็กต์และบิลมูลค่าสูงมาก

• มีกรณีที่โปรเจ็กต์ซึ่งจ่ายเพียง $50 ต่อเดือน วันหนึ่งกลับได้รับบิลเรียกเก็บเงินสูงถึง $70,000 ในตอนเช้า

#5 ปัญหาค่าบริการจากการใช้ BigQuery และ public dataset

• ระหว่างใช้ BigQuery ในสภาพแวดล้อม Playground กลับถูกเรียกเก็บเงินจำนวนมหาศาลเกิน $22,000

#6 ค่าบริการโฮสติ้งสูงเกินไปเมื่อเทียบกับจำนวนผู้เยี่ยมชมที่น้อย

• แม้มีผู้เข้าชมเพียง 9,000 คน ต่อเดือน ก็ยังถูกเรียกเก็บเงิน $250 ต่อเดือน ซึ่งเท่ากับต้องจ่าย $3,000 ต่อปี

#7 ปัญหาที่เกิดขึ้นหลัง Devin(AI) เปลี่ยนแปลง codebase

• พบผลลัพธ์ที่ไม่คาดคิดเมื่อ AI ชื่อ Devin ดำเนินการแก้ไขโค้ด

#8 ถูกเรียกเก็บเงินกะทันหันหลังใช้งานฟรี

• ทั้งที่ไม่เคยชำระเงินมาก่อน วันหนึ่งกลับมีการเรียกเก็บเงิน $530 แบบกะทันหัน

#9 ค่าบริการของเว็บไซต์เอกสารและโปรเจ็กต์ขนาดเล็กอื่น ๆ

• แม้แต่ เว็บไซต์เอกสาร แบบเรียบง่ายก็ยังถูกเรียกเก็บเกือบ $400 แสดงให้เห็นว่าบริการที่ใช้งานน้อยก็มีกรณีบิลสูงจำนวนมาก

#10 ความสยองของ free tier

• แม้แต่บิลราว $103 ก็ถูกมองว่าเป็นปัญหา โดยเฉพาะความกังวลเรื่องการได้รับใบแจ้งหนี้แบบไม่คาดคิดระหว่างใช้งาน free tier

#11 Cloudflare, AWS และประเด็นอื่น ๆ

• มีกรณีที่ Cloudflare แจ้งให้ชำระ $120,000 ภายใน 24 ชั่วโมง พร้อมระงับบริการ
• ใน AWS S3 ก็มีการคิดค่าบริการที่ไม่คาดคิด แม้เพียงสร้าง bucket ว่างแบบ private
• เช่นเดียวกับกรณีได้รับบิลค้างชำระ $104,500 จาก Netlify สะท้อนว่าปัญหาแบบนี้เกิดซ้ำในผู้ให้บริการหลายราย

#12 การโจมตี DoS อีเมล และการสูญหายของข้อมูล

• ระหว่างถูกโจมตีแบบ DoS มีการส่งอีเมลจนทำให้เสียค่าใช้จ่าย $11,000 และหลังจากนั้นยังสูญเสียฐานข้อมูลด้วย

#13 การเรียกเก็บเงินจำนวนมากจาก Vercel รวมถึงปัญหาบัญชีและ trial

• ใน Vercel มีกรณีถูกโจมตีด้วยสแปมจนโดนเรียกเก็บเงิน $23,000 ภายในวันเดียว พร้อมมีการเปิดใช้งานบัญชีและ trial ถึง 56,000 รายการ

#14 ค่าใช้จ่ายไม่คาดคิดระหว่างการทดสอบ/ดีพลอย

• มีกรณีถูกเรียกเก็บเงินแบบไม่คาดคิดระหว่างดีพลอยฟีเจอร์ไปยัง Vercel และบริการอื่น ๆ เพื่อการทดสอบ
• sitemap.txt ใช้แบนด์วิดท์ระดับหลายร้อย GB จนก่อให้เกิดค่าใช้จ่ายสูง

#15 ต้นทุนทดสอบ Firebase และ Cloud Run

• เพียงทดสอบ Firebase และ Cloud Run แค่สองครั้ง ก็สิ้นเปลืองไปถึง $72,000 จนบริการเสี่ยงล้มละลาย

บทสรุปและข้อสังเกต

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

[ahwjdekf]

เคยพัฒนาระบบสำหรับ internal DW ของบริษัทใหญ่ เป็นงานย้ายข้อมูล on-premise เดิมไปไว้บน AWS แต่สุดท้ายแม้จะพัฒนาและทดสอบกันมาหลายเดือนก็ต้องล้มเลิกไป เพราะดูแล้วค่าใช้จ่ายรายเดือนจะสูงกว่าที่คิดมาก ต่อให้เป็นบริษัทใหญ่ การรับมือกับค่าใช้จ่ายบนคลาวด์ก็ไม่ใช่เรื่องง่าย

[regentag]

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

[ifmkl]

อยากแนะนำว่าก่อนจะเริ่มใช้คลาวด์ ลองสร้างสภาพแวดล้อมมินิเซิร์ฟเวอร์ด้วยเครื่องระดับ n100 หรือ n150 ที่กำลังนิยมกันช่วงนี้ เพื่อสะสมประสบการณ์ทั้งการทดสอบและการใช้งานจริงสักหน่อยครับ

[crawler]

ถึงจะเป็นโปรเจ็กต์เล็กมาก แค่เอาขึ้นแพลตฟอร์มแล้วถ้ามีช่องโหว่จนกลายเป็นความเสียหายทางการเงินได้ ก็น่ากลัวจริง ๆ ครับ

ผมวาง cloudflare ไว้หน้าคอนเทนต์ของตัวเอง แต่แฮ็กเกอร์หาอ็อบเจ็กต์ที่ไม่ได้ถูกแคชเจอแล้วไล่ยิงเกิน 100 ล้านครั้ง พอผมบล็อกได้ก็ยังตามหาที่อยู่ของบัคเก็ตต้นทางโดยตรงแล้วโจมตีอีก

ในกรณีแบบนี้เขาจะคืนค่าใช้จ่ายให้ไหมก็สงสัยเหมือนกัน

[GN⁺]

ความคิดเห็นจาก Hacker News

• ตอนที่ฉันเรียนเขียนโปรแกรมในบูตแคมป์ ฉันเคยลองสร้างอินสแตนซ์ elastic beanstalk แบบฟรี ตอนนั้นต้องใช้บัตรเครดิตเพื่อยืนยันตัวตน ซึ่งฉันก็ไม่ได้คิดว่าจะเป็นปัญหาอะไร แต่หลังจากนั้นเซิร์ฟเวอร์ของฉันโดนบอตสแปมโจมตี แล้ว Amazon ก็เรียกเก็บเงินฉัน 100,000 ดอลลาร์ สุดท้ายฉันได้เงินคืนก็จริง แต่ตั้งแต่วันนั้นเป็นต้นมาฉันก็เกลียด Amazon และตั้งใจว่าถ้าจำเป็นต้องใช้คลาวด์คอมพิวติ้ง ฉันจะไปใช้บริการอื่น ฉันไม่ชอบแดชบอร์ดที่ซับซ้อนและโครงสร้างที่ทำให้ลูกค้าสับสนจนเสียเงิน แค่ใช้บัตรเครดิตเพื่อยืนยันตัวตนแล้วป้องกันบอตก็น่าจะพอแล้ว น่าเสียดายที่ไม่ทำแบบนั้น ถ้าเทียบกับร้านขายของชำที่ให้ใช้บัตรเครดิตซื้อคุกกี้ง่าย ๆ ก็จะเห็นว่าเทคโนโลยีการเงินสามารถถูกใช้อย่างมีประโยชน์ได้จริง แต่กรณีนี้กลับไม่ได้ทำเช่นนั้น
  • นี่คือหนึ่งในเหตุผลที่คลาวด์โฮสติ้งน่ากลัว ไม่ใช่แค่ Amazon แต่ Azure หรือ Google Cloud ก็ “โดยปกติ” จะคืนเงินให้เหมือนกัน แต่ถ้าโปรเจ็กต์เดโมของฉันที่มีผู้เข้าชมสัปดาห์ละ 5 คน อยู่ ๆ โดน DDoS แล้วบริษัทโฮสติ้งบอกว่าคราวนี้ไม่เข้าเงื่อนไข “ปกติ” และขอให้โอนเงิน ฉันก็คงเสี่ยงล้มละลายได้เลย
  • ตอนนี้ฉันมียอดเรียกเก็บอยู่ 25,000 ดอลลาร์ เมื่อก่อนฉันเปิด data plane audit ของ SQS ทิ้งไว้ และดันเชื่อมกับฟีด real-time audit event จริง ผลคือทุก audit event แบบล้วน ๆ กลับไปสร้าง record event แบบลูปไม่สิ้นสุด บัญชีที่เคยจ่ายเฉลี่ยวันละ 2 ดอลลาร์มาตลอดเกือบ 10 ปี วันหนึ่งจู่ ๆ ก็พุ่งเป็นวันละ 3,000 ดอลลาร์ และ AWS ก็ไม่มีทั้งคำเตือนหรือการแทรกแซงใด ๆ
  • ฉันสงสัยว่าทำไมถึงไม่ชอบ Amazon ทั้งที่เขาคืนเงิน 100,000 ดอลลาร์ให้ ในกรณีของฉัน AWS คืนเงินให้เสมอแม้จะเป็นค่าบริการแพง ๆ ที่เกิดจากความผิดของฉันเองทั้งหมด ถ้ามีนโยบายแบบ “เกินงบแล้วปิดทั้งหมด” เราก็คงได้เห็นโศกนาฏกรรมอีกแบบ เช่น “โดน DDoS แล้ว AWS ปิด EC2 ของฉันทั้งหมด พร้อมทำข้อมูลในที่เก็บชั่วคราวหายไปด้วย” อีกเยอะ
  • “นี่เป็นเรื่องที่ง่ายมาก แค่มี if statement บรรทัดเดียว พอบัญชีเกินลิมิตก็ปิดอินสแตนซ์แล้ว dump บริการลง static drive ได้เลย พวกเขาแค่ไม่อยากทำ—เพราะต้องการใช้ขนาดธุรกิจเพื่อรีดกำไรจากลูกค้า คนที่ทำให้ทุกคนลำบากกับ cloud compute ตอนนี้ก็กำลังพยายามหาผลประโยชน์ทางเศรษฐกิจจากค่าใช้จ่าย AI ด้วยแรงส่งจากการยึดตลาด ทุกวันนี้ edge compute ง่ายขึ้นก็เพราะคริปโตทำให้คนลงทุนฮาร์ดไดรฟ์เกินความจำเป็น สุดท้ายตลาดก็สร้างแรงจูงใจให้ฟองสบู่และพฤติกรรมแย่ ๆ และเปิดทางให้คนที่ใช้อำนาจบิดเบือนตลาดแทนการสร้างความเชื่อใจครองเกมได้ง่าย อันธพาลฉลาด ๆ ที่ชอบทำท่าแนว ‘คุณแค่ไม่เข้าใจมันเอง! (แล้วก็ช่วยจ่ายเพิ่มอีกหน่อยก่อนตลาดพังนะ)’ นี่แหละคือปัญหาใหญ่ของวงการ บริษัทแท็กซี่ก็ไม่คิดเงิน 1,000 ดอลลาร์เพียงเพราะไม่ยอมพาคุณไปถึงจุดหมาย ฉันเลยสงสัยว่ามันจะยากอะไรนักกับการใส่ if statement ในเซิร์ฟเวอร์ จะบอกว่า Amazon แย่กว่าบริษัทแท็กซี่ก็อาจจะจริงก็ได้ นี่แหละคือเหตุผลที่ ‘Waymo’ เริ่มต้นขึ้น (หรืออาจจะล้อเล่นก็ได้)”
• ฉันคิดว่าจะเป็นเรื่องเล่าความเจ็บปวดของ serverless ในงานโฮสต์/พัฒนา/ดีบัก แต่กลายเป็นเรื่องราคาพุ่งแทน ปกติฉันไม่ได้รู้สึกว่าค่าแบนด์วิดท์เป็นเรื่องใหญ่มาก เลยอ่านผ่าน ๆ บทความแนวนี้มาตลอด แต่บทความนี้แปลกดี—กรณีที่ S3 bucket ว่างเปล่าทำให้ค่า AWS พุ่งระเบิดได้ เล่าว่าแค่ยิง API แบบไม่ยืนยันตัวตนไปยัง S3 ของคนอื่น ก็สามารถโยนภาระค่าใช้จ่ายให้เจ้าของอีกฝ่ายได้ เรื่องนี้ใหม่สำหรับฉันมาก
  • ฉันคิดว่าหลังจากบล็อกโพสต์นี้กลายเป็นกระแส ก็มีการจัดการแทบจะทันที: Amazon S3 หยุดคิดค่าบริการสำหรับบาง error code
  • หนึ่งในปัญหาจริงของสภาพแวดล้อม serverless คือแพลตฟอร์มมันเป็นกล่องดำที่ไม่โปร่งใสโดยตัวมันเองอยู่แล้ว (ซึ่งก็เป็น value proposition ของ serverless เช่นกัน) เรารับช่วง Lambda backend ขนาดใหญ่มา และทรมานมากเวลาเกิดปัญหาภายในแพลตฟอร์ม เช่น อาการ socket หลุดเป็นพัก ๆ ตอนเชื่อมกับ secret extender การไล่หาสาเหตุแทบเป็นฝันร้าย ยิ่งแย่ตรงที่ local test environment ต่างจากสภาพแวดล้อม production มากเกินไป ใช้ Google Cloud Functions ทำโปรเจ็กต์เล่น ๆ ที่บ้านอาจจะดี แต่ถ้าเป็นโปรเจ็กต์จริง ฉันอยากเอา HTTP server/queue consumer ไปลงคอนเทนเนอร์อย่าง ECS เองมากกว่า
  • เนื้อหาประมาณว่า ‘สมมติฉันสร้าง private S3 bucket เปล่า ๆ ในรีเจียนที่ชอบ แล้วบังเอิญโอเพนซอร์สยอดนิยมตัวหนึ่งตั้งค่าเริ่มต้นให้เก็บแบ็กอัปลง S3 และดันใช้ชื่อเดียวกับ bucket ที่ฉันตั้งไว้เป็น placeholder’ ฉันเลยสงสัยว่าเรื่องแบบนี้มันเกิดขึ้นบ่อยแค่ไหน—ไม่แน่ใจเลยว่าการชนกันของชื่อเกิดขึ้นจริงบ่อยแค่ไหน
  • ฟังดูเหมือนเป็นวิธีที่ใช้กำจัดคู่แข่งได้เลย นี่แหละเหตุผลที่ฉันไม่ค่อยชอบ AWS เพราะไม่มีความพยายามปกป้องลูกค้ารายเล็กจากบิลช็อกแบบไม่ทันตั้งตัวเลย Azure ก็ไม่ได้ดีกว่ามาก แต่ก็ยังพอมีมาตรการป้องกันอยู่บ้าง
  • ฉันเองก็หวังว่าจะเจอเรื่อง cloud lock-in แบบที่ทุกอย่างถูกผูกไว้กับ serverless, Lambda, DynamoDB ทั้งที่จริง ๆ น่าจะใช้แค่ VPS ราคา $20 กับ sqlite ก็พอ แต่กลับไม่ใช่ ก็เลยนิดหน่อย
• ความเจ็บปวดที่แท้จริงของ serverless ไม่ใช่การโดนบิลหนักจากเหตุการณ์ครั้งเดียว แต่คือค่าใช้จ่ายที่ค่อย ๆ พองขึ้นทุกเดือน มันสร้าง resource ได้ง่ายและปล่อยทิ้งไว้ได้ง่ายเหมือนกัน ค่าใช้จ่ายเพิ่มทีละหลายพันดอลลาร์ทุกเดือนสองเดือน จน COO สังเกตเห็น แล้วทั้งบริษัทก็เข้าภาวะฉุกเฉินเพื่อลดบิลให้ต่ำกว่า $10,000 จากนั้นก็วนซ้ำใหม่ พอสะสมหลายปีแล้วสิ้นเปลืองยิ่งกว่าการเสียเงินก้อนทีเดียวอีก
  • นี่แทบจะเป็นโมเดลธุรกิจของ AWS เลย เคยได้ยินคนเรียกมันว่าโมเดล “Planet Fitness” ไหม? สมัครหรือใช้เงินง่ายมาก แต่ยกเลิกการจ่ายเงินยุ่งยากมาก
  • ดูเหมือนองค์กรจะไม่ค่อยเรียนรู้อะไรจากช่วงเวลาที่โดนบิลแพงแบบนี้เลย ฉันสงสัยว่าต้นเหตุของค่าใช้จ่ายที่เพิ่มขึ้นเรื่อย ๆ คืออะไร และไม่มีวิธีป้องกันล่วงหน้าจริง ๆ หรือ
  • ปัญหาแบบนี้ก็เกิดกับ on-premise ได้บ่อยเหมือนกัน จะมีเซิร์ฟเวอร์ที่ยังรันแอปที่ไม่ได้ใช้แล้วอยู่ต่อไปเรื่อย ๆ (มักจะเป็น VM) แน่นอนว่าค่าใช้จ่ายของ VM ก็ไม่ได้เป็นศูนย์เหมือนกัน
• หลายครั้งความรับผิดชอบมันไม่ชัดเจน ลูกค้าต้องการเครื่องมือวิเศษแบบไร้แรงเสียดทานที่กดคลิกเดียวก็ deploy โครงสร้างพื้นฐานฮาร์ดแวร์ได้ แต่ถ้าผู้ใช้ที่ไม่มีประสบการณ์ตั้งค่าผิดแล้วโดนบิลมหาศาล พอผู้ให้บริการคลาวด์เรียกเก็บเต็ม ๆ ชื่อเสียงก็เสีย แต่ถ้าคัดกรองและจำกัดผู้ใช้ล่วงหน้า ก็กลายเป็นปิดประตูใส่นักพัฒนารายเล็กที่อยากท้าทายสตาร์ตอัป ในกรณีที่มีบิล $10,000 โผล่มากะทันหัน ฉันมักสงสัยเชิงปรัชญาว่าใครควรจ่ายเท่าไรถึงจุดไหน และต้นทุนที่เกิดจากความผิดพลาดควรมีใครรับผิดชอบแค่ไหน ถ้าฉันเขียนโค้ดให้ใช้ resource ไม่มีประสิทธิภาพมากขึ้น 10 เท่า มันควรเป็นเรื่อง “ตั้งค่าพลาดก็รับผิดชอบเอง” หรือไม่ และจากมุมลูกค้า เราควรจะไม่ต้องสนด้วยไหมว่าคลาวด์ที่ใช้เป็นเจ้าใหญ่แบบ AWS หรือเป็นบริการ API จากสตาร์ตอัปรายเล็ก
  • แล้วถ้ามีระบบแบบ budget overrun/circuit breaker (เพดานการใช้จ่าย) ล่ะ? มันไม่ได้ดูเป็นปัญหาที่แก้ไม่ได้เลย
  • คำตอบจริง ๆ ก็ง่ายมาก—กำหนดเพดานงบประมาณ
  • นี่ก็เป็นเหตุผลว่าทำไมถึงใช้เซิร์ฟเวอร์จริงที่ไม่ใช่ serverless แทน
• ที่ Hetzner ใช้ HDD 16TBx2, SSD 1TBx2, RAM 64GB, ทราฟฟิกฟรี 20TB ได้ในราคา $70 ต่อเดือน ในขณะที่ฉันเคยใช้ทราฟฟิก 1TB บน AWS micro instance แล้วโดนเก็บ $150 (ถ้าจำไม่ผิด) มันไม่จำเป็นต้องเป็นแบบนี้เลย
• เรื่องที่ว่า “ฉันวาง cloudflare ไว้หน้าคอนเทนต์ของฉัน แต่แฮ็กเกอร์หา object ที่ไม่ถูก cache เจอแล้วกระหน่ำยิงเกิน 100 ล้านครั้ง พอฉันบล็อกได้ เขาก็ไปหา origin bucket address แล้วโจมตีตรงนั้นแทน” ฉันสงสัยว่าสิ่งนี้ไม่ใช่เรื่องที่เกิดกับใครก็ได้หรือ? ฉันก็ไม่แน่ใจว่าการปล่อยให้ object ที่ไม่ถูก cache หลุดออกมา มันร้ายแรงพอ ๆ กับการเปิดพอร์ต 22 ด้วยรหัสผ่านอ่อนหรือเปล่า และปกติ S3 resource (โดยเฉพาะรูปภาพ) มันก็ถูกทำให้ใครเข้าถึงกี่ครั้งก็ได้อยู่แล้วไม่ใช่หรือ
  • ไม่ใช่เลย S3 bucket ต้องตั้งเป็น private และต้องใส่กฎความปลอดภัยให้เข้าถึงได้ผ่าน CDN เท่านั้น แบบนี้ถึงจะบังคับให้ทุก request วิ่งผ่าน CDN ได้
  • ให้ความรู้สึกเหมือนคนที่อวดว่าปล่อยช่องโหว่ OWASP Top 10 ทิ้งไว้ ทั้งที่การตั้งค่า access control ไม่ได้ยากอย่างที่คิด ถ้าพลาดเรื่องพื้นฐานแบบนี้ ก็มีโอกาสสูงว่าจะปล่อยผ่านเรื่องอื่นแบบขอไปทีเหมือนกัน ฉันไม่ไว้ใจระบบที่คนแบบนี้เป็นผู้รับผิดชอบ
  • พื้นฐานที่สุดคือปล่อย S3 object เป็น private และอย่างน้อยก็วาง proxy อย่าง cloudfront ไว้ข้างหน้า สิ่งอย่างรูปภาพต้องบังคับให้ผ่าน cache เสมอ
• จะเรียกว่า serverless ก็ไม่ถูกนัก เพราะจริง ๆ แล้วมันก็ยังเป็นการรันเซิร์ฟเวอร์อยู่บนคลาวด์อินฟราสตรักเจอร์ สุดท้ายเราก็ยังเขียนซอฟต์แวร์ตามโมเดล client-server และต้องมีเซิร์ฟเวอร์รันอยู่ที่ไหนสักแห่งให้ผู้ใช้ใช้งานได้ สำหรับฉัน ‘serverless’ ที่แท้จริงคือซอฟต์แวร์ที่ผู้ใช้ดาวน์โหลดครั้งเดียวแล้วใช้งานต่อได้โดยไม่ต้องมีอินเทอร์เน็ต หรือถึงจะส่งข้อมูลไปยังเซิร์ฟเวอร์ ก็ไม่ต้องพึ่งพาตำแหน่งเฉพาะที่นักพัฒนากำหนดไว้จุดเดียวถึงจะทำงานได้
  • โดยแก่นแล้วคำว่า ‘serverless’ หมายถึง “ระบบจัดการที่เพิ่มหรือลด resource (เซิร์ฟเวอร์) โดยอัตโนมัติตามโหลด” นี่แหละคือสาระสำคัญ โหลดเพิ่มก็เพิ่มเซิร์ฟเวอร์ ลดก็ลด และมันจะฉายศักยภาพได้จริงก็ต่อเมื่อคุณปรับโครงสร้างโค้ดทั้งระบบให้เข้ากับสภาพแวดล้อมแบบนี้อย่างมีประสิทธิภาพ นั่นคือเป็นสถาปัตยกรรมที่ควรใช้เมื่อจำเป็นจริง ๆ เท่านั้น
  • โดยทั่วไปสิ่งนั้นเรียกว่า ‘ซอฟต์แวร์แบบ local’ มากกว่า ‘serverless’ เป็นชื่อที่ไม่ค่อยดีนัก แต่จริง ๆ มันพูดถึงรูปแบบการ deploy ของแบ็กเอนด์ประเภทหนึ่ง ไม่ได้แปลว่าเป็นแอปที่ไม่มีแบ็กเอนด์เลย
  • ‘serverless’ ก็เหมือน “บริษัทที่ไม่มีพนักงาน” นั่นแหละ จริง ๆ ยังมีคนให้บริการอยู่ เพียงแต่ทุกคนเป็นพนักงานสัญญาจ้าง
  • ปกติ ‘เซิร์ฟเวอร์’ หมายถึงเครื่องเดี่ยวที่มี OS และซอฟต์แวร์หลายชั้น (รวมถึงเครื่องมือตรวจสอบ) ติดตั้งอยู่ และเปิดให้ผู้ใช้เข้าถึง business logic ได้ ถ้าจะใช้เซิร์ฟเวอร์เอง คุณต้องดูแลทุกอย่างตั้งแต่เลือก OS ติดตั้ง/อัปเดตซอฟต์แวร์สนับสนุน ไปจนถึงกู้คืนเมื่อมีปัญหา แต่ serverless เป็นโมเดล ‘function as a service’ ดังนั้นคุณสนใจแค่ business logic (โค้ดของคุณ) ก็พอ ไม่ต้องติดตั้ง OS บนเซิร์ฟเวอร์เอง ไม่ต้องดูแลซอฟต์แวร์พื้นฐานอย่าง HTTP server ไม่ต้องคอยอัปเดตหรือบำรุงรักษา แค่อัปโหลดโค้ดแล้วมันจะรันเมื่อถูกเรียก เป็นแนวคิดที่ปลดปล่อยคุณออกจากความเครียดของการดูแลเซิร์ฟเวอร์โดยสิ้นเชิง เพราะแบบนี้ถึงเรียกว่า ‘serverless’—ยังมีเซิร์ฟเวอร์อยู่จริง แต่คุณไม่ต้องจัดการมันเอง
• คำว่า “serverless” ในความเป็นจริงไม่ได้หมายความว่าไม่มีเซิร์ฟเวอร์ แต่หมายถึงคุณไม่ต้องจัดการเซิร์ฟเวอร์เอง และไม่จำเป็นต้องรู้ด้วยว่าโค้ดของคุณไปรันอยู่บนเซิร์ฟเวอร์ตัวไหน อารมณ์ประมาณ “นี่โค้ด เอาไปรันให้ทีทุกชั่วโมง ส่วนจะรันที่ไหนฉันไม่สน”
  • แม้คำนี้อาจทำให้รู้สึกขัดใจ แต่ในเชิงภาษาแล้วมันไม่ใช่ปัญหาแบบ Orwellian นัก ใน 1984 คำว่า ‘Newspeak’ คือการทำให้รูปแบบการแสดงออกหดแคบลง แต่ ‘serverless’ กลับเป็นคำใหม่ที่สร้างขึ้นเพื่อชี้ไปยังหมวดหมู่ใหม่มากกว่า แน่นอนว่ามันอาจเป็นคำที่พร่าเลือนการมีอยู่ของเซิร์ฟเวอร์ แต่จะเรียกว่ามัน Orwellian แบบตรงตัวก็คงไม่แม่นนัก ฉันคิดว่าคำอย่าง “servelet” ในความหมายว่า ‘เซิร์ฟเวอร์ขนาดเบา’ ก็อาจใช้ได้เหมือนกัน
  • ยังมีวลีประชดแบบ “คลาวด์ไม่มีจริง ก็แค่คอมพิวเตอร์ของคนอื่น” ที่ถูกใช้กันเยอะด้วย
  • ท้ายที่สุด ‘serverless’ ก็ให้ความรู้สึกเหมือน shared hosting เวอร์ชัน tech-bro ที่บวก “มาร์จิน 10,000%” และ “คิดเงินต่อ request” เข้าไป
  • ระบบ “no-code” ก็ยังขับเคลื่อนด้วยโค้ดอยู่ดี จะไปโมโหว่า PaaS หรืออะไรก็ตามยังมีเซิร์ฟเวอร์อยู่ก็เหมือนหาเรื่องบ่นมากกว่า
• ฉันเคยใช้ AWS serverless แล้วพบว่าการทดสอบบน local แทบเป็นไปไม่ได้เลย และสำหรับ serverless run ก็ต้องใช้ AWS IAM role เท่านั้น ทำให้บัญชีทั้งบัญชีเปิดสิทธิ์กว้างมาก สุดท้ายมันกลายเป็นปัญหาใหญ่ที่แทบไม่ต่างจากการทดสอบบน production ทุกครั้ง
  • ฉันก็ทำโปรเจ็กต์ serverless มาหลายปี และต้นทุนใหญ่จริง ๆ คือแทบไม่สามารถรันอะไรบน local ได้เลย เวลา debug ก็เสียไปอย่างน่าเศร้า เครื่องมือที่อ้างว่ามาแทนได้ก็แทบไม่มีประโยชน์กับโปรเจ็กต์จริง
  • ถ้าตั้งค่าไฟล์ ~/.aws/credentials ให้เหมาะสม ก็สามารถทดสอบบน local ด้วย AWS security key ได้ ใช้ makefile ทำ deployment ของ Lambda อัตโนมัติ และสร้าง custom IAM role แยกสำหรับแต่ละ Lambda เพื่อจัดการข้อกำหนดความปลอดภัยในไฟล์ JSON จุดแข็งจริงของ AWS คือทุกอย่างจัดการผ่าน API เดียวกันได้ คุณสามารถสร้างและดูแลทุกอย่างแบบ programmatically ได้
  • 1. deploy แบบผูกกับ stack ไปยังบัญชีแยกสำหรับนักพัฒนา (staging ฟรี) 2) ทดสอบบน local ด้วย Docker runtime ที่ซัพพอร์ตอย่างเป็นทางการ 3) เขียน unit test ตามปกติ 4) ใช้เครื่องมืออย่าง localstack เพื่อจำลอง staging environment แบบเดียวกันบนเครื่อง ตัวเลือกมีมากมายขนาดนี้ ฉันเลยไม่เข้าใจว่าทำไมถึงมีประสบการณ์ที่แย่ได้ขนาดนั้น
  • เป็นคำกล่าวที่ห่างไกลจากข้อเท็จจริง
• ฉันคิดว่าคำว่า ‘serverless’ ไม่ว่าอย่างไรก็เป็นการตั้งชื่อแบบ Orwellian ที่ใช้ห่อหุ้มระบบที่จริง ๆ แล้วยังอิงเซิร์ฟเวอร์อยู่ดี
• ฉันไม่อยากเชื่อว่าบริษัทพวกนี้จะคิดเงินถึง $550 ต่อ 1TB แบนด์วิดท์ ต่อให้เช่าเซิร์ฟเวอร์พร้อมพอร์ตการันตี 10Gb/s ถ้าเกิน $3 ต่อ TB ฉันก็ถือว่าโกงแล้ว ฉันสงสัยว่า serverless ใช้อะไรมาอธิบายว่าทำไมต้นทุนนี้ถึงแพงกว่าได้ถึง 150 เท่า มีคนยอมจ่ายราคานี้จริง ๆ มากกว่าหนึ่งสองคนหรือ? แค่เอาไปลง VPS ราคา $10 หรือ GitHub Pages ก็พอสำหรับ wiki อ่านหนังสือ/เอกสารเทคนิค/บล็อกแบบไม่มีปัญหา และถ้าเซ็ตอัปดีพอก็รับ concurrent 10,000 คนได้สบาย

[benjamin]

ตอนนี้คนที่เพิ่งเริ่มเข้าสู่การพัฒนาเป็นครั้งแรก เวลาสร้างอะไรบางอย่างด้วย AI คนส่วนใหญ่ก็คงให้บริการด้วยของอย่าง Vercel, Supabase กันใช่ไหม?

แต่พอบริการเริ่มโตขึ้น ดูเหมือนหลายคนจะไม่ได้คำนวณกันดีนักว่าต้องจ่ายเงินให้พวกเขาเท่าไร
ด้วยความคิดประมาณว่า ค่อยไปคิดตอนนั้นก็ได้

ผู้ก่อตั้ง Vercel หรือ Supabase ก็คงจะยิ้มกว้างแล้วพูดคล้อยตามว่า “ใช่ ๆ ค่อยไปคิดตอนนั้นก็ได้!”

แน่นอนว่าจะไปคิดตอนนั้นก็ได้เหมือนกัน ถ้าคุณมีฝีมือพอจะย้ายออกมาได้อย่างรวดเร็ว
แต่ถ้าไม่มีความรู้ด้านวิทยาการคอมพิวเตอร์ ก็คงไม่ใช่เรื่องง่าย
เงินที่เพิ่งเริ่มหาได้อาจลงเอยด้วยการเอาไปจ่ายให้พวกเขาหมด

จริง ๆ แล้วนี่คือสิ่งที่กำลังเกิดขึ้นอยู่ตอนนี้
พูดอีกอย่างคือ… กำลังมีธุรกิจขนาดใหญ่ที่เปิดขึ้นมาเพื่อกินเงินจากมือใหม่ที่กระโดดเข้ามาโดยไม่รู้อะไรเกี่ยวกับวิทยาการคอมพิวเตอร์เลย

นี่แหละคือเหตุผลที่เรายังต้องขุดลึกลงไปในวิทยาการคอมพิวเตอร์ต่อไป
บางคนใช้เงินเดือนละ 1,000,000 วอนกับบริการที่เพิ่งเริ่มทำกำไรได้ไม่นาน ขณะที่บางคนกลับรันบริการได้โดยไม่ต้องจ่ายเงินเลย
การลดต้นทุนการดำเนินงานก็เป็นทักษะอย่างหนึ่ง มันเป็นความได้เปรียบทางการแข่งขันมหาศาลไม่ใช่หรือ?
การเขียนโค้ดด้วย AI แล้วลองสร้างอะไรบางอย่างพร้อมรู้สึกสนุกไปกับมันเป็นเรื่องที่ดี แต่ถ้าไม่พยายามลงลึกไปกว่านั้น สุดท้ายก็จะสร้างความแตกต่างไม่ได้

https://jeho.page/essay/2025/09/08/sucker-developer.html