+1 on Markus' points about "crash safety" and "scaling". I can understand the reasons behind exploring this change but from a developer experience point of view this adds introduces a large amount of complexity to the programming model.
If I have a concurrent container serving 100 requests and one of the requests triggers a fatal error how does that affect the other requests? Tearing down the entire runtime environment will destroy all those requests. How could a developer understand how many requests per container to set without a manual trial and error process? It also means you have to start considering things like race conditions or other challenges of concurrent code execution. This makes debugging and monitoring also more challenging. Looking at the other serverless providers, I've not seen this featured requested before. Developers generally ask AWS to raise the concurrent invocations limit for their application. This keeps the platform doing the hard task of managing resources and being efficient and allows them to use the same programming model. On 2 July 2017 at 11:05, Markus Thömmes <markusthoem...@me.com> wrote: > ... > > 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". > > 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. > > Cheers, > Markus > > -- Regards, James Thomas
