เว็บแอปส่วนใหญ่สามารถให้บริการบนเซิร์ฟเวอร์เดียวได้
- เมื่อมองตามวงการพัฒนาเว็บ จะรู้สึกได้ว่าเว็บไซต์และแอปจำนวนมากไม่ได้ต้องการอินฟราสตรักเจอร์ที่ซับซ้อน โดยส่วนใหญ่รับคำขอน้อยกว่า 10 ครั้งต่อวินาที และในวันที่ยุ่ง ๆ ก็อยู่ราว 50 ครั้งต่อวินาที
- การมีเอนด์พอยต์กระจายอยู่ทั่วโลกช่วยลด latency ได้ แต่เพราะยังต้องเข้าถึงข้อมูล จึงไม่มีความหมายมากนักหากแม้ไคลเอนต์จะอยู่ห่างเพียง 20ms แต่ฐานข้อมูลกลับอยู่ห่างจากเอนด์พอยต์นั้น 200ms
- การแคชมีประโยชน์ แต่ทำได้ผ่าน CDN หรือ HTTP caching แบบง่าย ๆ หาก push ไฟล์ใหม่ขึ้น CDN หลังการอัปเดต ในหลายกรณีทั้งไซต์ก็สามารถให้บริการจาก CDN ได้ทั้งหมด
- อาจต้องมี API endpoint บางส่วนสำหรับฟังก์ชันแบบไดนามิก แต่สิ่งนี้สามารถจัดการได้ด้วย JavaScript เป็นต้น
- โปรเจ็กต์ส่วนใหญ่สามารถรันแบบคอนเทนเนอร์บน VPS ราคา $5 ได้ และอาจจะเร็วกว่าเสียด้วยซ้ำ
ความเห็นของ GN⁺
- บทความนี้นำเสนอมุมมองเชิงวิพากษ์ต่อการใช้อินฟราสตรักเจอร์มากเกินจำเป็นในการพัฒนาเว็บแอป โดยชี้ว่าเว็บแอปจำนวนมากจริง ๆ แล้วสามารถให้บริการได้ดีพอด้วยอินฟราสตรักเจอร์ที่เรียบง่าย ซึ่งช่วยเตือนวิศวกรซอฟต์แวร์ระดับเริ่มต้นให้หลีกเลี่ยงการทุ่มทรัพยากรมากเกินไปในการวางระบบ และใช้ทรัพยากรเท่าที่จำเป็นอย่างเหมาะสม
- บทความยังเน้นย้ำความสำคัญของการแคชและ CDN ซึ่งเป็นองค์ประกอบสำคัญในการเพิ่มประสิทธิภาพของเว็บแอป และชี้ให้เห็นว่านักพัฒนาเว็บควรพิจารณากลยุทธ์การแคชเพื่อการปรับแต่งประสิทธิภาพ
- หากเว็บแอปมีขนาดเล็กหรือมีทราฟฟิกไม่มาก การเลือกใช้เซิร์ฟเวอร์เดี่ยวหรือบริการคลาวด์แบบเรียบง่ายอาจคุ้มค่ากว่าระบบกระจายที่ซับซ้อน โดยเฉพาะสำหรับสตาร์ตอัปหรือโปรเจ็กต์ขนาดเล็ก
- บทความแนะนำให้นักพัฒนาเว็บรอบคอบในการเลือกเทคโนโลยี และเลือกอินฟราสตรักเจอร์ให้สอดคล้องกับความต้องการจริงของโปรเจ็กต์ ซึ่งช่วยให้การพัฒนาไม่ถูกพัดพาไปตามกระแสเทคโนโลยี แต่ตอบโจทย์ความต้องการที่แท้จริง
- ในอีกมุมหนึ่ง บทความนี้อาจใช้ไม่ได้กับเว็บแอปหรือบริการขนาดใหญ่ที่ต้องรองรับทราฟฟิกมหาศาล ดังนั้นจึงควรตระหนักว่าการเลือกอินฟราสตรักเจอร์ที่เหมาะสมขึ้นอยู่กับขนาดและความต้องการของแต่ละโปรเจ็กต์
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผู้ใช้รายหนึ่งยืนยันว่าเมื่อโปรเจกต์ของตนขึ้นหน้าแรกของ Hacker News (HN) ก็ยังรองรับทราฟฟิกได้ดีบน Digital Ocean droplet ราคา 5 ดอลลาร์ เขาโต้แย้งว่าโปรเจกต์ส่วนใหญ่เพียงใช้การตอบสนองแบบ asynchronous และ scheduler/queue เพื่อกระจายโหลดในแนวนอนตามช่วงเวลาก็เพียงพอแล้ว อีกทั้งยังวิจารณ์ว่าวัฒนธรรม DevOps แบบใหม่ทำให้การ deploy แอปบนคลาวด์ซับซ้อนเกินไป และชี้ว่าไม่จำเป็นต้องขยายระบบเกินเหตุสำหรับซอฟต์แวร์ที่เรียบง่าย
Standard Ebooks ให้บริการ page view และ ebook จำนวนมากในแต่ละเดือน และแม้จะขึ้นหน้าแรก HN มาแล้ว 3–4 ครั้ง ก็ยังจัดการทุกอย่างได้ด้วย VPS 4GB เครื่องเดียว เขาบอกว่าที่อัปเกรดจาก 2GB เป็น 4GB ก็เพียงเพราะต้องใช้ RAM เพิ่มเพื่อสร้าง ebook
Decline and Fall of the Roman Empireเท่านั้น ไม่เช่นนั้นเซิร์ฟเวอร์ 2GB ก็เพียงพอแล้ว พร้อมแนบลิงก์ไปยังบล็อกโพสต์เกี่ยวกับเรื่องนี้ผู้ใช้คนหนึ่งซึ่งบอกว่าไม่มีเหตุผลจะใช้ k8s นอกจากเพราะวิศวกรอยากเรียนรู้ k8s เอง ยังบ่นด้วยว่าเพราะ k8s เขาจึงแม้แต่ดู server log ก็ไม่ได้ และอ้างว่าแผน Cloudflare ราคา 5 ดอลลาร์ก็น่าจะรองรับทั้งหมดได้สบาย
มีการกล่าวถึงว่า sqlite.org รองรับ HTTP request มากกว่า 500,000 ครั้งต่อวัน และให้บริการคอนเทนต์ราว 200GB โดยใช้ Linode ราคา 40 ดอลลาร์ต่อเดือน พร้อมโต้แย้งว่าถ้าแอปของคุณไม่ได้รับ request มากกว่า sqlite.org ก็ไม่จำเป็นต้องจ่ายแพงกว่านั้น
ผู้ใช้รายหนึ่งแชร์ว่าตนรันหลายเว็บแอปที่รองรับ request ราว 10,000 ครั้งต่อวัน โดยใช้ Oracle Free Tier สำหรับ backend แบบฟรี และทำ frontend integration ฟรีผ่าน Cloudflare tunneling และ Pages
มีคนกล่าวว่าตนรันหลายแอปพลิเคชันบนเซิร์ฟเวอร์ราคา 5 ยูโรเพียงเครื่องเดียว ทั้งเว็บไซต์ส่วนตัว เกมเซิร์ฟเวอร์แบบ multiplayer สองตัว และ frp สำหรับ tunneling พร้อมบอกว่าตั้งใจจะเพิ่มอย่างอื่นเข้าไปอีกจนกว่าเซิร์ฟเวอร์จะไม่ไหว นอกจากนี้ยังบอกด้วยว่าแอปอื่น ๆ ก็ทำงานได้ดีบน VM ราคา 5 ยูโร
ผู้ใช้รายหนึ่งเล่าประสบการณ์ว่าตนใช้เวลากับไฟล์ Terraform มากกว่าการเขียนฟีเจอร์จริงถึง 4 เท่า ทั้งที่บริษัทนั้นมี hit ต่อวันไม่ถึง 1,000 ครั้ง
ผู้ใช้ที่ชี้ว่า VPS ราคา 4 ดอลลาร์ต่อเดือนสามารถรองรับ query ได้หลายพันครั้งต่อวินาที ยังได้แนบลิงก์ที่เกี่ยวข้องไว้ด้วย
มีการชี้ว่าถึงแม้เว็บแอปส่วนใหญ่จะรันบนเครื่องเดียวได้ แต่ลูกค้าส่วนใหญ่มักคาดหวัง uptime เกือบ 100% และเครื่องเดียวก็ไม่สามารถตอบโจทย์ความต้องการของลูกค้าได้
ผู้ใช้ที่แสดงความเห็นต่างเกี่ยวกับเว็บแอปพื้นฐานที่ไม่ต้องการระบบซับซ้อน ระบุว่าแม้แต่บริษัทอย่าง FAANG ก็ยังรันบริการภายในและแดชบอร์ดบน single binary ได้ แต่เมื่อ downtime แปลเป็นความเสียหายโดยตรง ก็จะเริ่มตระหนักถึงความจำเป็นของระบบที่ซับซ้อนขึ้น