Feasibility of Hybrid PoolManager/NewDeploy Execution Strategy

Following some analysis of Fission's executor strategies (PoolManager vs. NewDeploy), we've identified the well-known trade-offs:

• PoolManager: Offers excellent cold start performance (<100ms specialization) by reusing warm containers, but lacks per-function resource tuning (CPU/memory limits/requests are set at the Environment level) and doesn't use standard HPA for granular, per-function scaling based on metrics.
• NewDeploy: Provides standard Kubernetes per-function resource limits/requests and HPA-based autoscaling (including scale-to-zero), but incurs a full Kubernetes pod cold start latency, which can be significantly longer.

Ideally, we'd like to combine the benefits of both approaches for a single function: achieve the low-latency cold start of PoolManager while leveraging the efficient, granular scaling and resource management of NewDeploy for sustained load.

Proposed Hybrid Behavior:

A potential hybrid execution model for a single Fission Function could operate as follows:

1. Initial Invocation(s) (Cold Start): The first request(s) to an idle function are routed to the PoolManager. An idle container from the appropriate Environment pool is specialized quickly, providing a sub-100ms response time, thus negating the cold start problem.
2. Sustained Load / Scaling: As load increases beyond the capacity of the initially specialized container(s) (or perhaps after the first hit), Fission would transition to scaling the function using dedicated pods, similar to the NewDeploy model. These dedicated pods would:

• Have per-function specific resource requests/limits defined.
• Be managed by a standard Kubernetes HPA for efficient scaling based on CPU/memory/custom metrics.
• Potentially scale down to zero when load subsides.

Motivation / Benefits:

This hybrid approach aims to offer the "best of both worlds":

• Minimal Cold Start Latency: Leverage PoolManager's core strength for initial requests.
• Efficient Resource Usage: Allow fine-tuning CPU/Memory requests & limits per function for scaled instances (like NewDeploy).
• Granular Autoscaling: Use standard HPA for predictable scaling based on individual function load (like NewDeploy).
• Better Isolation: Dedicated pods for scaled instances reduce "noisy neighbor" concerns inherent in a shared pool.

Reference to Existing Ideas:

I came across the following text (source related to older issue/discussions):

Hybrid approaches are also possible: the first instance of a function can be drawn from the pool (to make cold start fast), and subsequent instances can be be created in new pods (to make autoscaling easier). The beginnings of this implementation already exist on the autoscaling branch.

This suggests that this concept has been considered before and potentially prototyped.

Questions:

• Does Fission currently support such a hybrid execution strategy, even experimentally or via feature flags?
• If not, how technically feasible would it be to adapt the current architecture to support this model?
• What is the status or context of the "autoscaling branch" mentioned in the quote? Does it relate to this hybrid concept?
• Is this type of hybrid executor on the Fission roadmap or under consideration?

We believe this feature could significantly enhance Fission's flexibility, addressing key user trade-offs between performance and scaling efficiency.

Thanks for your time and insights!