Service Mesh #

Saat microservice bertambah banyak, satu set masalah muncul secara konsisten: bagaimana memastikan komunikasi antar service aman (mTLS), bagaimana melacak request yang melintasi puluhan service (distributed tracing), bagaimana menerapkan circuit breaking dan retry tanpa mengubah kode setiap service? Service mesh menjawab semua ini dengan pendekatan yang elegan: tambahkan sidecar proxy ke setiap Pod yang menangani semua cross-cutting concern tanpa modifikasi kode aplikasi.

Konsep Dasar Service Mesh #

Service mesh terdiri dari dua lapisan:

Data plane:
  Sidecar proxy (biasanya Envoy) yang di-inject ke setiap Pod
  → Intercept semua traffic masuk dan keluar
  → Implementasikan mTLS, retry, circuit breaking, observability

Control plane:
  Komponen yang mengonfigurasi semua sidecar proxy
  → Distribusikan sertifikat TLS
  → Distribusikan konfigurasi routing
  → Kumpulkan telemetri dari semua proxy

Tanpa service mesh:
  Service A → HTTP → Service B (tidak terenkripsi)
  Tidak ada visibility siapa hubungi siapa

Dengan service mesh (Istio):
  Service A → Envoy A ─── mTLS ─── Envoy B → Service B
              │                    │
              └── report metrics   └── report metrics
              └── report traces         ke control plane

Fitur yang Disediakan Service Mesh #

Mutual TLS (mTLS) #

Setiap service mendapat identitas kriptografis. Semua komunikasi antar service dienkripsi dan diautentikasi tanpa perubahan kode:

Tanpa mTLS:
  Service A → HTTP → Service B
  Siapapun yang bisa intercept network bisa baca traffic

Dengan mTLS:
  Service A (cert: service-a.production) 
    ─── TLS 1.3 (terenkripsi + mutual auth) ───
  Service B (cert: service-b.production)

  Service B memverifikasi bahwa yang menghubunginya adalah
  memang Service A yang sah, bukan pod lain yang menyamar.

Traffic Management #

# Canary deployment: 90% traffic ke v1, 10% ke v2
# (Istio VirtualService)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-vs
spec:
  hosts:
  - api-service
  http:
  - route:
    - destination:
        host: api-service
        subset: v1
      weight: 90
    - destination:
        host: api-service
        subset: v2
      weight: 10

Fitur traffic management lainnya:

Retry otomatis — coba ulang request yang gagal
Circuit breaking — hentikan request ke service yang sedang bermasalah
Fault injection — inject delay atau error untuk testing resilience
Header-based routing — route ke service berbeda berdasarkan HTTP header

Observability #

Service mesh menghasilkan telemetri dari setiap request tanpa instrumentasi manual:

Setiap request menghasilkan:
  Metrics: latensi p50/p90/p99, error rate, request count
  Traces:  distributed trace yang menunjukkan path request
           melalui setiap service
  Logs:    access log dari setiap proxy

Visualisasi:
  Kiali (Istio):  service graph, traffic flow visualization
  Hubble (Cilium): real-time network flow
  Linkerd dashboard: service health at a glance

Perbandingan Service Mesh #

Istio #

Service mesh paling feature-rich, paling mature, dan paling kompleks.

Istio:
  Data plane:    Envoy proxy (otomatis di-inject via admission webhook)
  Control plane: istiod (menggabungkan pilot, citadel, galley)

  Pro:
  ✓ Fitur paling lengkap
  ✓ Komunitas terbesar, ekosistem kaya
  ✓ Kiali untuk service graph visualization
  ✓ Fine-grained traffic control

  Con:
  ✗ Overhead resource signifikan: setiap Pod tambah ~50-100MB RAM dan ~0.5 vCPU
  ✗ Kurva pembelajaran curam
  ✗ Debugging lebih kompleks (ada lapisan proxy di antara)
  ✗ Istio sendiri butuh beberapa GB RAM untuk control plane

Linkerd #

Dirancang dengan filosofi simplicity dan low overhead.

