Benefits and Drawbacks

บริบท

ตอนนี้คุณเข้าใจแล้วว่า microservices architecture คืออะไรและต่างจาก monolith อย่างไร ก่อนจะตัดสินใจว่าจะเอามาใช้หรือไม่ คุณต้องเห็นบัญชีที่ตรงไปตรงมาก่อน ว่าสถาปัตยกรรมนี้ให้อะไรจริง ๆ และเรียกเก็บอะไรจากคุณจริง ๆ การตลาดและ talk ในงาน conference มักไล่ลิสต์ประโยชน์แล้วข้ามใบเรียกเก็บเงินไป บทเรียนนี้จึงวางทั้งสองคอลัมน์ไว้เคียงกัน เพราะคุณจะได้ประโยชน์ก็ต่อเมื่อยอม จ่าย ต้นทุน ทั้งสองเป็นคนละด้านของการตัดสินใจเดียวกัน

ปัญหา

อันตรายคือการรับ microservices มาใช้เพราะเห็นแต่ข้อดี แต่ประเมินข้อเสียต่ำเกินไป ทีมได้ยินคำว่า “scale อย่างอิสระ” และ “deploy ได้เร็วขึ้น” แล้วก็ขยับตัวตาม เพียงเพื่อจะค้นพบว่าตอนนี้ request หนึ่งวิ่งข้ามถึงห้า service, transaction เดียวกลายเป็น workflow หลายขั้นตอน และ bug ง่าย ๆ ตอนนี้ต้องอาศัยการเชื่อมโยง log จากสาม process

ดังนั้นคำถามที่บทเรียนนี้ตอบคือ: สำหรับแต่ละประโยชน์ที่ microservices สัญญาไว้ ต้นทุนที่คู่กันคืออะไร และคุณจะชั่งน้ำหนักทั้งสองอย่างไร?

วิธีแก้

วาง trade-off ออกมาเป็นสองคอลัมน์ที่จับคู่กัน ทุกประโยชน์ทางซ้ายมีต้นทุนคู่ของตัวเองอยู่ทางขวา ทั้งคู่มาพร้อมกันเสมอ ไม่ได้มาแยกกัน

flowchart LR
  subgraph Benefits[Benefits]
    B1[Independent deploy and scale]
    B2[Team autonomy]
    B3[Fault isolation]
    B4[Technology diversity]
  end
  subgraph Costs[Drawbacks]
    C1[Distributed-system complexity]
    C2[Data consistency is harder]
    C3[Operational overhead]
    C4[Testing across services]
  end
  B1 -.- C1
  B2 -.- C3
  B3 -.- C2
  B4 -.- C4

ทุกประโยชน์ของ microservices ถูกจ่ายด้วยต้นทุนที่คู่กัน

ประโยชน์

การ deploy และ scale อย่างอิสระ แต่ละ service ship ตามตารางของตัวเอง ดังนั้นการเปลี่ยนแปลงเล็ก ๆ ใน service หนึ่งไม่จำเป็นต้อง deploy ใหม่ทั้งระบบ คุณยังสามารถรัน instance ของเฉพาะ service ที่ต้องการเพิ่มได้ แทนที่จะ scale ทั้งแอปพลิเคชัน
ทีมเป็นอิสระ ทีมหนึ่งเป็นเจ้าของ service ได้ตั้งแต่ต้นจนจบ ทั้ง code ข้อมูล และ release pipeline แล้วตัดสินใจในขอบเขตของตัวเองได้ โดยไม่ต้องนัดแนะ codebase ร่วมหรือ deploy ร่วมกับคนทั้งบริษัท
fault isolation ความล้มเหลวสามารถถูกจำกัดให้อยู่ใน service เดียวได้ ถ้า recommendations service ล้มลง checkout service ก็ยังรับ order ต่อได้ ตราบใดที่คุณออกแบบขอบเขตให้เสื่อมสภาพอย่างนุ่มนวล (degrade gracefully)
เลือกเทคโนโลยีได้หลากหลาย แต่ละ service เลือกภาษา framework หรือ datastore ที่เหมาะกับงานของตัวเองได้ และคุณลองเทคโนโลยีใหม่ใน service เดียวได้โดยไม่ต้องเขียนทั้งระบบใหม่

ข้อเสีย

ความซับซ้อนของระบบแบบกระจาย ตอนนี้เครือข่ายอยู่ตรงกลางแอปพลิเคชันของคุณ การเรียกอาจช้า ล้มเหลว timeout หรือมาถึงสองครั้ง พฤติกรรมที่เคยเป็น function call แบบ deterministic กลายเป็น request ที่ต้องรับมือกับ partial failure
ความสอดคล้องของข้อมูลยากขึ้น เมื่อแต่ละ service เป็นเจ้าของข้อมูลของตัวเอง คุณก็เสีย atomic transaction เดียวไป การรักษาความสอดคล้องข้าม service แปลว่าต้องใช้ eventual consistency, saga และ compensating action คอร์สนี้มีโมดูลทั้งโมดูลที่เกิดขึ้นเพราะต้นทุนข้อเดียวนี้
ภาระการดำเนินงาน ตอนนี้คุณ deploy, monitor และรักษาความปลอดภัยให้ service จำนวนมากแทนที่จะเป็นตัวเดียว สิ่งนี้เรียกร้องการลงทุนจริงจังใน automation, CI/CD, container orchestration และ logging กับ tracing แบบรวมศูนย์ ก่อนที่สถาปัตยกรรมจะคุ้มทุน
การทดสอบข้าม service unit test ไม่เปลี่ยน แต่การตรวจสอบว่า service ทำงาน ร่วมกัน ได้ตอนนี้เกี่ยวข้องกับเครือข่าย contract ระหว่าง service และ failure mode ของการเรียกแบบกระจาย end-to-end test ยากขึ้นอย่างมีนัยสำคัญ

