Belajar Microservices - Production Checklist & Cost
Menyiapkan tokokita untuk produksi sesungguhnya: runbook deploy dan rollback per service, SRE metrics SLI/SLO dengan target availability yang berbeda per layanan, analisis ekonomi biaya operasional, dan disaster recovery dengan backup serta restore test rutin
#Pendahuluan
Tokokita sudah punya arsitektur, keamanan, observability, testing, dan otomasi. Episode ini menjawab pertanyaan paling netral dari semuanya: apa saja yang harus ada sebelum kita bilang "siap produksi", dan berapa biayanya? Karena microservices tidak hanya soal pola, melainkan juga soal kesiapan operasional dan batu ujian ekonomi — dua hal yang jarang dibahas di tutorial tapi selalu menentukan di dunia nyata.
#Runbook: Multi-Service Deploy yang Mudah & Rollback per Service
#Deploy Multi-Service
Di GitOps (episode 23), deploy satu service = satu PR manifest. Checklist runbook deploy produksi tokokita:
- Merge manifest ke
overlays/production→ Argo CD sync otomatis. - Pantau rollout:
rollout status, metrik RED (episode 20), HPA/KEDA (episode 21). - Smoke test endpoint kritikal:
/api/health, checkout mini. - Amati error budget (lihat SLI/SLO di bawah) selama ±30 menit.
#Rollback per Service
Rollback microservices seharusnya jauh lebih mudah daripada monolith — hanya satu service yang berubah, hanya itu yang dibalik:
Argo CD → History & Rollback → pilih revisi manifest sebelum commit → sync
(atau redeploy image tag semver sebelumnya)
→ konfirmasi via metrik/canary yang samaRunbook wajib menyimpan jawaban atas: siapa yang boleh rollback, keputusan kapan (error rate naik X%?, SLO terancam?), dan kontak on-call. Healthcheck publik (endpoint /api/health yang memeriksa seluruh dependency) juga bagian runbook — untuk status halaman di luar cluster.
#SRE Metrics: SLI, SLO per Service
SLI (Service Level Indicator) = ukuran. SLO (Service Level Objective) = target. Pilihannya disengaja berbeda antar layanan — bukan semua 99,99%:
| Service | SLI utama | SLO (availability) | Alasan |
|---|---|---|---|
| api-gateway | request success rate | 99.9% | permukaan terluas |
| product-service | read success + latency | 99.9% | dibaca sangat sering |
| order-service | order create success | 99.95% | transaksi uang/order |
| payment-service | payment success + idempotent | 99.95% | sensitif finansial |
| notification-service | email delivered | 99.5% | bisa toleran sesaat |
SLO 99.9% vs 99.95% bukan selisih kecil: 99.9% berarti 8,76 jam downtime setahun, sedangkan 99.95% hanya 4,38 jam. Error budget adalah toleransi downtime yang tersisa; begitu terpakai habis, waktunya fokus pada perbaikan reliabilitas, bukan fitur baru.
availability tahunan 99.9% → budget error 8,76 jam/tahun
terpakai semua di Q1 → setuju berhenti rilis fitur & fokus kestabilan#Cost: Ekonomi per Service
Microservices membawa biaya yang kadang luput dihitung:
#Biaya Nyata yang Harus Diakui
- Runtime overhead — 7 service = 7 set pod, 7 image registry, 7 pipeline CI, 7 dashboard. Setiap service "kecil" tetap membayar biaya tetap ini.
- Observability — log, metrics, traces 7x lipat. Data observability bisa jadi komponen biaya terbesar kedua setelah compute.
- Operasional manusia — on-call melintasi 7 layanan, runbook 7 kali lebih banyak.
#Mitigasi yang Disengaja
service X: request/mo, latency p95, resource request/limit
→ underutilized + tidak pernah diskala → kandidat penggabungan
Lakukan dengan yakin saat: traffic kecil, domain saling dekat, tim samaKeputusan bisnis murni: jika penggabungan cart-service ke order-service menghemat 2 pod + 1 pipeline tanpa merugikan domain, lakukan. Microservices bukan maksim "pisahkan semua"; pegangannya adalah: pecahlah bila domain, tim, dan volume menuntut — dan gabungkan kembali saat tidak.
Note
Klasik dan benar: modular monolith boleh menjadi jawaban akhir, bukan kegagalan. Penggabungan yang benar bukan membalik ke arsitektur berantakan, melainkan menyatukan batas yang ternyata memang satu domain. Di episode 27 kita bahas skenario penggabungan cart + order secara konkret.
#DR / Backup
Data tokokita tersebar di tujuh database. Rencana recovery wajib:
- Snapshot berkala — PostgreSQL
pg_basebackup/managed backup; file di object storage. - Volume backup — velero mem-backup seluruh namespace K8s (manifest + PVC snapshot).
- Restore test rutin — ini bagian yang paling sering dilewatkan dan justru paling penting. "Backup berjalan" ≠ "restore berhasil".
velero backup create tokokita-daily --include-namespaces tokokita
velero restore create --from-backup tokokita-daily
kubectl -n tokokita exec deploy/order-service -- sh -c 'bun restore-check' # validasi RPO/RTOSasaran DR yang sehat: RPO (berapa banyak data boleh hilang — misal 15 menit) dan RTO (berapa lama pulih — misal 4 jam). Keduanya diukur dan ditulis; tidak diukur sama dengan tidak punya.
#Penutup
Episode 24 menyiapkan tokokita untuk produksi sesungguhnya:
- Runbook: deploy multi-service mudah via GitOps; rollback per service cepat; healthcheck publik.
- SLI/SLO per service — 99.9% API vs 99.95% order/payment; error budget yang dikelola.
- Biaya didata: runtime overhead, observability, on-call — dan penggabungan layanan kecil yang wajar.
- DR: snapshot, velero, restore test rutin dengan RPO/RTO tertulis.
Di episode 25 selanjutnya, giliran teknologi paling hangat 2026: Dapr — standard runtime untuk microservices dengan building blocks state, pub/sub, service invocation, bindings, dan secrets; deklaratif, bahasa-agnostik, dan portabel antar cloud. Sampai jumpa di episode 25!