Belajar Cloud Engineer - Microservices & Service Mesh on Cloud

#Pendahuluan

Sampai episode 11, kita membangun satu aplikasi utuh. Di episode 12 ini kita memecahnya — dan inilah titik di mana cloud engineer modern menghabiskan banyak waktunya: microservices. Aplikasi tidak lagi satu monolit besar, melainkan kumpulan service kecil (auth, orders, payments, notifications) yang dikembangkan, di-deploy, dan di-scale secara independen.

Episode 12 membahas prinsip microservices, tantangannya di cloud, service discovery dan observability lintas service, lalu pengenalan service mesh (Istio/Linkerd) — lapisan infrastruktur yang menangani lalu lintas antar-service, mTLS, dan tracing tanpa mengubah kode aplikasi.

#Prinsip Microservices

#Mengapa dipecah, Mengapa tidak

Monolit sederhana di awal, tapi saat tim besar dan fitur banyak, setiap rilis berisiko tinggi (semua harus naik bareng) dan scaling boros (semua dinaikkan padahal hanya satu modul yang sibuk). Microservices memecahkan itu — setiap service bisa dirilis, di-scale, dan punya teknologi sendiri — tetapi dengan biaya: kompleksitas jaringan, distribusi, dan debugging yang lebih tinggi.

Aturan yang perlu kalian internalisasi sejak sekarang: jangan pecah microservices sebelum kebutuhan memaksa. Banyak tim memecah aplikasi 5.000 baris menjadi 20 service dan membayar kompleksitas yang tidak perlu. Pola yang benar: mulai monolit modular, pecah satu per satu saat beban atau tim membutuhkan.

#Bounded Context dan Komunikasi

Setiap microservice punya boundary yang jelas (bounded context) — misal service orders hanya mengelola data pesanan, tidak boleh menyentuh tabel user langsung. Komunikasi antar-service:

• Synchronous — HTTP/gRPC: cocok untuk request-response langsung.
• Asynchronous — message queue/event: untuk decoupling (episode 13).

#Deploy Microservices di Cloud

Di Kubernetes, setiap service adalah workload + service-nya sendiri:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
  namespace: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: orders
  template:
    metadata:
      labels:
        app: orders
    spec:
      containers:
        - name: orders
          image: registry.example.com/orders:1.4.0
          ports:
            - containerPort: 8080
          env:
            - name: DB_HOST
              value: orders-db.internal
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: orders
  namespace: shop
spec:
  selector:
    app: orders
  ports:
    - port: 8080
      targetPort: 8080

Perhatikan dua hal penting:

1. Namespaces (namespace: shop) — memisahkan environment/dept dalam satu cluster.
2. Readiness probe — Kubernetes hanya mengirim traffic ke pod yang sehat. Tanpa probe, request bisa diarahkan ke pod yang belum siap.

#Service Discovery

Bagaimana service checkout menemukan orders? DNS internal Kubernetes menyelesaikan nama service: orders.shop.svc.cluster.local. Kalian tidak menulis IP statis — cukup nama. Ini service discovery: lokasi service didaftarkan dan dicari secara otomatis.

curl http://orders.shop.svc.cluster.local:8080/health

Di luar Kubernetes, provider punya solusi masing-masing: AWS Cloud Map, GCP Service Directory, Azure service registry. Konsepnya sama — daftar terpusat yang bisa dicari oleh service lain.

#Observability Lintas Service

Satu request melintasi banyak service; log di tiap service tidak lagi cukup. Dibutuhkan:

• Distributed tracing — satu trace ID mengikuti request dari edge sampai database; setiap service mencatat span-nya. Tool: X-Ray (AWS), Cloud Trace (GCP), Application Insights (Azure), atau OpenTelemetry (episode observability).
• Correlation ID — id yang sama di semua log satu request, supaya bisa di-query lintas service.

Prinsipnya sederhana: setiap service meneruskan header trace (misal x-trace-id) ke service berikutnya dan mencatatnya di log. Dengan begitu, satu ID bisa menelusuri seluruh perjalanan request.

#Service Mesh: Istio dan Linkerd

Ketika jumlah service dan trafik antar-service membengkak, menangani retry, timeout, mTLS, dan metrics di setiap service menjadi tidak efisien. Service mesh memindahkan semua itu ke lapisan infrastruktur: sebuah sidecar proxy (Envoy) disuntikkan ke setiap pod, dan control plane mengatur perilaku semua sidecar secara terpusat.

┌───────────── pod ─────────────┐
│  [app container]              │
│  [sidecar Envoy] ──↔── mesh   │  ← semua traffic keluar-masuk lewat sidecar
└───────────────────────────────┘

#Yang Disediakan Service Mesh

Contoh: memaksa semua traffic antar-service menggunakan mTLS (encrypted + mutual auth) dan melakukan canary 10% traffic ke versi baru — tanpa mengubah kode sama sekali:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: shop
spec:
  mtls:
    mode: STRICT
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: orders
  namespace: shop
spec:
  hosts:
    - orders
  http:
    - route:
        - destination:
            host: orders
            subset: v1
          weight: 90
        - destination:
            host: orders
            subset: v2
          weight: 10

Managed options di cloud: AWS App Mesh, GCP Traffic Director / Anthos Service Mesh, Azure Service Mesh (Istio/Open Service Mesh). Untuk sekarang, cukup pahami masalah apa yang dipecahkan mesh; implementasi detailnya ada di episode 19 (zero trust & mTLS).

#Praktik: Microservices di Cloud

Kerjakan bertahap di cluster kalian:

1. Deploy dua service: orders (kode di atas) dan checkout yang memanggil orders via DNS service.
2. Verifikasi discovery: dari pod checkout, curl http://orders.shop.svc.cluster.local:8080/healthz.
3. Pasang readiness probe di kedua service; buktikan traffic berhenti saat probe gagal.
4. Tambahkan correlation ID di log kedua service; telusuri satu request lintas service.
5. (Opsional, lanjutan) Install Istio di cluster dan aktifkan mTLS STRICT + canary 90/10.

#Kesalahan Umum (Common Pitfalls)

1. Memecah tanpa kebutuhan — membayar kompleksitas untuk aplikasi kecil.
2. Service saling terkait langsung — tidak ada boundary; ubah satu memaksa ubah yang lain.
3. Tanpa readiness probe — traffic diarahkan ke pod rusak.
4. Log tanpa correlation ID — tidak bisa menelusuri request lintas service.
5. Semua komunikasi sync — chain HTTP yang panjang = latency & kegagalan berantai; campur dengan async (episode 13).

#Penutup

Inti yang harus dibawa pulang:

• Microservices = service kecil, independen, dengan boundary jelas; jangan dipecah sebelum kebutuhan memaksa.
• Service discovery membuat service saling menemukan via nama, bukan IP statis.
• Distributed tracing & correlation ID adalah syarat mutlak saat service > 1.
• Service mesh (Istio/Linkerd) memindahkan mTLS, retry, canary ke lapisan infrastruktur — kuat, tapi tidak gratis; pasang saat dibutuhkan.
• Managed mesh di cloud: App Mesh, Traffic Director, Azure Service Mesh.

Di episode 13 selanjutnya kita akan membahas message queues & streaming — SQS/SNS, Pub/Sub, Kinesis/Event Streaming — dan membangun event-driven pipeline yang menghubungkan microservices secara asynchronous. Sampai jumpa di episode 13!