Re: Improving support for UI driven use cases

Hi Michael, Totally agree with your statement “value prop of serverless is that folks don't have to care about that" Again, the proposal at hand does not intend to change that at all. On the contrary - in our mind it’s a requirement that the developer should not change or that internals of the

Re: Improving support for UI driven use cases

Hi Michael, thanks for the feedback -- glad you like my stmt re value prop :-) I might not yet have fully gotten my head around Steve's proposal -- what are your thoughts on how this would help avoiding the reimplementation of an autoscaling / feedback loop mechanism, as we know it from more

Re: Improving support for UI driven use cases

Thanks everyone for the feedback. I’d be happy to join a call - A couple of details on the proposal that may or may not be clear: - no changes to existing behavior without explicit adoption by the action developer or function client (e.g. developer would have to “allow” the function to

Re: Improving support for UI driven use cases

Again, this doesn't answer how to avoid implementing the autoscaling function idescribed below... Sent from my iPhone > On 5. Jul 2017, at 17:45, Alex Glikson wrote: > > Once different 'flavors' of pools/invokers are supported, one could > implement whatever policy for

Re: Improving support for UI driven use cases

Hi Michael, To make sure we mean the same thing with the word “autoscaling” in the context of this thread and in the context of OpenWhisk: I refer to the (automated) increase/decrease of the VMs that run the action containers. Is that what you also refer to? If so, then the proposal at hand is

Re: Improving support for UI driven use cases

Hi Alex, That is a very interesting question. If the programming model and guarantees that are exposed to developers involve guarantees on amount of memory then I still see two options: - reserve the full capacity (i.e. Current model) - or “overbook” a container. (not exactly the spirit of the