Linkerd:
  Data plane:    Linkerd2-proxy (ditulis dalam Rust, sangat ringan)
  Control plane: linkerd-control-plane

  Pro:
  ✓ Resource overhead jauh lebih rendah (~10MB per proxy vs ~50MB Envoy)
  ✓ Setup dan operasional lebih mudah
  ✓ Dashboard yang intuitif
  ✓ Zero-config mTLS

  Con:
  ✗ Fitur traffic management tidak selengkap Istio
  ✗ Tidak ada dukungan TCP/gRPC traffic splitting yang sefleksibel Istio
  ✗ Ekosistem lebih kecil

Cilium Service Mesh #

Berbeda dari Istio dan Linkerd — menggunakan eBPF di kernel, bukan sidecar proxy.

Cilium Service Mesh:
  Data plane:    eBPF (tanpa sidecar!)
  Control plane: Cilium control plane

  Pro:
  ✓ Tidak ada sidecar → tidak ada overhead per-Pod
  ✓ mTLS dan observability di level kernel
  ✓ Sudah bundled dengan Cilium CNI (tidak perlu install terpisah)
  ✓ Performa sangat baik

  Con:
  ✗ Fitur traffic management masih berkembang
  ✗ Butuh Cilium sebagai CNI (tidak bisa dipakai jika pakai Calico/Flannel)
  ✗ Lebih baru, maturitas lebih rendah dari Istio

Kapan Service Mesh Worth It #

Service mesh menambah kompleksitas yang signifikan. Pertanyaan paling penting: apakah manfaatnya sebanding?

Pertimbangkan service mesh jika:
  ✓ Punya lebih dari 10-15 microservice yang saling berkomunikasi
  ✓ Compliance requirement mengharuskan enkripsi in-transit (mTLS)
  ✓ Butuh distributed tracing tanpa instrumentasi manual di setiap service
  ✓ Tim yang mengelola platform berbeda dari tim yang menulis service
  ✓ Butuh canary deployment atau traffic splitting yang sophisticated
  ✓ Cluster multi-tenant dengan isolasi keamanan yang ketat

Jangan pakai service mesh jika:
  ✗ Kurang dari 10 service (overhead tidak sebanding)
  ✗ Tim kecil tanpa bandwidth untuk belajar dan maintain service mesh
  ✗ Startup yang butuh kecepatan iterasi — service mesh memperlambat debugging
  ✗ Semua service sudah implementasi mTLS sendiri
  ✗ Cluster development/staging yang sering berubah

Overhead yang Harus Diperhitungkan #

Overhead per Pod dengan Istio:
  RAM tambahan:   ~50-100MB per sidecar proxy
  CPU tambahan:   ~0.5 vCPU saat high traffic
  Latensi tambahan: 1-5ms per hop (dua proxy per request)

Contoh kalkulasi:
  Cluster 100 Pod
  Overhead: 100 × 75MB = 7.5GB RAM tambahan
           100 × 0.1 vCPU = 10 vCPU tambahan (saat idle)

  Plus overhead Istio control plane: 1-2GB RAM, beberapa vCPU

Total biaya tambahan bisa 20-30% dari total resource cluster.

Ringkasan #

Service mesh = cross-cutting concerns tanpa ubah kode — mTLS, observability, retry, circuit breaking ditangani sidecar proxy, bukan kode aplikasi.
Dua lapisan: data plane (proxy) dan control plane — sidecar proxy intercept traffic, control plane distribusikan konfigurasi dan sertifikat ke semua proxy.
Istio paling lengkap, Linkerd paling ringan, Cilium tanpa sidecar — pilih berdasarkan trade-off fitur, overhead, dan kompleksitas yang bisa ditoleransi.
Worth it di atas 10-15 service — di bawah itu, kompleksitas service mesh lebih besar dari manfaatnya; implementasi manual lebih simpel.
Overhead nyata: RAM, CPU, latensi — kalkulasi overhead sebelum adopsi; 100 Pod dengan Istio bisa butuh 7-10GB RAM ekstra dan 10+ vCPU tambahan.
Cilium service mesh tanpa sidecar — jika sudah pakai Cilium sebagai CNI, ini opsi yang menarik karena tidak ada overhead per-Pod.

← Sebelumnya: CNI Plugin Berikutnya: Ingress Controller Comparison →