Belajar Microservices - Platform Engineering & AIOps

#Pendahuluan

Sampai episode 25 kita membangun sistem. Episode 26 menanyakan pertanyaan yang lebih langka: bagaimana kalau tim tumbuh dari 3 menjadi 30 orang dan layanan dari 7 menjadi 50? Pada titik itu, microservices tidak lagi soal kode — melainkan soal bagaimana sebuah organisasi bisa mengkloning praktik yang sudah kita tulis 26 episode ini tanpa kehilangan kualitas.

Dua gelombang modern menjawabnya: platform engineering (membuat jalur aman agar developer tidak perlu memikirkan infrastruktur) dan AIOps (menggunakan AI untuk menganalisis sinyal operasional yang sudah melimpah). Keduanya adalah arah 2026 yang membuat tokokita layak bertahan.

#Internal Developer Platform (IDP)

Inti masalahnya: 50 layanan yang masing-masing bisa di-deploy berarti 50 cara deploy yang berbeda. Internal Developer Platform memusatkan "jalur emas" (golden path) agar developer tidak perlu tahu caranya — cukup terapkan template.

#Golden Path

Golden path adalah template dan pipeline yang disetujui tim platform:

• Template service: struktur monorepo standar + shared-types/client-db + Dockerfile + K8s manifest + pipeline CI.
• Observability default: Prometheus scrape, trace OTLP, log structured, semuanya sudah terpasang sejak lahir.
• Gateway & ingress terisi otomatis — service baru langsung terdaftar, bukan copy-paste manual.

Hasilnya: seorang backend engineer membuat service baru dari template dalam hitungan menit, bukan hari. Semua guardrail (slo, security, observability) tertanam sejak awal — bukan ditambal setelah insiden.

bun create @tokokita/service   → skaffold service baru
  ├── struktur monorepo + CI (path-filtering otomatis)
  ├── Deployment + Service + HPA + KEDA + NetworkPolicy
  └── dashboard Grafana + SLO di service catalog

#Service Catalog: Backstage

Backstage (CNCF, asal Spotify) menjadi service catalog — satu tempat melihat semua layanan, owner-nya, dokumentasinya, API-nya, dan statusnya. Di sinilah informasi yang tersebar di 20 episode (owner per service, endpoints, SLO, on-call) dikonsolidasikan. Service catalog mengubah "siapa yang punya service ini?" dari tebak-tebakan menjadi jawaban satu klik.

#AIOps: Deteksi Anomali & Analisis Log

Dengan 50 layanan, mustahil manusia memantau setiap dashboard. AIOps memanfaatkan AI untuk dua pekerjaan paling melelahkan: mendeteksi anomali dan menelusuri log saat insiden.

#Deteksi Anomali dari Metrics

Alih-alih menulis 200 alert rules statis (dan mengabaikannya setelah alarm fatigue), model mempelajari pola normal tiap metrik lalu memberi sinyal penyimpangan:

p99 order-service naik 3x dari baseline selama 10 menit (sebelumnya normal)
→ model mengangkat "kemungkinan regresi" — bukan menunggu alert manual

Alert rules statis tetap ada untuk hal yang deterministik (SLO break, lag KEDA); AI melengkapi dengan deteksi yang tidak ter-manageable oleh threshold manual.

#LLM untuk Analisis Log dan Korelasi

Saat anomali terdeteksi, kini ada asisten yang merangkum log/trace lintas layanan: "error meningkat di order-service dimulai 14:02, bertepatan dengan deploy v1.4.3 yang menyentuh finalisasi order; trace menunjukkan panggilan ke product-service gagal dengan timeout; indikasi: regresi pada validasi stok."

Ini bukan magic — LLM bekerja di atas struktur yang sudah kita bangun: structured logs (episode 20) sebagai material, trace sebagai konteks, dan runbook sebagai pengetahuan sebelumnya.

#Self-Healing: Auto-Rollback on Error Rate

Lompatan berikutnya setelah observability (episode 20) dan GitOps (episode 23): membuat sistem menyehatkan diri sendiri untuk kelas kegagalan yang deterministik.

deploy canary 5% → error rate merah 10 menit → auto-rollback ke revisi sebelumnya
   (Argo Rollouts / release pipeline memberlakukan gate)
→ dashboard melaporkan "rollback otomatis karena error rate" + trace tersedia untuk analisis

Auto-rollback bekerja hanya saat tanda tangan kegagalan deterministik (5xx spike, SLO terancam, di canary). Distributed tracing menjadi bukti gigi yang berharga di sini: setelah rollback, engineer membuka trace dari menit kegagalan dan masuk ke episode 20 alur insiden dengan data, bukan tebakan.

#Feature Flags & Gradual Rollout

Tidak semua risiko bisa diringkas ke "deploy". Feature flags memisahkan deploy kode dari pengiriman fitur: kode ter-deploy, fitur di-hidupkan belakangan (atau untuk segmen tertentu) lewat toggle. Untuk rilis lintas service yang risiko kamu takutkan, ini adalah penyangga yang paling fleksibel:

import { getFlag } from '../flags'
 
export const isCheckoutV2 = getFlag('checkout.v2')   // dari provider flag
 
export const createOrderHandler = (req) =>
  isCheckoutV2 ? createOrderV2(req) : createOrderV1(req)

Penerapan bijak di microservices:

• Daur hidup: flag di-hidupkan bertahap (1% → 50% → 100%) lalu dihapus setelah stabil — flag yang mengendap menumpuk utang teknis.
• Kill switch: fitur baru yang bermasalah tinggal di-off tanpa rollback — menyelamatkan vs mustahilnya rollback cepat pada lintas service.
• Awas fenomena flags²: terlalu banyak flag = variabel konfigurasi lain; tetapkan pemilik dan TTL tiap flag.

#Penutup

Episode 26 membangun organisasi yang men-skalakan tokokita:

• IDP & golden path: template service + observability default + guardrail dari lahir.
• Backstage: service catalog — owner, API, SLO, on-call satu tempat.
• AIOps: deteksi anomali metrik; LLM meringkas log/trace sebagai hipotesis + bukti — engineer memutuskan.
• Self-healing: auto-rollback pada error rate deterministik; tracing jadi basis investigasi.
• Feature flags: deploy ≠ rilis; gradual rollout 1%→100%; hapus flag yang sudah selesai.

Di episode 27 — episode pamungkas — kita akan studi kasus & refleksi final tokokita dalam produksi: arsitektur akhir lengkap, simulasi skenario kegagalan (payment down, Kafka down, canary deploy), optimasi penggabungan layanan, dan roadmap ke depan dari modular monolith sampai Dapr workflow. Sampai jumpa di episode 27!