Service Mesh adalah lapisan infrastruktur yang mengatur komunikasi antar microservice, memindahkan logika networking (retry, circuit breaker, observability) keluar dari kode aplikasi.

Masalah tanpa Service Mesh:

// Setiap service harus implementasi sendiri:
class OrderService {
  async callUserService(userId) {
    // Retry logic
    for (let i = 0; i < 3; i++) {
      try {
        const resp = await fetch("http://user-service/users/" + userId);
        return resp.json();
      } catch (e) {
        if (i === 2) throw e;
        await sleep(Math.pow(2, i) * 1000); // backoff
      }
    }
  }
  // + circuit breaker, timeout, tracing, mTLS... semua harus tulis sendiri!
}

Kode networking yang sama ditulis berulang di setiap service. Sulit distandarkan dan di-update.

Solusi: Sidecar Proxy

Setiap service mendapat proxy (sidecar) yang mengurus semua komunikasi:

┌─────────────────────────────────┐
│  Pod / Container Group          │
│  ┌──────────────┐ ┌──────────┐  │
│  │ Order Service│ │ Sidecar  │  │
│  │ (bisnis)     │◄►│ (Envoy)  │  │
│  └──────────────┘ └────┬─────┘  │
└────────────────────────┼────────┘
                         │ mTLS
                         ▼
┌────────────────────────────────────┐
│  Pod / Container Group             │
│  ┌──────────────┐  ┌──────────┐   │
│  │ User Service │  │ Sidecar  │   │
│  │ (bisnis)     │◄►│ (Envoy)  │   │
│  └──────────────┘  └──────────┘   │
└────────────────────────────────────┘

Yang dikerjakan Sidecar secara otomatis:

• Mutual TLS (mTLS) — semua komunikasi antar service dienkripsi dan diautentikasi
• Retry otomatis — coba lagi jika request gagal
• Circuit breaking — berhenti panggil service yang bermasalah
• Load balancing — distribusi traffic ke beberapa instance
• Distributed tracing — lacak request antar service
• Metrics — latency, error rate, throughput per service

Komponen Service Mesh:

Data Plane:
  Sidecar proxy (Envoy) di setiap pod — menangani traffic aktual

Control Plane:
  Mengkonfigurasi semua sidecar secara terpusat
  Contoh: Istio, Linkerd, Consul Connect

Konfigurasi traffic dengan Istio (declarative):

# Traffic shifting — canary deployment
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: order-service
spec:
  http:
  - route:
    - destination:
        host: order-service
        subset: v1
      weight: 90          # 90% ke versi lama
    - destination:
        host: order-service
        subset: v2
      weight: 10          # 10% ke versi baru (canary)

# Retry policy — otomatis di semua service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - retries:
      attempts: 3
      perTryTimeout: 2s
      retryOn: gateway-error,connect-failure

Keuntungan Service Mesh:

Kapan pakai Service Mesh:

• Sudah punya banyak microservice (> 10)
• Butuh keamanan zero-trust antar service
• Tim platform/infra yang bisa maintain-nya
• Running di Kubernetes

Jangan pakai untuk monolith atau sedikit service — overhead kompleksitas tidak sebanding.

Tools populer: Istio, Linkerd, Consul Connect, AWS App Mesh

🎭 Analogi sehari-hari: Service mesh = sopir bus + cleaning service di kantor. Karyawan (service) fokus kerjaan masing-masing. Sopir antar mereka ke meeting di kantor lain (routing), cleaning service jaga keamanan + cek ID (mTLS). Kalau sopir ganti rute (canary deploy), karyawan gak perlu tau detail.

💡 Service Mesh = ngangkat networking concerns dari aplikasi: Tanpa mesh, tiap service implement retry, mTLS, circuit breaker, tracing — duplicate code. Dengan mesh, semua di sidecar = aplikasi cuma fokus business logic.

⚠️ Jebakan klasik:

• Premature mesh adoption = kompleksitas Istio overkill untuk 5 service. Tunggu sampai >10 service
• Sidecar overhead = +1ms latency per call + memory tambahan per pod. Cek apakah worth it
• Learning curve curam — Istio config = beasiswa S2 tersendiri
• Debugging lebih susah = layer extra antara service. Wajib tracing
• Vendor lock-in = Istio config berbeda dari Linkerd

🎯 Service Mesh decision:

• Service ≤ 5 → no mesh (overkill)
• Service 5-15 + Kubernetes + dedicated platform team → Linkerd (simpler)
• Service 15+ + complex routing + multi-cluster → Istio (powerful)
• AWS native → AWS App Mesh
• No K8s → biasanya pakai library di app (Resilience4j, Hystrix)

TL;DR: Service Mesh = sidecar proxy (Envoy) handle networking concerns. mTLS, retry, circuit breaker, tracing built-in. Wajib K8s + tim platform. Jangan adopt premature — overhead kompleks. Istio (powerful), Linkerd (simple).