See the original English version of this article here
มาดูว่าเราจะเลือก Monolith หรือ Microservices? บทเรียนจาก Netflix ชี้ว่าไม่มีคำตอบเดียว การเลือกสถาปัตยกรรมขึ้นอยู่กับทีมและการ Scale ของระบบจริง กับบทความ Monolith หรือ Microservices? บทเรียนจาก Netflix
ตลอด 10 กว่าปีที่ผ่านมา แนวคิดที่ครอง Silicon Valley คือ Monolith ไม่สามารถรองรับการเติบโตได้ แต่ Microservices ทำได้ ซึ่ง Netflix เองก็คือหนึ่งในบริษัทที่ผลักดันแนวทางนี้ให้กลายเป็น Best Practice ของวงการ หลังจากย้ายระบบจาก Java App ขนาดใหญ่ (Monolith) ไปสู่ Microservices จำนวนมหาศาล
แต่สิ่งที่น่าสนใจคือ จากประสบการณ์จริงในการดูแล Streaming Platform ที่ซับซ้อนที่สุดในโลก Netflix กลับค้นพบความจริงตรงกันข้าม โดยภายใต้เงื่อนไขบางอย่าง Monolith สามารถรองรับการขยายระบบ (Scale) ได้ดีกว่า Microservices
ความเชื่อผิด ๆ เกี่ยวกับ Microservices ที่ “Scale ได้ไม่จำกัด”
ทฤษฎีของ Microservices บอกว่า:
- แต่ละบริการสามารถขยายตัวได้อิสระ
- ทีมต่าง ๆ ปล่อย Code ได้โดยไม่ต้องรอซึ่งกันและกัน
- ปัญหาจะถูกจำกัดวง ไม่ลามไปทั้งระบบ
แต่ในความเป็นจริง กลับเจอปัญหาเหล่านี้:
- Network Tax: ทุกครั้งที่มีการสื่อสารข้าม Service Boundary ต้องมีการ Serialize/deserialize, Network Hop, Retry และ Timeout ซึ่งทั้งหมดนี้เพิ่ม Latency ให้กับระบบ
- Operational Complexity: แต่ละบริการต้องมี Monitoring, CI/CD, Alert และ Incident Playbook ดังนั้น ยิ่งบริการเยอะ ยิ่งยุ่ง
- Debugging ยุ่งยาก: แค่ Trace ฟังก์ชันเดียว อาจต้องไล่ผ่านบริการนับร้อย
Netflix ซึ่งมีระบบที่ใช้ Microservices เป็นพัน ต้องเผชิญสิ่งเหล่านี้ทุกวัน
เรื่องที่ทำให้ประหลาดใจ: Monolithic Core ที่ Scale ได้ดีกว่า
ไม่ใช่ว่า Netflix ใช้ Microservices ไปทั้งหมด แต่ยังมีบางระบบที่ถูกเก็บไว้ใน Monolithic Core เช่น Recommendation Engine, ระบบ Billing และ Playback Authorization
สาเหตุคือ เมื่อมี Traffic พุ่งสูง (เช่น ซีรีส์ดังเปิดตัวตอนเที่ยงคืน) Monolith สามารถ Scale Horizontally ได้ มีประสิทธิภาพกว่าการจัดการ Microservices จำนวนมาก
ข้อดีของ Monolith:
- Deployment Artifact เดียว
- Runtime เดียว
- Scaling Policy เดียว
- ส่วนประกอบน้อยลง = โอกาสล้มเหลวน้อยลง
Microservices vs Monolith เมื่อเจอการใช้งานระดับใหญ่
- Microservices: ทุกครั้งที่ Call ข้าม Service = Latency + Overhead
- Monolith: Call ภายใน Memory = เร็วกว่า, ถูกกว่า, ง่ายกว่า
ผลการทดสอบ (Benchmark) พบว่า Monolith ไม่เพียงแต่ตอบสนองได้เร็วกว่า แต่ยังต้องใช้ทีม DevOps น้อยลงเวลาแก้ปัญหา Outage
ทำไมวงการถึงพลาดจุดนี้
- Narrative Momentum: Microservices ถูกเล่าขานว่าเป็น “คำตอบสมัยใหม่” จนไม่มีใครตั้งคำถาม
- Org Fit > Tech Fit: Microservices แก้ปัญหาการบริหารทีม มากกว่าปัญหาทางเทคนิคเสมอไป
- Conference Bias: งานสัมมนามักเล่าความสำเร็จของ Microservices แต่ไม่ค่อยมีใครแชร์ “ชัยชนะเงียบ ๆ” ของ Monolith
Monolith หรือ Microservices?
บทเรียนที่แท้จริง: เลือกสถาปัตยกรรมให้เหมาะกับบริบท
Netflix ไม่ได้เลิกใช้ Microservices แต่การที่ยังพึ่งพา Monolithic Core แสดงให้เห็นว่า ไม่มีสถาปัตยกรรมไหนที่ดีที่สุดเสมอไป
Monolith ที่ออกแบบดี + ใช้เครื่องมือสมัยใหม่ ก็ Scale ได้อย่างน่าทึ่ง
สิ่งสำคัญคือ อย่าตามกระแส โดยไม่คิดถึงบริบทของระบบ
บางครั้งแนวทางดั้งเดิมก็ยังคงดีอยู่ และในบางสถานการณ์ มันอาจดียิ่งกว่าวิธีที่ถูกมองว่า “ทันสมัย” อีกด้วย
และทั้งหมดนี้ก็คือ Monolith หรือ Microservices? บทเรียนจาก Netflix
เมื่อ หางาน IT ให้ ISM Technology Recruitment เป็นอีกหนึ่งตัวช่วย เพื่อให้คุณได้ “ชีวิตการทำงานในแบบที่คุณต้องการ” เพียงส่ง Resume มาที่นี่
ISM เชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ ได้เปิดทำการมาแล้วกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
Source: https://medium.com/