openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David P Grove" <gro...@us.ibm.com>
Subject Re: Prototyping for a future architecture
Date Mon, 27 Aug 2018 18:01:50 GMT



"Markus Thömmes" <markusthoemmes@apache.org> wrote on 08/23/2018 04:19:33
PM:

>
> 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?
>

+1 for starting to prototype.  It's been a good discussion and I think
we've identified some things that we know we don't know, so time to
experiment and find out.


Not sure what the best logistics are for this.  Would like the work to be
at Apache (community visibility).  I'm not sure if the best way is a new
repo or an experimental branch of the main repo (we could dial down the
level of testing on the branch to make it less cumbersome?).  The branch is
attractive to me because it might make it easier to keep in synch with the
components we aren't changing.

--dave

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message