Serverless เป็นเรื่องหลอกลวง: ใช้แค่คอนเทนเนอร์ก็พอ
(sliplane.io)- Serverless ดูเหมือนจะใช้งานง่าย แต่ในความเป็นจริงเป็นสถาปัตยกรรมที่ก่อให้เกิด ความซับซ้อน ข้อจำกัด และต้นทุนสูง
- คอนเทนเนอร์มอบ ความสามารถในการพกพา การคงสถานะ และการควบคุมที่ชัดเจน และเหมาะกับกรณีใช้งานส่วนใหญ่มากกว่า
- Serverless มี โครงสร้างต้นทุนที่ไม่โปร่งใส และคาดเดาไม่ได้ พร้อมทั้งสร้าง ความซับซ้อนที่ไม่จำเป็น ระหว่างองค์ประกอบต่าง ๆ
- ความสามารถในการสเกลและความสะดวกของ Serverless เหมาะกับ กรณีใช้งานที่จำกัด เท่านั้น
- ในสภาพแวดล้อมการใช้งานจริง การดีพลอยแบบอิงคอนเทนเนอร์ เรียบง่ายกว่า สเกลได้ และคุ้มค่ากว่า
Serverless Is a Scam. Just Use a Container.
Serverless คืออะไร?
- Serverless คือการ ดีพลอยโค้ดในระดับฟังก์ชันเดี่ยว โดยให้แพลตฟอร์มคลาวด์จัดการการรันและการสเกลให้อัตโนมัติ
- แต่ในทางปฏิบัติกลับมีปัญหาต่อไปนี้
- ข้อจำกัดด้านเวลารัน (เช่น AWS Lambda จำกัดไว้ที่ 15 นาที)
- ไม่สามารถคงสถานะได้ (รีเซ็ตใหม่ทุกครั้งที่รัน)
- ปัญหา cold start
- สภาพแวดล้อมที่ดีบักแทบไม่ได้
- การตั้งค่าและคอนฟิกเฉพาะแพลตฟอร์ม
- การใช้ YAML มากเกินไป
- แม้จะดูเรียบง่าย แต่ ไม่เหมาะกับงานที่ซับซ้อน
คอนเทนเนอร์: เรียบง่าย ทรงพลัง และน่าเบื่อในความหมายที่ดี
- คอนเทนเนอร์มีข้อดีดังนี้
- เริ่มทำงานได้รวดเร็ว
- รันได้ในทุกสภาพแวดล้อม
- คงสถานะได้ (ใช้
Docker volume) - ไม่มีข้อจำกัดด้านเวลารัน
- ดีบัก พัฒนาแบบโลคัล และสลับไปสู่ระบบโปรดักชันได้อย่างอิสระ
- ตัวอย่างโค้ด:
docker run -v my-data:/data my-app - ผลลัพธ์คือสามารถรัน เวิร์กโหลดที่มีสถานะ ได้อย่างสม่ำเสมอไม่ว่าจะอยู่ที่ไหน
- ไม่ผูกติดกับผู้ให้บริการ ไม่มีค่าใช้จ่ายแอบแฝง และไม่ต้องปรับโครงสร้างโดยไม่จำเป็น
การตั้งราคาของ Serverless: ชวนให้ผู้ใช้สับสน
- ค่าใช้จ่ายของ Serverless ถูกจัดโครงสร้างไว้อย่างซับซ้อนมาก
- คิดค่าบริการต่อการเรียกใช้งาน
- ตามปริมาณการใช้หน่วยความจำ
- ตามเวลาที่ใช้รัน
- ตามปริมาณข้อมูลที่รับส่ง
- แตกต่างกันตามรีเจียน
- รวมถึงค่าเข้าถึง secret key เป็นต้น
- ตัวอย่างคำศัพท์ที่ชวนสับสน:
- Provisioned Concurrency Units
- GB-seconds
- Requests Tier 1/2/3
- ด้วยโครงสร้างการคิดค่าบริการที่คาดเดาไม่ได้ จึงอาจทำให้เกิด บิลที่ไม่คาดคิด
- เปรียบเทียบกันแล้ว VPS ราคา $5 ให้ ค่าบริการแบบเหมาจ่ายที่คาดเดาได้ พร้อมการควบคุมทรัพยากรทั้งหมด
ข้อโต้แย้งต่อคำกล่าวที่ว่า “Serverless สเกลได้”
- Serverless สเกลได้ในเชิงเทคนิค แต่แอปส่วนใหญ่ในโลกจริงไม่ได้ต้องการสิ่งนั้น
- สิ่งที่แอปพลิเคชันส่วนใหญ่ต้องการจริง ๆ คือ
- ความคาดเดาได้
- ความสามารถในการมอนิเตอร์
- ข้อจำกัดทรัพยากรที่เหมาะสม
- สภาพแวดล้อมสำหรับพัฒนาและ staging
- ในแนวทางแบบคอนเทนเนอร์ การสเกลก็ทำได้ง่ายเช่นกัน
replicas: 5 - หรือจะสเกลแนวนอนด้วยการใช้ load balancer ก็ได้
การออกแบบแบบไร้สถานะสร้างปัญหาแบบประดิษฐ์ขึ้นมา
- Serverless บังคับให้ต้องออกแบบ แบบไร้สถานะเสมอ
- ใช้แคช เซสชัน ไฟล์ชั่วคราว หรือการเชื่อมต่อแบบคงอยู่ไม่ได้
- ผลลัพธ์คือจำเป็นต้องมีองค์ประกอบต่อไปนี้
- ฐานข้อมูลภายนอก
- distributed cache
- file storage
- event bus
- state machine
- สุดท้ายแล้วแอป Serverless ที่ “เรียบง่าย” กลับมี การพึ่งพา SaaS มากกว่า 6 ตัว
- ในทางกลับกัน คอนเทนเนอร์สามารถทำสิ่งต่อไปนี้ได้
- memory cache
- เขียนลงดิสก์
- คงเซสชันไว้ได้
- รันได้ไม่จำกัดเวลา
คำตอบต่อแนวคิด “ฉันไม่อยากดูแลเซิร์ฟเวอร์”
- มีวิธีใช้แพลตฟอร์มแบบคอนเทนเนอร์โดยไม่ต้องบริหารจัดการเซิร์ฟเวอร์เอง
- ใช้แพลตฟอร์มอย่าง Sliplane, Railway, Coolify เป็นต้น
- หรือใช้เพียง Docker + systemd บน VPS ก็ได้เช่นกัน
- มีความสะดวกด้านการปฏิบัติการครบถ้วน เช่น การดีพลอยจาก Git, การย้อนกลับเวอร์ชัน, ล็อก, เมตริก
- และยัง เข้าใจและควบคุมทั้งระบบได้
ข้อโต้แย้งต่อคำกล่าวที่ว่า “Serverless ถูกกว่า”
- หากมีความถี่ในการเรียกใช้งานต่ำมากก็อาจถูกกว่าได้
- แต่ต้นทุนจะพุ่งขึ้นอย่างรวดเร็วในกรณีต่อไปนี้
- เมื่อทราฟฟิกเกินระดับหนึ่ง
- เมื่อต้องใช้หน่วยความจำมากขึ้น
- เมื่อมีการประมวลผลจริงจำนวนมาก
- เมื่อมีการรับส่งข้อมูลมาก
- Serverless ทำให้ ปรับแต่งให้เหมาะสมได้ยาก เพราะแพลตฟอร์มซ่อนทุกอย่างไว้
- ในทางกลับกัน คอนเทนเนอร์
- รันต่อเนื่องได้แม้บนฮาร์ดแวร์ราคาถูก
- รวมเข้ากับแคชและสตอเรจได้
- benchmark และ tuning ได้ง่าย
- ไม่มีการคิดค่าบริการระดับมิลลิวินาที
กรณีที่ Serverless เหมาะสมจริง ๆ
- เหมาะกับงานที่เกิดเป็นช่วง ๆ และไร้สถานะ เช่น
- ฟังก์ชันแบบ event-driven (เช่น การปรับขนาดรูปภาพ)
- งานที่รันไม่บ่อยหรือ webhook
- เครื่องมือภายใน
- POC
- กรณีที่ต้องการสเกลขึ้น/ลงอย่างรวดเร็ว
- แต่เมื่อเป็น แอปพลิเคชันจริง ก็มักจะชนข้อจำกัด
- และต้องจ่าย ต้นทุนมหาศาล ทั้งในแง่เวลา ค่าใช้จ่าย และความซับซ้อน
เหตุผลที่คอนเทนเนอร์เป็นตัวเลือกที่ดีกว่า
- คอนเทนเนอร์มอบสิ่งต่อไปนี้
- ความสามารถในการพกพา
- การควบคุม
- ความเรียบง่าย
- ความโปร่งใส
- ความยืดหยุ่น
- รองรับทั้งการดีพลอยแบบคอนเทนเนอร์เดี่ยวหรือหลายคอนเทนเนอร์ การสเกล การคงสถานะ งานเบื้องหลัง และการเชื่อมต่อฐานข้อมูล
- ย้ายแพลตฟอร์มได้โดยไม่ต้องเขียนโค้ดใหม่
สรุป (TL;DR)
- Serverless ดูเท่มากในทางทฤษฎี
- แต่ในโลกความจริงมันคือ:
- ไม่โปร่งใส
- ต้นทุนสูง
- ซับซ้อนเกินจำเป็น
- ถูกโฆษณาเกินจริง
ก่อนจะเริ่ม ให้ถามตัวเองก่อนว่า:
“สิ่งนี้สร้างเป็นคอนเทนเนอร์ธรรมดาไม่ได้หรือ?”
- ถ้าคำตอบคือ “ได้” การ เริ่มต้นด้วยคอนเทนเนอร์คือทางเลือกที่ดีกว่า
คำแนะนำในการลงมือทำต่อ
- แนะนำให้แชร์ประสบการณ์ที่เคยเจอ ค่าใช้จ่ายไม่คาดคิดหรือเวิร์กโฟลว์ที่ไม่มีประสิทธิภาพ จาก Serverless
- อย่าทำให้ปัญหาง่าย ๆ ซับซ้อนเกินความจำเป็น
19 ความคิดเห็น
ก็มี xfaas อยู่แล้วนะ.. แล้วก็มี cf workers ด้วย ดูเหมือนเป็นบทความที่มีอคตินะครับ
ตอนจะเช่า GPU ผมกำลังคิดอยู่ว่าจะรันแบบสั้น ๆ ด้วย serverless function น่ะครับ
ในคอนเทนเนอร์ก็ทำแบบนั้นได้ไหมครับ
ในบริการ PHP เว็บโฮสติ้งสมัยก่อน ถ้าเอา PHP ออกแล้วใส่ JS ที่มี vendor lock-in หนัก ๆ เข้าไป....
ผมอดคิดไม่ได้ว่ามันคงแทบแยกไม่ออกจากแพลตฟอร์มเซิร์ฟเวอร์เลส FaaS ชื่อดังทั้งหลาย
แน่นอนว่าในฐานะคนสายชิมของแย่ที่ใช้ PHP กับ JS/TS เป็นหลัก ผมก็ใช้งานมันได้อย่างพอใจอยู่
แต่ถึงอย่างนั้นก็ยังไม่ค่อยเข้าใจว่าทำไมหลายคนถึงประเมินว่าสิ่งนี้มันอร่อยนัก
โดยส่วนตัวผมคิดว่าการใช้บริการเซิร์ฟเวอร์เลสของผู้ให้บริการนั้นมีความเสี่ยง แต่การใช้คอนเทนเนอร์เพื่อให้บริษัทสร้างและให้บริการสภาพแวดล้อมแบบเซิร์ฟเวอร์เลสด้วยตัวเองก็ดูเป็นทางเลือกที่ดีครับ ถ้านำเซิร์ฟเวอร์เลสมาใช้ในฐานะ "แนวคิด" มากกว่าจะเป็นบริการ ก็น่าจะเวิร์กนะครับ
ช่วงหนึ่งมีทั้งทวีตและวิดีโอ[1] ที่บอกว่าเลิกใช้ Edge rendering ของ vercel แล้ว รวมถึงบทความเกี่ยวกับ serverless server (ฮ่าๆ)[2] ที่เป็นกระแสอยู่พอสมควรนะครับ คิดว่าน่าจะมีมุมมองคล้ายกับบทความที่ออกมาในตอนนั้น
นี่เป็นความเห็นส่วนตัว แต่ในมุมของนักพัฒนา frontend ผมคิดว่าการเอา serverless function ไปผูกกับคำขอของผู้ใช้ยังเป็นเรื่องที่อีกไกลอยู่ (ถ้าแอปพลิเคชันที่กำลังจะทำไม่ใช่ MVP นะครับ)
[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…
แน่นอนว่าอย่างที่มีคอมเมนต์ไว้ในโพสต์นี้เหมือนกัน ดูเหมือนจะเป็นบทความที่ตั้งใจเขียนให้ยั่วกระแสมากเกินไปจริง ๆ นะ :(
ในมุมของคนที่เคยใช้งานทั้งสภาพแวดล้อมแบบคอนเทนเนอร์ (เน้น ECS Fargate และ Kubernetes cluster) และสภาพแวดล้อมแบบ serverless (AWS) ผมรู้สึกว่ายังไม่ค่อยโดนใจเท่าไรนัก
สิ่งที่ยกมาเป็นข้อดีของสภาพแวดล้อมแบบคอนเทนเนอร์นั้น ก็เป็นจุดที่อาจกลายเป็นข้อเสียได้พร้อมกันเช่นกัน
ส่วนที่พูดว่า 'ควบคุมได้เองโดยตรงและมี state ได้' นั้น สำหรับผมทั้งหมดล้วนกลายเป็นจุดที่ต้องดูแล ทำให้ความยากในการปฏิบัติการสูงขึ้น
ผมจึงแนะนำ serverless อย่างมากสำหรับองค์กรขนาดเล็ก หรือองค์กรที่ไม่มีทีมดูแลเซิร์ฟเวอร์แบบเฉพาะทาง
อ้อ แต่เรื่องที่การคำนวณค่าใช้จ่ายซับซ้อนหรือคาดเดาได้ยาก รวมถึงปัญหา vendor lock-in นั้น ผมเห็นด้วยครับ
ขอเสริมจากที่มีคนพูดถึงประสบการณ์การพัฒนาและการทำ observability นะครับ
ถ้าจัดสภาพแวดล้อมการรวมระบบตั้งแต่ช่วงแรกไว้ดีพอ ก็สามารถได้ประสบการณ์การพัฒนาที่ไม่แพ้แบบคอนเทนเนอร์ หรืออาจจะใกล้เคียงความเป็นเนทีฟยิ่งกว่าแบบคอนเทนเนอร์ด้วยซ้ำ (และก็มีเครื่องมือหลากหลายสำหรับเรื่องนี้)
ส่วน observability ถ้าจะทำกันแบบลึกจริงจัง ไม่ว่าจะเป็น serverless หรือแบบคอนเทนเนอร์ก็ไม่ใช่ปัญหาที่แก้ง่ายเหมือนกันทั้งคู่ ไม่ว่าจะเป็นการรวมศูนย์ล็อก การแสดงผลเมตริกต่าง ๆ, APM, การแสดงผลการใช้ cpu/memory และการวางกลยุทธ์การสเกลตามนั้น ฯลฯ...
แต่ถ้ายังไม่ถึงขั้นนั้น เมตริก/การรวมล็อกที่คลาวด์เวนเดอร์ให้มาพื้นฐานก็ทรงพลังอยู่แล้ว เลยไม่ได้ต่างกันมากครับ
ถ้าจะพูดกันแบบตรง ๆ หน่อย ผมก็อยากถามว่า 'ได้ลองทำ serverless แบบจริงจังพอสมควรแค่ไหนแล้ว?' 😅
ผมก็คิดเหมือนกันว่าอาจจะดีกว่าไหมถ้ารันเฉพาะเอ็นด์พอยต์ที่จำเป็นบางส่วนบน Lambda แต่ตั้งแต่แรกผมเองก็ไม่มีประสบการณ์พัฒนาแบบเซิร์ฟเวอร์เลส เลยพูดอะไรมากไม่ได้ อย่างไรก็ดี มันก็ดูเหมือนว่าจะเหมาะกับบางกรณีพิเศษอยู่เหมือนกัน
บริษัทที่เขียนบทความนี้เป็นบริษัทแพลตฟอร์มโฮสต์คอนเทนเนอร์อยู่แล้ว เลยอาจจะเขียนจากมุมมองที่มีอคติหรือเปล่าครับ 555
ก่อนหน้านี้ก็มีคนสงสัยบทความของนักพัฒนาจาก netlify (คู่แข่ง) ที่แสดงความกังวลเกี่ยวกับ nextjs (vercel) ทางฝั่งฟรอนต์เอนด์อยู่เหมือนกันใช่ไหมครับ พอดูคอมเมนต์แล้วก็ดูเหมือนไม่ได้ลำเอียงนะครับ
ผมอยู่ฝั่งฟรอนต์เอนด์เลย... ไม่ได้ใกล้ชิดกับด้านนี้เท่าไร แต่ก็เหมือนจะเห็นมีมแนว serverless (มีเซิร์ฟเวอร์อยู่) บ่อย ๆ เหมือนกัน ฮ่า
ปัญหาใหญ่คือประสบการณ์การพัฒนานั้นด้อยกว่าแบบเนทีฟอย่างเห็นได้ชัดมาก และตัวซอฟต์แวร์เองก็เกิดการพึ่งพาผู้ให้บริการอินฟรามากขึ้น ทำให้พอตั้งหลักได้แล้วก็หนีออกได้ยาก มีทั้งกรณีอ้างอิงที่น้อยกว่าอย่างชัดเจน และความสามารถในการสังเกตการณ์ก็ตกต่ำมากด้วย
ดูเหมือนว่า Cloudflare จะเป็นบริษัทที่พยายามทำ serverless ได้ดีกว่าบริษัทอื่นอยู่บ้าง ฐานข้อมูลก็เป็น serverless, key-value storage ก็เป็น serverless, แม้กระทั่ง message queue ก็ยังมีแบบ serverless...
(แน่นอนว่า พอเป็นแบบนี้ก็ทำให้รู้สึกต่อต้านอยู่บ้าง เพราะเหมือนจะถูกผูกติดและถูกจำกัดไว้กับแพลตฟอร์มอย่างสมบูรณ์)
ถึงอย่างนั้น หากการดีบัก, ความสามารถในการสังเกตการณ์ และประสบการณ์การพัฒนาไม่ได้รับการปรับปรุง มันก็ยังคงเป็นการอยู่กับที่เหมือนเดิมเท่านั้น
ไป Cloud Run เลย
การรันบริการด้วยเซิร์ฟเวอร์เลสคือการเลือกใช้เครื่องมือผิดประเภท
มีปัญหาเฉพาะบางอย่างที่ต้องใช้เซิร์ฟเวอร์เลส และเหมาะกับงานที่มีการใช้งานเป็นครั้งคราว
แล้วกับบริการคอนเทนเนอร์แบบ serverless ก็ยังคิดเหมือนกันไหม
เพราะปัญหาของบริการ serverless แบบเดิม ๆ (อย่าง Lambda) ทำให้ AWS ออก Fargate มา แล้วก็ทำ App Runner ที่ง่ายกว่านั้นอีก 🤔
แถมยังมีบริการคอนเทนเนอร์แบบ serverless ของ Google Cloud อย่าง Cloud Run ที่ scale to zero ได้แบบเทพ ๆ อีกด้วย
ส่วนตัวแล้วในบรรดาพวกนี้ รู้สึกว่า Cloud Run ให้ประสบการณ์การพัฒนาที่ดีที่สุด
Serverless (มีเซิร์ฟเวอร์อยู่)
ความเห็นจาก Hacker News
ตั้งแต่แรกมันก็ไม่ใช่ Serverless แต่เป็น Serverlease ต่างหาก
555555