ความซับซ้อนที่ซ่อนอยู่
Dave Farley อธิบายว่า microservices ไม่ได้แย่โดยตัวมันเอง แต่ มันต้องอาศัย “วินัยและความซับซ้อนทางวิศวกรรม” สูงมาก เพื่อให้ทำงานได้จริง เช่น
- ต้องมีระบบสื่อสารระหว่าง service ที่ดี (API, message queue, event bus ฯลฯ)
- ต้องจัดการกับ distributed data ที่ไม่สอดคล้องกัน
- ต้องมีระบบ monitoring, logging และ deployment pipeline ที่แข็งแรง
- และที่สำคัญ ต้องมีทีมที่เข้าใจ “ขอบเขตของบริการ” อย่างแท้จริง
เมื่อทีมขนาดกลางหรือเล็กพยายามนำ microservices มาใช้โดยไม่มีพื้นฐานเหล่านี้ ผลลัพธ์ที่ได้คือ “distributed monolith” — ระบบที่ซับซ้อนกว่าเดิมแต่ไม่ได้ประโยชน์ใด ๆ เพิ่ม
ต้นทุนที่มองไม่เห็น
Microservices เพิ่มภาระทั้งในด้านการดูแลและค่าใช้จ่าย:
- โครงสร้างพื้นฐาน (Infrastructure) ต้องซับซ้อนขึ้น: CI/CD, container orchestration, network, security
- ค่า latency และ debugging สูงขึ้นเพราะมีหลาย service ต้องประสานกัน
- ทีมต้องเข้าใจภาพรวมระบบทั้งระบบ แทนที่จะโฟกัสเฉพาะฟีเจอร์เดียว
หลายบริษัทจึงเริ่มรู้สึกว่า “เราจ่ายแพงเกินกว่าผลลัพธ์ที่ได้จริง”
Modular Monolith กลับมามีบทบาท
แนวคิด “Modular Monolith” กลายเป็นทางสายกลางที่หลายทีมเริ่มกลับมาใช้
คือระบบ monolith ที่ยังมีโครงสร้างแบบแยกโมดูลชัดเจน — ง่ายต่อการดูแลและขยายในอนาคต โดยไม่ต้องรับภาระจาก distributed system เต็มรูปแบบ
Dave ย้ำว่า เทคโนโลยีไม่ควรนำหน้าเหตุผลทางธุรกิจ เราควรเริ่มจากปัญหาที่แท้จริงก่อน แล้วค่อยเลือกสถาปัตยกรรมที่เหมาะสม ไม่ใช่เลือกเพราะมัน “ดูเท่เหมือนที่บริษัทใหญ่ใช้”
สรุป
Microservices ไม่ได้ตายไปไหน — แต่มันไม่เหมาะกับทุกคน
องค์กรที่ประสบความสำเร็จจริง ๆ กับ microservices มักจะมีวินัยสูง, ระบบอัตโนมัติที่ดี, และทีมที่เข้าใจการออกแบบเชิงระบบอย่างลึกซึ้ง
สำหรับองค์กรทั่วไป “Modular Monolith” หรือ “Hybrid Architecture” กลับกลายเป็นคำตอบที่สมเหตุสมผลกว่า เพราะช่วยให้ทีมโฟกัสกับคุณค่าทางธุรกิจมากกว่าเทคโนโลยี
บทเรียนจากวิดีโอนี้คือ:
“อย่าเริ่มต้นด้วย microservices เพราะมันฮิต — เริ่มจากการเข้าใจปัญหาที่คุณต้องแก้ก่อน แล้วค่อยเลือกเครื่องมือที่เหมาะกับมัน”
