So for each “Flame.call” it begins a whole new app process and copies the execution context in?
A very simple solution to scaling, but I’d imagine this would have some disadvantages…
Adding 10ms to the app startup time, adds 10ms to every “Flame.call” part of the application too… same with memory I suppose
I guess these concerns just need to be consider when using this system
For hot runners, the only overhead is the latency between the parent and child, which should be the same datacenter so 1ms or sub 1ms.
Your own mission statement states: "We want on-demand, granular elastic scale of specific parts of our app code." Doing that correctly is fundamentally a question of how long you need to wait for cold starts, because if you have a traffic spike, the spiked part of the traffic is simply not being served until the cold start period elapses. If you're running hot runners with no load, or if you have incoming load without runners (immediately) serving them, then you're not really delivering on your goal here. AWS EC2 has had autoscaling groups for more than a decade, and of course, a VM is essentially a more elaborate wrapper for any kind of application code you can write, and one with a longer cold-start time.
> Under load you are rarely paying the cold start time because the pool is already hot.
My spiky workloads beg to differ.