I highly support the idea to start experimenting to help us make more informed decisions vs basing decisions on assumptions.
Should we also agree on a performance goal (aside from the other goals you called out ) ? I'm thinking at setting a performance goal i.e. run X/requests per second on a machine ? WDYT ? On Thu, Aug 23, 2018 at 4:19 PM Markus Thömmes <markusthoem...@apache.org> wrote: > Hi OpenWhiskers, > > We've been discussing a new direction for our architecture based on a > proposal I made here: > > https://cwiki.apache.org/confluence/display/OPENWHISK/OpenWhisk+future+architecture > > Discussion threads: > - > > https://lists.apache.org/thread.html/29289006d190b2c68451f7625c13bb8020cc8e9928db66f1b0def18e@%3Cdev.openwhisk.apache.org%3E > - > > https://lists.apache.org/thread.html/02986151fb2cffb7426c0d3b207c35923bc49bf164a967d310b3bbb6@%3Cdev.openwhisk.apache.org%3E > - > > https://lists.apache.org/thread.html/efec3d588e3519ce72b44f2d5ae00cabf1f6a33afaa2f08194290553@%3Cdev.openwhisk.apache.org%3E > > This discussion has been veeery fruitful and I enjoyed i'm enjoying it a > lot! Thanks so far to anybody who continues to contribute here! > > I think we are reaching a point where we start assuming a lot of things. > I'll attempt to diagram out my current view of things and maybe we can > already agree on some key parts of the current design as-is? Things I have > in mind that we need: > > 1. ContainerRouter: I think there's little debate around us needing an > efficient router, preferably with an API, that we can add/remove containers > from. > 2. ContainerManager: In terms of it being the interface creating containers > seems pretty accepted as well, from what I read in the discussions. > 3. A work-stealing backend: A backend (hopefully a pre-canned MQ) that > allows us to do action-specific pulling and signaling of demand through > that pulling. This one I think is more subject to a debate than the other > two. > > We should also lay out some of the basic gains we want to have from that > new system, i.e.: > 1. Makes streaming payloads possible. > 2. Has very high warm-ratios. > 3. Doesn't create (many) more containers than needed. > > (These are examples, others will feel different) > > Key point I want to make is: At some point we'll have to start to prototype > things out and see if our assumptions actually hold water. For example, my > assumption on a work-stealing backend is pretty much in the air. > > My proposal for going forward would be: > 1. Create a playground for the implementation of some parts of the system > (a new repository?) > 2. Let's build some of the things that are uncontroversial and absolutely > needed in any case (ContainerRouter, ContainerManager). > 3. Play around with them, hook them up in different ways, see what works > and what doesn't. > > Some things will need some testing out to see the scale that the components > can operate at. These things will narrow or widen the solution space for > the more controversial topics around how to distribute containers in the > system, how to balance between the routers, work-stealing queue: yes/no > etc. > > Having some simple components fleshed out could encourage innovation and > creates some facts that we need to focus things into a good direction. > > What do you think? Too early to start with this and/or the wrong way of > doing it? > > Cheers, > Markus >
