ในช่วง 5–6 ปีที่ผ่านมา "Microservices" กลายเป็น buzzword ที่หลายบริษัทอยากทำ โดยเฉพาะเมื่อได้ยินว่า Netflix, Amazon, Uber ใช้ architecture แบบนี้
แต่ความจริงที่ไม่ค่อยพูดถึงคือ: หลายบริษัทที่รีบทำ Microservices เมื่อยังไม่พร้อมต้องใช้เวลาและทรัพยากรมหาศาลในการ debug, maintain และแก้ปัญหาที่ distributed system สร้างขึ้น
บทความนี้อธิบาย tradeoff จริงๆ เพื่อให้คุณเลือก architecture ที่เหมาะกับสถานการณ์ธุรกิจของคุณ
Monolith คืออะไร?
Monolith คือ application ที่ทุก component อยู่ใน codebase เดียวและ deploy เป็นหน่วยเดียว เช่น web server, business logic, database access อยู่ใน project เดียว deploy ครั้งเดียว
ตัวอย่าง: Django app ที่มี views, models, และ logic ทั้งหมดใน repository เดียว deploy บน server ตัวเดียว
Microservices คืออะไร?
Microservices คือ architecture ที่แบ่ง system ออกเป็น service เล็กๆ ที่ independent แต่ละ service:
- มี codebase และ database ของตัวเอง
- deploy แยกกันได้อิสระ
- คุยกันผ่าน API หรือ message queue
ตัวอย่าง: Order service, Payment service, Inventory service, Notification service — แต่ละตัว deploy แยก scale แยก ทีมรับผิดชอบแยก
เปรียบเทียบตรงๆ
| หัวข้อ | Monolith | Microservices |
|---|---|---|
| ความง่ายในการ develop | สูง | ต่ำ |
| ความง่ายในการ debug | สูง | ต่ำมาก |
| Operational complexity | ต่ำ | สูงมาก |
| การ scale แยก component | ทำไม่ได้ | ทำได้ |
| ทีมขนาดใหญ่ทำงานพร้อมกัน | ยาก (merge conflict) | ดีกว่า |
| Time to market ระยะแรก | เร็วกว่ามาก | ช้ากว่า |
| Infrastructure cost | ต่ำ | สูงกว่า |
ความเข้าใจผิดที่พบบ่อย
"Monolith = legacy, Microservices = modern"
ไม่จริง — นี่คือ misconception ที่อันตรายที่สุด
Monolith ที่ออกแบบดีสามารถ scale ได้มหาศาล Stack Overflow ที่รองรับหลักพันล้าน request ต่อเดือนใช้ Monolith มาหลายปี เพราะ engineering team เข้าใจ tradeoff และ optimize ได้ถูกจุด
Microservices ที่ออกแบบไม่ดีคือ "Distributed Monolith" — worst of both worlds: deploy แยกแต่ depend กันแบบ tight coupling
"Microservices scale ได้ดีกว่าเสมอ"
Microservices ให้ scale แต่ละ service แยกกันได้ จริง — แต่ Monolith scale ด้วย horizontal scaling (เพิ่ม instance) ก็ได้เช่นกัน สำหรับ traffic ระดับ SME ส่วนใหญ่ Monolith + horizontal scaling เพียงพอโดยไม่ต้องการ Microservices complexity
Framework ตัดสินใจ
เลือก Monolith (หรือ Modular Monolith) ถ้า:
1. ยังอยู่ใน early stage หรือ MVP การที่ product market fit ยังไม่ชัด ทำให้ requirement เปลี่ยนไวมาก Monolith iterate ได้เร็วกว่า Microservices หลายเท่า
2. ทีมขนาดเล็กกว่า 10 คน Microservices ออกแบบมาสำหรับทีมหลาย squad ที่ทำงานแยกกัน ทีม 5 คนจะเสียเวลากับ infrastructure overhead มากกว่า value ที่ได้
3. Traffic ยังไม่สูงพอที่ต้องการ scale แยก service ถ้า peak traffic ไม่เกิน parallel users หลักพัน Monolith + proper caching + horizontal scaling เพียงพอ
4. ไม่มี DevOps mature team Microservices ต้องการ CI/CD pipeline, container orchestration, distributed tracing, centralized logging — ถ้าทีมยังไม่ mature เรื่องนี้ operational overhead จะสูงมาก
เลือก Microservices ถ้า:
1. Teams ขนาดใหญ่ต้องการ deploy แยกกัน Conway's Law: "Organizations design systems that mirror their communication structure" — ถ้ามี 5+ squad ทำงานแยกกัน Microservices ช่วยให้ team A deploy โดยไม่ต้อง coordinate กับ team B
2. Service ต่าง ๆ มี traffic pattern ต่างกันมาก เช่น Recommendation engine ใช้ GPU ส่วน Order service ไม่ต้องการ Microservices ให้ scale แต่ละ service ตาม resource ที่ต้องการจริงๆ
3. Technology stack ที่เหมาะกับแต่ละ domain ต่างกัน ML service เขียนด้วย Python, Core business logic ด้วย Go, Frontend BFF ด้วย Node.js — Microservices ให้ทำแบบนี้ได้
เส้นทางที่แนะนำสำหรับส่วนใหญ่
- เริ่มด้วย Monolith ที่ออกแบบดี (Modular Monolith)
- เมื่อ scale ถึงจุดที่ Monolith constraint จริงๆ
- Identify service ที่ต้องการ extract ออก (โดยทั่วไปเริ่มจาก high-traffic หรือ computationally expensive service)
- Extract ทีละ service แบบ incremental
- ไม่จำเป็นต้อง extract ทั้งหมด — Hybrid ก็โอเค
นี่คือ pattern ที่ Shopify, GitHub, Airbnb ทำ — เริ่มด้วย Monolith แล้ว extract service ตาม need จริงๆ ไม่ใช่ทำ Microservices ทั้งหมดตั้งแต่วันแรก
สรุป
Architecture ที่ดีไม่ได้หมายความว่าต้องเป็น Microservices เสมอ — มันหมายความว่า fit กับ stage ของธุรกิจ ขนาดทีม และ operational capability ของคุณ
ถ้ายังอยู่ใน early-to-mid stage ให้เริ่มด้วย Modular Monolith ออกแบบให้ดี scale ได้ และ migrate ได้ในอนาคตเมื่อ need จริงๆ มาถึง
ทีม Adowbig ยินดีให้คำปรึกษาด้าน architecture ที่เหมาะกับ stage และ team ของคุณโดยไม่มีค่าใช้จ่าย
