> how this approach would be different from the many IaaS- and PaaS-centric
I like Adrian Cockcroft's response ( https://twitter.com/intent/like?tweet_id=736553530689998848 ) to this: *"...If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless..."* I think none of us here imagines that we're building a PaaS experience for developers, nor does the current proposal intends to suggest we should. I also assume that none of us imagines to run in production a scalable system with millions of concurrent users with the current setup that demands an incredible amount of resources. Quoting Michael M, which said it nicely, the intent is to make "*the current problem ... not be a problem in reality anymore (and simply remain as a theoretical problem)*". I think we have a way to be pragmatic about the current limitations, make it so that developers don't suffer b/c of this, and buy us enough time to implement the better model that should be used for serverless, where monitoring, "crash safety", "scaling" , and all of the concerns listed previously in this thread are addressed better, but at the same time, the performance doesn't have to suffer so much. This is the intent of this proposal. On Tue, Jul 4, 2017 at 11:15 AM Michael M Behrendt < michaelbehre...@de.ibm.com> wrote: > Hi Dragos, > > > What stops > > Openwhisk to be smart in observing the response times, CPU consumption, > > memory consumption of the running containers ? > > What are your thoughts on how this approach would be different from the > many IaaS- and PaaS-centric autoscaling solutions that have been built over > the last years? All of them require relatively complex policies (eg scale > based on cpu or mem utilization, end-user response time, etc.? What are the > thresholds for when to add/remove capacity?), and a value prop of > serverless is that folks don't have to care about that. > > we should discuss more during the call, but wanted to get this out as food > for thought. > > Sent from my iPhone > > On 4. Jul 2017, at 18:50, Dascalita Dragos <ddrag...@gmail.com> wrote: > > >> How could a developer understand how many requests per container to set > > > > James, this is a good point, along with the other points in your email. > > > > I think the developer doesn't need to know this info actually. What stops > > Openwhisk to be smart in observing the response times, CPU consumption, > > memory consumption of the running containers ? Doing so it could learn > > automatically how many concurrent requests 1 action can handle. It might > be > > easier to solve this problem efficiently, instead of the other problem > > which pushes the entire system to its limits when a couple of actions > get a > > lot of traffic. > > > > > > > >> On Mon, Jul 3, 2017 at 10:08 AM James Thomas <jthomas...@gmail.com> > wrote: > >> > >> +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 > >> > >
