3 ms·
Pretty cool idea, and that api is awesome. > CPU bound work like video transcoding can quickly bring our entire service to a halt in production Couldn't you j
by willsmith72 3y ago
Pretty cool idea, and that api is awesome.
> CPU bound work like video transcoding can quickly bring our entire service to a halt in production
Couldn't you just autoscale your app based on cpu though?
- quaunaut 3y agoYes and no: Maybe the rest of your workloads don't require much CPU- you only need this kind of power for one or two workloads, and you don't want them getting crowded out by other work potentially. Or they require a GPU. Or your core service only needs 1-2 servers, but you need to scale up to dozens/hundreds/thousands on demand, for work that only happens maybe once a day.
- willsmith72 3y agofair enough. i think it's cool tech, but none of those things are "hair on fire" problems for me. i'm sure they are for some people.
- chrismccord 3y agoThanks! I try to address this thought in the opening. The issue with this approach is you are scaling at the wrong level of operation. You're scaling your entire app, ie webserver, in order to service specific hot operations. Instead what we want (and often reach for FaaS for) is granular elastic scale. The idea here is we can do this kind of granular scale for our existing app code rather that smashing the webserver/workers scale buttons and hoping for the best. Make sense?
- stuartaxelowen 3y agoIf you autoscale based on CPU consumption, doesn’t the macro level scaling achieve the same thing? Is the worry scaling small scale services where marginal scaling is a higher multiple, e.g. waste from unused capacity?