Belajar Platform Engineer - Service Mesh & Networking

#Pendahuluan

Setelah di episode 7 kita memastikan kode mengalir dari build ke deploy dengan pipeline yang konsisten, sekarang kode itu harus berkomunikasi satu sama lain. Di platform dengan ratusan service, komunikasi antar-service bukan sekadar masalah DNS — ia masalah keamanan (mTLS), keandalan (retry, timeout), dan observability (traces). Service mesh adalah jawaban platform engineering untuk masalah ini.

Mengapa service mesh relevan di 2026? Karena aplikasi sudah terbagi menjadi banyak microservice, dan mengimplementasikan retry, mTLS, dan distributed tracing di setiap service — di setiap bahasa — adalah beban yang tidak bisa ditanggung developer. Service mesh memindahkan beban ini ke data plane dan control plane yang dikelola platform team.

#Apa Itu Service Mesh?

Service mesh adalah infrastruktur dedicated untuk menangani komunikasi service-to-service. Ia terdiri dari dua bagian:

• Data plane — proxy yang berada di samping setiap service (sidecar), memproses semua traffic masuk/keluar. Dalam Istio ini adalah Envoy.
• Control plane — otak yang mengatur kebijakan proxy. Di Istio: istiod; di Linkerd: linkerd-controller.

Yang terpenting: aplikasi tidak tahu keberadaan mesh. Service tetap memanggil service lewat HTTP biasa — proxy yang mengurus mTLS, retry, dan telemetry secara transparan.

#Istio vs Linkerd

Dua pilihan utama di ekosistem CNCF, dengan filosofi berbeda:

Untuk series ini kita pakai Istio sebagai contoh utama karena fiturnya paling lengkap; konsep yang sama berlaku di Linkerd.

#mTLS: Enkripsi Antar-Service

Fitur paling penting service mesh dari sisi keamanan adalah mutual TLS (mTLS) — dua arah: client dan server sama-sama membuktikan identitas lewat sertifikat. Ini berbeda dari TLS biasa yang hanya memverifikasi server.

Di Istio, mTLS diaktifkan secara mesh-wide dengan permissive mode dulu (agar service lama tidak rusak), lalu strict:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Dengan STRICT, semua traffic antar-service diwajibkan memakai mTLS. Ini adalah fondasi zero trust yang akan kita perdalam di episode 18. Keuntungan lain: sertifikat yang dikeluarkan istiod membuat identitas service dapat diverifikasi — dasar untuk authorization antar-service (yang mana boleh bicara dengan yang mana).

#Traffic Management: Canary dan Weighted Routing

Di sinilah service mesh menunjukkan kekuatan yang tidak dimiliki mekanisme Kubernetes standar. Ingress standard bisa load balance antar Pod, tapi tidak bisa mengarahkan persentase trafik antar versi dengan mudah.

#Canary Deployment

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: payments-api
  namespace: team-payments-prod
spec:
  hosts:
    - payments-api
  http:
    - route:
        - destination:
            host: payments-api
            subset: v1
          weight: 90
        - destination:
            host: payments-api
            subset: v2
          weight: 10

Dengan weight: 90/10, 10% trafik diarahkan ke versi baru (v2). Platform team bisa menaikkan secara bertahap: 10% → 50% → 100%, sambil memantau error rate dan latency dari telemetry mesh.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: payments-api
  namespace: team-payments-prod
spec:
  host: payments-api
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

#Timeout dan Retry

Pola reliability yang dipindahkan dari kode aplikasi ke mesh:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: payments-api
  namespace: team-payments-prod
spec:
  hosts:
    - payments-api
  http:
    - timeout: 3s
      retries:
        attempts: 3
        perTryTimeout: 1s
        retryOn: connect-failure,5xx
      route:
        - destination:
            host: payments-api

Catatan penting: timeout aplikasi tetap dibutuhkan — timeout di mesh dan di aplikasi harus dikoordinasikan (timeout client lebih pendek dari server, dst), jika tidak kalian mendapat error yang misterius.

#Gateway: Pintu Masuk Trafik

Istio Gateway menggantikan kebutuhan ingress controller terpisah untuk kebutuhan routing tingkat lanjut:

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*.apps.example.com"
      tls:
        mode: SIMPLE
        credentialName: apps-tls-cert

Gateway + VirtualService membentuk lapisan routing platform yang konsisten: semua service dipublish dengan pola DNS yang seragam ({service}.apps.example.com), TLS otomatis, dan kebijakan yang sama.

#Observability Jaringan dari Mesh

Bonus besar service mesh: telemetry otomatis. Karena semua traffic melewati proxy, mesh menghasilkan metrics (traffic, latency, error), traces (distributed tracing antar service), dan access logs tanpa aplikasi diubah sama sekali.

Ini adalah jalur langsung ke episode 9 (observability platform) — mesh sudah menyediakan data, observability stack tinggal memvisualisasikannya.

#Common Pitfalls

1. Mesh tanpa observability — memasang mesh hanya untuk mTLS menyia-nyiakan data telemetry-nya.
2. Canary tanpa metrik — routing 10% tanpa memantau error berarti 10% pengguna jadi kelinci percobaan buta.
3. Timeout mesh vs aplikasi tidak sinkron — kombinasi timeout yang salah menghasilkan error yang sulit ditelusuri.
4. mTLS STRICT langsung — memutus service lama yang tidak punya sidecar.
5. Lupa service tanpa sidecar — service yang tidak masuk mesh (misal karena label selector salah) menjadi "lubang" di kebijakan.

#Penutup

Inti yang harus dibawa pulang:

• Service mesh = data plane (proxy) + control plane; aplikasi tetap tak sadar keberadaannya.
• mTLS adalah fondasi keamanan antar-service; aktifkan bertahap PERMISSIVE → STRICT.
• Canary dengan VirtualService weight memungkinkan release bertahap yang aman.
• Telemetry mesh adalah sumber observability jaringan yang otomatis.

Di episode 9 selanjutnya kita membangun observability platform — Prometheus/Grafana untuk metrics, Loki untuk logs, Tempo untuk traces, dan OpenTelemetry sebagai standar data — yang mengubah data mentah dari mesh, pipeline, dan Kubernetes menjadi pengertian yang bisa ditindaklanjuti!