ความแตกต่างระหว่าง monolith และ microservices คืออะไร?

Question

Accepted Answer

**Monolith** บรรจุฟังก์ชันการทำงานทั้งหมดในหน่วยที่ปรับใช้ได้ตัวเดียว; **Microservices** แบ่งฟังก์ชันการทำงานนั้นออกเป็นบริการที่ปรับใช้ได้อย่างอิสระจำนวนมาก ความแตกต่างหลักคือหน่วยการปรับใช้และขอบเขตระหว่างโมดูล

## การเปรียบเทียบ

| แง่มุม | Monolith | Microservices |
|---|---|---|
| การปรับใช้ | หน่วยเดียว | หลายหน่วยอิสระ |
| ฐานข้อมูล | โดยปกติเป็น DB ที่ใช้ร่วม | DB หนึ่งต่อบริการ |
| การปรับขนาด | ปรับขนาดแอปทั้งหมด | ปรับขนาดบริการแต่ละรายการ |
| การสื่อสาร | เรียกใช้ในกระบวนการ | เครือข่าย (HTTP/gRPC/events) |
| การจับคู่ทีม | สูง | ต่ำ (ความเป็นเจ้าของต่อบริการ) |
| รัศมีการระเบิดของการล้มเหลว | แอปทั้งหมด | มักเป็นแบบแยกส่วนต่อบริการเดียว |
| ความซับซ้อนในการปฏิบัติการ | ต่ำ | สูง |

## ว่าแต่ละอย่างเข้ากันได้อย่างไร

```text
MONOLITH best when:
  ✓ small team / early-stage product
  ✓ domain not yet well understood
  ✓ simplicity and fast iteration matter most

MICROSERVICES best when:
  ✓ large org with many teams
  ✓ parts have very different scaling needs
  ✓ you need independent deploy cadence
```

## จุดอ่อน

Monolith ที่มีการจัดโมดูลอย่างไม่ดีจะไม่ดีขึ้นอย่างน่าอัศจรรย์เมื่อแบ่งแยก — คุณแค่ได้รับ**ความสั่งสม**ที่กระจายออกไป แก้ไขขอบเขตก่อน

## ทำไมจึงมีความสำคัญ

การเลือกสไตล์ที่ผิดนั้นมีราคาแพง: การแบ่งแยกที่เร็วเกินไปเพิ่มความล่าช้า ต้นทุนการปฏิบัติการ และความเจ็บปวดในการแก้จุดบกพร่องสำหรับทีมขนาดเล็ก

ระบบที่ประสบความสำเร็จส่วนใหญ่เริ่มต้นเป็น monolith ที่มีโครงสร้างดี และแยกบริการเฉพาะเมื่อขนาดทีมหรือแรงกดดันการปรับขนาดสนับสนุนอย่างชัดเจน

การปรับใช้	หน่วยเดียว	หลายหน่วยอิสระ
ฐานข้อมูล	โดยปกติเป็น DB ที่ใช้ร่วม	DB หนึ่งต่อบริการ
การปรับขนาด	ปรับขนาดแอปทั้งหมด	ปรับขนาดบริการแต่ละรายการ
การสื่อสาร	เรียกใช้ในกระบวนการ	เครือข่าย (HTTP/gRPC/events)
การจับคู่ทีม	สูง	ต่ำ (ความเป็นเจ้าของต่อบริการ)
รัศมีการระเบิดของการล้มเหลว	แอปทั้งหมด	มักเป็นแบบแยกส่วนต่อบริการเดียว
ความซับซ้อนในการปฏิบัติการ	ต่ำ	สูง