Belajar KEDA - Ekosistem Alternatif & Refleksi Akhir

#Pendahuluan

Di episode 21 sebelumnya kalian menyiapkan arsitektur produksi lengkap. Kini tibalah episode terakhir — episode 22 — penutup perjalanan 23 episode dari episode 0 sampai 22. Sebelum menutup, ada satu pertanyaan yang layak dijawab dengan jujur: di tengah banyaknya solusi autoscaling, kenapa KEDA, dan kapan solusi lain lebih tepat?

Episode ini berjalan dalam empat bagian: membandingkan solusi autoscaling, merekap seluruh perjalanan, menyusun decision framework untuk 2026, dan melihat arah evolusi KEDA. Ini bukan sekadar rangkuman — ini cara kalian memutuskan kapan KEDA dipakai, kapan tidak, dan apa yang harus dipelajari selanjutnya.

#Perbandingan Solusi Autoscaling

Empat pendekatan paling umum di ekosistem Kubernetes 2026:

#Kapan Memilih Masing-masing

• HPA murni — jika workload didorong utilisasi CPU/memori yang stabil (API biasa, worker padat compute) dan kalian tidak butuh scale-to-zero. Murah, teruji, tidak ada komponen baru.
• Prometheus adapter — jika organisasi sudah serius dengan Prometheus dan ingin skala dari metrik bisnis yang sudah ada tanpa pindah mental ke event source. Cocok untuk metrik aplikasi, bukan queue eksternal.
• KEDA — jika metrik datang dari queue, stream, message broker, atau jadwal (cron), dan kalian butuh scale-to-zero dengan 70+ integrasi siap pakai. Ini tema seluruh seri.
• Knative autoscaling — jika workload berbasis HTTP request dan kalian butuh scale-to-zero otomatis dengan kontrol concurrency per pod; sering dipakai untuk platform serverless internal.

Kuncinya bukan "mana yang terbaik", melainkan "mana yang paling cocok dengan bentuk beban". KEDA dan Knative bahkan bisa berdampingan — KEDA menangani bagian event-driven, Knative menangani permintaan HTTP (seperti disinggung di episode 17).

#Catatan Perbandingan

Perlu diingat, keempat solusi ini berbeda lapisan, bukan hanya berbeda merek. HPA murni dan Prometheus adapter adalah sumber metrik sekaligus mekanisme skala; KEDA adalah lapisan di atas HPA yang memilih dan mengelola metrik event; sedangkan Knative membawa runtime sendiri untuk workload-nya. Karena itu kalian bisa mengombinasikannya — yang umum dilakukan adalah KEDA sebagai penggerak, HPA sebagai eksekutor, dan Karpenter sebagai penyedia kapasitas.

#Rekap Perjalanan: 23 Episode

Perjalanan ini terbagi dalam enam fase. Berikut peta lengkapnya:

Dari episode 0 yang menyiapkan environment sampai episode 22 ini, kalian telah menempuh semua aspek: mengapa event-driven scaling ada, cara kerja operator dan metrics server, puluhan jenis scaler, keamanan, biaya, sampai kesiapan produksi.

#Keterampilan yang Sudah Kalian Miliki

• Membaca dan menulis ScaledObject, ScaledJob, TriggerAuthentication, dan ClusterTriggerAuthentication tanpa membuka dokumentasi.
• Menganalisis arsitektur autoscaling: kapan scale-to-zero aman, kapan perlu min replica, kapan fallback wajib.
• Mendiagnosis masalah autoscaling dari status CRD, log operator, dan metrics keda_scaler_*.
• Menyusun strategi biaya: idle replica, Karpenter dengan spot dan konsolidasi, serta tuning polling dan cooldown.
• Menilai solusi autoscaling secara objektif — keterampilan yang kini kalian gunakan di episode ini.

#Decision Framework Autoscaling 2026

Saat menghadapi workload baru di 2026, ikuti alur keputusan ini:

1. Apakah sumber beban berupa event atau queue? Ya ke KEDA. Ini kasus klasik: SQS, Kafka, RabbitMQ, Redis Streams, Azure Service Bus, GCP Pub/Sub.
2. Butuh scale-to-zero? Ya ke KEDA (non-HTTP) atau Knative (HTTP request). Tidak, lanjut ke pertanyaan berikutnya.
3. Cukup diukur dari CPU atau memori? Ya ke HPA murni — jangan menambah kompleksitas.
4. Metrik bisnis sudah ada di Prometheus? Ya ke Prometheus adapter, atau langsung KEDA dengan scaler prometheus jika nanti butuh scale-to-zero.
5. Campuran banyak sumber? KEDA mendukung multi-trigger dalam satu ScaledObject (episode 10), sehingga menjadi pilihan paling fleksibel.
6. Cluster butuh node tambahan saat skala? Tambahkan Karpenter (episode 16) terlepas dari solusi pod-scaling yang dipilih.

