Service Mesh คืออะไร และทำไมคุณถึงต้องใช้มัน?

Question

Accepted Answer

**Service Mesh** (Istio, Linkerd) ย้ายความกังวลเกี่ยวกับเครือข่ายระหว่างบริการ — retry, timeout, mTLS, traffic routing, observability — **ออกจากโค้ดแอปพลิเคชัน** ไปยังชั้น network infrastructure ของ **sidecar proxies**

## วิธีการทำงาน

แต่ละ instance ของบริการทำงานข้างๆ **sidecar proxy** (เช่น Envoy) 交通ทั้งหมดไหลผ่านตัวเพื่อพรอกซี ซึ่งสร้าง **data plane**; **control plane** จะกำหนดค่าพวกเขา

```text
┌─────────────────┐        ┌─────────────────┐
│ Service A       │        │ Service B       │
│  app  ⇄ [proxy] │◀──────▶│ [proxy] ⇄  app  │
└─────────────────┘  mTLS  └─────────────────┘
        ▲ configured by ▲
        └──── Control Plane (Istio/Linkerd) ────┘
```

## สิ่งที่มันให้

- **mTLS** ระหว่างบริการโดยอัตโนมัติ (ไม่มีการเปลี่ยนแปลงแอป).
- **ความยืดหยุ่น** — retry, timeout, circuit breaking ที่ proxy
- **การจัดการ traffic** — canary, A/B, weighted routing
- **Observability** — metrics, traces, logs เพียงรูปแบบเดียว

## ตัวอย่างนโยบาย

```yaml
# shift 10% of traffic to v2 (canary), no code change
route:
  - destination: { host: orders, subset: v1 }
    weight: 90
  - destination: { host: orders, subset: v2 }
    weight: 10
```

## Trade-offs

Mesh เพิ่มความหน่วง (extra hops), resource overhead (ตัวหนึ่งต่อ pod), และความซับซ้อนการดำเนินงานจริงๆ

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

Mesh ทำให้การยืดหยุ่น ความปลอดภัย และการสังเกตการณ์ เป็นมาตรฐานสำหรับทุกบริการ โดยไม่ต้องให้แต่ละทีมนำโครงสร้างเครือข่ายกลับมาใช้ใหม่ในภาษาที่แตกต่างกัน

แต่มันหนัก: เลือกใช้มันเมื่อคุณมีบริการมากพอที่ logic เครือข่ายที่ซ้ำซ้อน ก็นับได้ว่า mesh ค่าใช้งานการดำเนินการ