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