# Kapan harus memilih
hpa murni          # CPU/memori stabil, tanpa scale-to-zero
prometheus-adapter # metrik bisnis Prometheus, tanpa scale-to-zero
keda               # event, queue, stream, cron, scale-to-zero
knative            # HTTP request, concurrency, scale-to-zero

Gunakan alur ini sebagai checklist bersama tim: menulis alasan pemilihan di dokumen keputusan arsitektur akan menyelamatkan kalian setahun kemudian saat ada yang bertanya kenapa memilih KEDA untuk workload tertentu.

#Arah Evolusi KEDA: v3 dan AI/GPU

#Roadmap v3

Seperti dibahas di episode 20, KEDA bersiap menuju v3 dengan fondasi yang ditulis ulang: metrics server baru yang lebih andal, SDK scaler modular agar kontribusi komunitas lebih mudah, multi-tenancy yang lebih tegas, dan integrasi yang lebih mulus dengan ekosistem scale-from-zero. Konsep yang kalian pelajari — ScaledObject, trigger, authentication — tetap menjadi bahasa inti, sehingga keterampilan kalian tidak usang.

#AI/GPU Workloads

Salah satu arah pertumbuhan paling menarik adalah workload AI/GPU. Polanya natural untuk KEDA: antrean job inference diisi request, KEDA menskalakan worker GPU berdasarkan panjang antrean, dan Karpenter menyediakan node GPU (termasuk spot) saat beban naik lalu mengonsolidasikannya saat turun. Fallback dan min replica (episode 11 dan 15) menjaga model kritis tetap punya kapasitas, sementara scale-to-zero menekan biaya GPU yang mahal saat tidak ada permintaan.

Ini tema yang terus berkembang — dokumentasi keda.sh dan repo kedacore/keda adalah tempat terbaik untuk memantau scaler baru di ekosistem ini.

#Rekomendasi Langkah Selanjutnya

Perjalanan tidak berhenti di sini. Beberapa jalur yang bisa kalian tempuh:

• Bangun proof of concept — pilih satu queue (SQS atau RabbitMQ) dan pasang KEDA lengkap dengan Karpenter, lalu ukur latensi scale-up seperti di episode 19.
• Terapkan GitOps — masukkan seluruh konfigurasi KEDA ke ArgoCD atau Flux sesuai episode 21, dan jadikan CRD bagian dari pipeline.
• Perdalam observability — buat dashboard Grafana untuk metrics keda_scaler_* dan pasang alert pada keda_scaler_errors_total.
• Ikuti komunitas — changelog GitHub kedacore/keda dan catatan rilis di keda.sh memberi gambaran awal tentang perubahan yang akan datang di v3.

#Penutup

Episode ini menutup seri: perbandingan empat solusi autoscaling (HPA murni, Prometheus adapter, KEDA, Knative) beserta kapan memilih masing-masing, rekap 23 episode dalam enam fase, decision framework autoscaling 2026, serta arah evolusi KEDA v3 dan workload AI/GPU.

Poin yang harus kalian bawa:

• Tidak ada solusi autoscaling terbaik secara mutlak — ada solusi yang paling cocok dengan bentuk beban.
• KEDA adalah pilihan utama untuk event, queue, stream, dan scale-to-zero.
• Decision framework membantu menjawab pertanyaan arsitektur dengan konsisten.
• Karpenter melengkapi solusi pod-scaling apa pun yang dipilih.
• Roadmap v3 dan AI/GPU adalah dua alasan kuat untuk terus mengikuti proyek ini.

Dari episode 0 sampai 22, kalian telah menempuh perjalanan lengkap: memahami mengapa event-driven autoscaling ada, membangun dan mengoperasikan KEDA, menguasai puluhan scaler, mengamankan dan mengoptimalkan biaya, menyiapkan produksi, sampai melihat masa depannya. Kalian tidak lagi bertanya "bagaimana cara pakai KEDA", melainkan "kapan dan mengapa". Itulah tanda bahwa kalian memahami autoscaling event-driven secara utuh. Selamat — dan sampai jumpa di seri berikutnya!