http-add-on VS keda

KEDA ships with an HTTP add-on to enable HTTP scaling.

KEDA has a special scaler that creates an HTTP proxy that measures and buffers requests before they reach the app.

I am a core maintainer on the KEDA HTTP Addon project (https://github.com/kedacore/http-add-on). It's 100% written in Go and we are a small group looking for additional contributors. I believe there are interesting challenges ahead of us that will be enjoyable to solve.

If you're interested, please reach out. My username here is the same as my username on the Gophers and Kubernetes slack groups.

(You're of course welcome to just go pick up an issue in the repo if you'd prefer)

The KEDA HTTP Addon project contains three major components: the operator, scaler and interceptor.

Hacking on the KEDA HTTP Addon, I found myself having to do something familiar:

First, we need to finish the minimal infrastructure. The components and supporting artifacts (Helm charts, CI scripts, etc...) are being built in PR #2, and once we have them completed, we will merge it [5]. Second, we need to establish a roadmap. We're beginning to outline it now and will finish it shortly after merging.

> lambda apps

Yes, SST [1] uses lambdas heavily but makes it more seamless and less visible, just the place your code runs.

I’ve also found Azure Container Apps to hit the right balance. It’s kubernetes under the hood, which you don’t have to mess with at all, except that it can use KEDA [2] scaling rules to scale your containers to zero, then scale up with any of the supported KEDA scalers like when a message hits a queue.

[1] https://sst.dev/

[2] https://keda.sh/

KEDA is a Kubernetes-based autoscaler that dynamically adjusts the number of pods in your cluster based on the number of events needing to be processed. It is a lightweight, single-purpose component that integrates seamlessly with any Kubernetes cluster.

Look for example at the metrics exposed by kube state metrics: https://github.com/kubernetes/kube-state-metrics/tree/main/d...

With controllers metrics + kube state metrics about most Kubernetes resources, you can easily build alerts when a resource fails to reconcile.

> Basically, Horizontal Pod Autoscaler but with sensors which are not just "CPU"

Take a look at KEDA, it's exactly this: https://keda.sh/

I am a little confused by your mention of "EC2 autoscaler" and then "EC2 ASG" autoscaler, but if I'm hearing you correctly and you'd want "self managed ASGs," then you may have some success adapting Keda <https://github.com/kedacore/keda#readme> (or your-favorite-event-driven-gizmo) to monitor the metrics that interest you and driving ec2.LaunchInstances on the other side, since as very best I can tell that's what ASGs are doing just using their serverless-event-something-or-other versus your serverless-event-something-or-other. I would suspect you could even continue to use the existing ec2.LaunchTemplate as the "stamp out copies of these" system, since there doesn't appear to be anything especially ASG-y about them, just that is the only(?) consumer thus far

It seems you want something like KEDA (https://keda.sh)

Most just utilize out of the box macro resources available in HPA.

For more advanced use cases there is keda - https://keda.sh/

Thankfully KEDA operator was already part of the cluster, and all Robin had to do was create a ScaledObject manifest targeting the Dispatch ScaleUp event, based on the rabbitmq_global_messages_received_total metric from Prometheus.

Keda

KEDA introduces event-driven scaling to Kubernetes workloads. It integrates with Kubernetes Horizontal Pod Autoscalers and can scale pods based on external metrics from services like databases and message queues (Kafka, RabbitMQ, MongoDB).