Learn KEDA - Alternative Ecosystem & Final Reflection

#Introduction

In the previous episode, 21, you set up a complete production architecture. Now it's time for the final episode — episode 22 — the close of a 23-episode journey from episode 0 to 22. Before closing, there's one question worth answering honestly: amid the many autoscaling solutions, why KEDA, and when is another solution more appropriate?

This episode runs in four parts: comparing autoscaling solutions, recapping the whole journey, building a decision framework for 2026, and looking at KEDA's evolution. This isn't just a summary — it's how you decide when KEDA is used, when it isn't, and what to learn next.

#Comparing Autoscaling Solutions

The four most common approaches in the 2026 Kubernetes ecosystem:

#When to Choose Each

• Pure HPA — if the workload is driven by stable CPU/memory utilization (typical APIs, compute-heavy workers) and you don't need scale-to-zero. Cheap, battle-tested, no new components.
• Prometheus adapter — if your organization is already serious about Prometheus and wants to scale from existing business metrics without shifting your mindset to event sources. Good for application metrics, not external queues.
• KEDA — if metrics come from queues, streams, message brokers, or schedules (cron), and you need scale-to-zero with 70+ ready-made integrations. That's the theme of this whole series.
• Knative autoscaling — if the workload is HTTP request-based and you need automatic scale-to-zero with per-pod concurrency control; often used for internal serverless platforms.

The key isn't "which is the best", but "which best fits the shape of the load". KEDA and Knative can even coexist — KEDA handles the event-driven part, Knative handles HTTP requests (as touched on in episode 17).

#A Note on the Comparison

Remember that these four solutions differ in layer, not just brand. Pure HPA and the Prometheus adapter are both metric sources and scaling mechanisms; KEDA is a layer above HPA that selects and manages event metrics; while Knative brings its own runtime for its workloads. That's why you can combine them — the common setup is KEDA as the driver, HPA as the executor, and Karpenter as the capacity provider.

#Journey Recap: 23 Episodes

This journey is divided into six phases. Here's the complete map:

From episode 0, which prepared the environment, to this episode 22, you've covered every aspect: why event-driven scaling exists, how the operator and metrics server work, dozens of scaler types, security, cost, and production readiness.

#Skills You Now Have

• Reading and writing ScaledObject, ScaledJob, TriggerAuthentication, and ClusterTriggerAuthentication without opening the docs.
• Analyzing autoscaling architecture: when scale-to-zero is safe, when min replicas are needed, when fallback is mandatory.
• Diagnosing autoscaling problems from CRD status, operator logs, and keda_scaler_* metrics.
• Building cost strategies: idle replicas, Karpenter with spot and consolidation, and polling and cooldown tuning.
• Evaluating autoscaling solutions objectively — the skill you're now using in this episode.

#Autoscaling Decision Framework 2026

When faced with a new workload in 2026, follow this decision flow:

1. Is the load source an event or queue? Yes → KEDA. This is the classic case: SQS, Kafka, RabbitMQ, Redis Streams, Azure Service Bus, GCP Pub/Sub.
2. Need scale-to-zero? Yes → KEDA (non-HTTP) or Knative (HTTP requests). No → move to the next question.
3. Is CPU or memory measurement enough? Yes → pure HPA — don't add complexity.
4. Are business metrics already in Prometheus? Yes → the Prometheus adapter, or KEDA directly with the prometheus scaler if you later need scale-to-zero.
5. A mix of many sources? KEDA supports multi-trigger in a single ScaledObject (episode 10), making it the most flexible choice.
6. Does the cluster need extra nodes when scaling? Add Karpenter (episode 16) regardless of the pod-scaling solution chosen.

# 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

Use this flow as a checklist with your team: writing the reasoning in an architecture decision record will save you a year from now when someone asks why KEDA was chosen for a particular workload.

#KEDA's Evolution: v3 and AI/GPU

#v3 Roadmap

As discussed in episode 20, KEDA is preparing for v3 with a rewritten foundation: a new, more reliable metrics server, a modular scaler SDK so community contributions are easier, firmer multi-tenancy, and smoother integration with scale-from-zero ecosystems. The concepts you learned — ScaledObject, trigger, authentication — remain the core language, so your skills don't go stale.

#AI/GPU Workloads

One of the most exciting growth directions is AI/GPU workloads. The pattern is natural for KEDA: an inference job queue fills with requests, KEDA scales GPU workers based on queue length, and Karpenter provides GPU nodes (including spot) as load rises and consolidates them when it drops. Fallback and min replicas (episodes 11 and 15) keep critical models with capacity, while scale-to-zero pushes down the expensive GPU cost when there's no demand.

This is a continuously evolving theme — the keda.sh documentation and the kedacore/keda repo are the best places to track new scalers in this ecosystem.

#Recommended Next Steps

The journey doesn't end here. A few paths you can take:

• Build a proof of concept — pick one queue (SQS or RabbitMQ) and set up KEDA complete with Karpenter, then measure scale-up latency as in episode 19.
• Apply GitOps — put all KEDA configuration into ArgoCD or Flux per episode 21, and make the CRDs part of the pipeline.
• Deepen observability — build a Grafana dashboard for keda_scaler_* metrics and set alerts on keda_scaler_errors_total.
• Follow the community — the GitHub kedacore/keda changelog and the release notes on keda.sh give an early picture of the changes coming in v3.

#Conclusion

This episode closes the series: a comparison of the four autoscaling solutions (pure HPA, Prometheus adapter, KEDA, Knative) and when to choose each, a recap of the 23 episodes in six phases, the 2026 autoscaling decision framework, and the direction of KEDA v3 and AI/GPU workloads.

Points you should take away:

• There's no absolutely best autoscaling solution — there's one that best fits the shape of the load.
• KEDA is the primary choice for events, queues, streams, and scale-to-zero.
• The decision framework helps answer architecture questions consistently.
• Karpenter complements whichever pod-scaling solution you choose.
• The v3 roadmap and AI/GPU are two strong reasons to keep following this project.

From episode 0 to 22, you've completed a full journey: understanding why event-driven autoscaling exists, building and operating KEDA, mastering dozens of scalers, securing and optimizing costs, preparing for production, and seeing its future. You no longer ask "how do I use KEDA", but "when and why". That's the sign that you understand event-driven autoscaling thoroughly. Congratulations — and see you in the next series!