ผลลัพธ์ที่ตามมา

บทสรุปที่ตรงไปตรงมาคือ microservices ย้ายความซับซ้อน ไม่ได้กำจัดทิ้ง ใน monolith ความซับซ้อนอยู่ใน code ซึ่งมี compiler และ debugger คอยช่วย ส่วนใน microservices ความซับซ้อนส่วนใหญ่ย้ายไปอยู่ในพื้นที่ ระหว่าง service ทั้งเครือข่าย ข้อมูล และการดำเนินงาน ซึ่งเครื่องมือของคุณอ่อนกว่าและรูปแบบความล้มเหลวก็ยุ่งกว่ามาก

การแลกนี้คุ้มเมื่อประโยชน์ที่ได้ตรงกับปัญหาที่คุณมีจริง เช่น ทีมติดขัดเพราะรอกัน component ที่มีความต้องการ scale ต่างกันสุดขั้ว หรือข้อกำหนดเรื่อง fault isolation ที่ทำใน process เดียวไม่ได้ แต่จะกลายเป็นการแลกที่แย่ทันทีถ้าคุณรับต้นทุนมาเพื่อไล่ตามประโยชน์ที่ยังไม่ต้องการ บทเรียนถัดไปจะแปลงการพิจารณานี้ให้เป็นการตัดสินใจที่จับต้องได้

pattern ที่เกี่ยวข้อง

Monolith vs Microservices — สองสถาปัตยกรรมที่ trade-off เหล่านี้นั่งอยู่ตรงกลาง
When to Use Microservices — การแปลงบัญชีนี้ให้เป็นการตัดสินใจ
Data Management — โมดูลที่อุทิศให้กับต้นทุนเรื่องความสอดคล้อง

ข้อดี	ข้อแลกเปลี่ยน
deploy แต่ละ service อิสระ — release cycle เร็วขึ้น	distributed system complexity — network failure, partial failure
scale เฉพาะ service ที่ต้องการ — ประหยัด cost	operational complexity สูง — ต้องการ DevOps maturity
technology diversity — เลือก stack ที่เหมาะสมแต่ละ service	consistency ยากกว่า — eventual consistency แทน ACID
fault isolation — service หนึ่งล้มไม่ทำให้ทั้งระบบหยุด	distributed tracing และ debugging ซับซ้อนมาก

ข้อผิดพลาดที่พบบ่อย

Microservices เป็นคำตอบของทุกปัญหา — adopt microservices โดยไม่ประเมิน context

อาการ:

startup 3 คนใช้ microservices ตั้งแต่วันแรก
ใช้เวลา configure Kubernetes มากกว่า build product
monolith ที่ดี deliver faster ในระยะแรก

Distributed Monolith — แยก service แต่ยัง deploy พร้อมกันและ share database

อาการ:

service A เรียก service B แบบ synchronous ใน critical path ทุกครั้ง
database เดียวสำหรับทุก service
ได้ทั้ง complexity ของ distributed system และ coupling ของ monolith

💡 ตัวอย่างจากของจริง

Amazon (2002):

Jeff Bezos ออก mandate: ทุกทีมต้อง expose data และ functionality ผ่าน service interface

ไม่อนุญาต direct database access ข้าม team

นี่คือจุดเริ่มต้นของ microservices ที่ Amazon ก่อน Martin Fowler บัญญัติคำ

Netflix (2008):

database corruption ครั้งใหญ่ทำให้ streaming หยุด 3 วัน

ตัดสินใจ migrate จาก monolith ไป microservices บน AWS

ใช้เวลา 7 ปีจึง complete migration

🧩 microservices ย้ายความซับซ้อน ไม่ได้ลบทิ้ง

ความซับซ้อนไม่ได้หายไปตอนที่คุณ decompose แต่ย้ายที่จากใน code ออกไปอยู่ที่เครือข่าย ข้อมูล และงานปฏิบัติการแทน ให้หยิบ microservices มาใช้เมื่อการย้ายที่ครั้งนี้ซื้ออะไรที่จับต้องได้กลับมา เช่น การ scale แยกอิสระ fault isolation หรือความเป็นอิสระของทีม และใช้ก็ต่อเมื่อมี automation พอจะแบกค่าใช้จ่ายด้านปฏิบัติการแล้วเท่านั้น ไม่อย่างนั้นคุณจะเก็บความซับซ้อนไว้ครบ แต่เสีย debugger ไปฟรี ๆ