> On Jul 2, 2017, at 3:05 AM, Markus Thömmes <[email protected]> wrote: > > Right, I think the UI workflows are just an example of apps that are latency > sensitive in general. > > I had a discussion with Stephen Fink on the matter of detecting ourselves > that an action is latency sensitive by using the blocking parameter or as > mentioned the user's configuration in terms of web-action vs. non-web action. > The conclusion there was, that we probably cannot reliably detect latency > sensitivity without asking the user to do so. Having such an option has > implications on other aspects of the platform: Why would one not choose that > option? >
Because a) your use case is event driven and the client trigger simply doesn’t care about the response or b) you want a guarantee that the activation will be processed even if the client stops listening for the response (e.g. they received a 202 instead of 200 after a timeout) > To Rodric's points I think there are two topics to speak about and discuss: > > 1. The programming model: The current model encourages users to break their > actions apart in "functions" that take payload and return payload. Having a > deployment model outlined could as noted encourage users to use OpenWhisk as > a way to rapidly deploy/undeploy their usual webserver based applications. > The current model is nice in that it solves a lot of problems for the > customer in terms of scalability and "crash safeness". > But if you require use of the programming model to always achieve scalability, you prevent use of libraries that may not be ported to that programming model. Consider a npm module that is used to wrap twitter API calls. I use that in my action to produce tweets. Is my only option for making my action scale (better than 1 user : 1 container) to reproduce the npm module in terms of OpenWhisk functions for each HTTP call and compute operation? > 2. Raw throughput of our deployment model: Setting the concerns aside I think > it is valid to explore concurrent invocations of actions on the same > container. This does not necessarily mean that users start to deploy > monolithic apps as noted above, but it certainly could. Keeping our > JSON-in/JSON-out at least for now though, could encourage users to continue > to think in functions. Having a toggle per action which is disabled by > default might be a good way to start here, since many users might need to > change action code to support that notion and for some applications it might > not be valid at all. I think it was also already noted, that this imposes > some of the "old-fashioned" problems on the user, like: How many concurrent > requests will my action be able to handle? That kinda defeats the > seemless-scalability point of serverless. I’m not suggesting changing any programming model, only that the programming model stops at the point that I depend on libraries for anything, so relying on the programming model to achieve throughput scalability will not be practical in many cases. I pointed out that both: the problems are old fashioned yes, and that concurrency is (still) a reasonable way to address them, Also that doing so it is not defeating any scalability provisions of a serverless mantra: additional containers can still be started per action, just not *1 per concurrent user*. You still need to provide some estimate of resource usage of your action. The only difference is that your approach to determining that estimate changes. e.g. if I can estimate that my action operates well at 100 rps with 500 concurrent users, and worse with more concurrent users, then I can configure the system to start more containers once 500 concurrent activations is hit, and stop those containers when it decreases below 500. How do you today estimate resource requirements of actions that are single-user workflows? Maybe that is something we can discuss to clarify how it would be done in a concurrent activation model. Thanks Tyson >
