Open KSemenenko opened 10 months ago
What would keda support look like? Do you need it for development?
Of course I no need it for local developments, at least not for every day. But autoscaling is important part of my projects. and we use it a lot for tests in azure.
We build some for https://github.com/managedcode/Keda orleans and asp.net core, for scaling base on “active connection per second”
also I relay love to use aspire for my production deployment. I need only way to configure size of container app. This is amazing tool, it’s easy, so why not?
I see it as extensions for apps like this:
builder.AddProject<Projects.FrontEnd>("frontend")
.WithOrleansClient(orleans)
.WithReplicas(2, 10)
.WithKedaRule(“cpu”, 80)
.WithKedaRule(“requests per second”, 1000);
It will be relay easy way to configure keda.
Keda is a Kubernetes-specific component that supports a wide variety of scalers. Also, during development, CPU and memory might might be different from production for various reasons.
There's value in using multiple replicas in local development instead of waiting for an app to crash once deployed to a cloud environment (looking at you, ASP.NET Core Data protection with Azure KV/Storage). But I don't believe it makes sense to autoscale in local dev. Resource consumption mighr become an issue.
I would rather have the opportunity to manually scale at runtime from the dashboard. Not sure if DCP supports this.
Is aspire only for local development?
Is aspire only for local development?
The orchestration pieces of the AppHost are, yes.
But I relay enjoy how it works, and would live to use it for production too, super cool panel, all logos in once place. Also AppHost can do autoscaling, as for me it will be amazing
Offtopic, but I also find Aspire's panel really enjoyable to work with. It would be cool to use Aspire traces/logs/metrics panel while targeting Elastic for example. Aspire's UX is much better than Kibana's UX for traces/logs in my opinion.
The AppHost is never deployed, however we're working on making the dashboard deployable.
As for keda support, I think the answer is maybe, but it's not a priority at the moment. We're still working on some of the core ideas of how the app model works and what it can represent.
I can write some code for it, I alreday did it for my self, so no probem to do this for aspire. lets just sync our vision about it
@KSemenenko regarding production deployment of the orchestration component this might be related #832
while not directly KEDA related I see this as more about defining the rules about replica scaling and the linkage to triggers; where & what triggers should be listened to and how these are recorded by the application concerned.
the defining of the replica scaling would then be used when deploying to the appropriate environment; or overridden/limited for the local development.
Is there any plans for Keda support? I think this is important for achieving autoscaling