From dev-return-2551-archive-asf-public=cust-asf.ponee.io@openwhisk.apache.org Wed Aug 29 10:36:00 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9D730180657 for ; Wed, 29 Aug 2018 10:35:59 +0200 (CEST) Received: (qmail 549 invoked by uid 500); 29 Aug 2018 08:35:58 -0000 Mailing-List: contact dev-help@openwhisk.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openwhisk.apache.org Delivered-To: mailing list dev@openwhisk.apache.org Received: (qmail 537 invoked by uid 99); 29 Aug 2018 08:35:57 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2018 08:35:57 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 8DEBC1809B6 for ; Wed, 29 Aug 2018 08:35:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.889 X-Spam-Level: * X-Spam-Status: No, score=1.889 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 6IOkkSgWxv85 for ; Wed, 29 Aug 2018 08:35:49 +0000 (UTC) Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 351BE5F17E for ; Wed, 29 Aug 2018 08:35:49 +0000 (UTC) Received: by mail-wm0-f43.google.com with SMTP id y2-v6so4389808wma.1 for ; Wed, 29 Aug 2018 01:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=et1Rrx4a9Pdox6Sx0VWvyWrhPPuA09AKd0Xnj4bimCU=; b=CsMYhIsGT5+z9kVo0OKU5Or6twxBKc6/+7KWbOyCZjdvlarnIJ6JtpPSfVFNeaANNC +gOWgohj9VHia8Az51Q0KIBDl8e046/gMGyT81jWDwndonzcJv2Vl5mnvoqEwZohXTJ6 nC2I/S8D5P35KVd0FDbySZvcIV5gTv1436YYxRnUL9OhJBjg+fv+MvhRK1gVJupoTr8V w8hEvB8Rq6gw0bgWkgQH44rVwAAyHSaaOv4t/EP8hTV+BULhuz6TlvJbtBT/vciTIIsA O6BdLqtDCwNyI1+S9D/ZSTna4tTuM7jVwGiuPnymcUsHRZtSAdnZFlV7YewhJqS7UnPo oPmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=et1Rrx4a9Pdox6Sx0VWvyWrhPPuA09AKd0Xnj4bimCU=; b=IqLRFhUyOvU262Y9CQB+uVm0JRVS+SFi0z8VzBalFG4wP4aWwS+cU0c32i1FK3r3xw Z+PpllsjXgJ20eLNhX7XhbUQI22BO3+pBTl7HkchE7uY8JX9GVV7sb72xwP3NK6oOceY N0n81d4JDzGzm67Wh5rE8TVNZ3Q6ew6yd6au2S75Htzqs15fwmzAkHXEKxmbbP2rS4ph 7gURT6w2bmx3BNjp4hMrfN5RRoII6DCPqloFwdC24hGA9tuT21yXuGGtO2aLKauEIBhm ojoKDUhmPDebt4YBb551ERQ5q23IUmN9hNF2yIiyWRltckmAXaXB5peGuVL9krQhIBo5 qisQ== X-Gm-Message-State: APzg51CbB1GViUGeSWYxbyOK//2VY/rqTr98raSt2cDU30mLQw4nvcza EPgYM4jplbjcBz631k+rH2eZV2kWJk4YPWYjJUrzrIBK X-Google-Smtp-Source: ANB0Vda1uHoSN6dT0LQ3Xa0yFTCUylINKOsjWCG89KwUFD7zanO3YWP0rern/xyJtvK6CVC7af1lGCsj/3OVDxS/iUw= X-Received: by 2002:a1c:e581:: with SMTP id c123-v6mr3640726wmh.85.1535531742933; Wed, 29 Aug 2018 01:35:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vadim Raskin Date: Wed, 29 Aug 2018 09:35:31 +0100 Message-ID: Subject: Re: Prototyping for a future architecture To: dev@openwhisk.apache.org Content-Type: multipart/alternative; boundary="00000000000014388105748ed83f" --00000000000014388105748ed83f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I see how performance of certain components could benefit from switching its implementation to Go. Earlier this year I did performance measurements of Go vs Scala http servers / logging systems. I was able to find a combo of Go based components that outperformed Scala implementation by 3-4x times. Thus **+1** to what Markus said with regards to the language choice. On Wed, 29 Aug 2018 at 04:31 Markus Th=C3=B6mmes wrote: > Hi, > > okay, let's separate concerns: > > ### Golang vs. Scala vs. something else entirely: ### > > I'm okay doing it in Scala although I don't see an issue in swapping the > language for a component that needs to be rewritten from the ground up > anyway (which I'm suggesting at least the ContainerRouter is). > > The ContainerPool/ContainerProxy part of it comes to mind immediately. It > was built with a scale of maybe 100 containers max in mind. There are a f= ew > performance problems with it at scale, that I can point out off the bat. > The changes needed to mitigate those are rather severe and while we **can= ** > implement those (and maybe even should if this proofs to make sense) I > believe it makes sense to at least experiment with a freshly written > component. In the new architecture, we can also greatly reduce the state > model to just paused/unpaused for the ContainerRouter, further simplifyin= g > its implementation. > > The ContainerRouter's speed requirements are more close to those of > nginx/envoy than they are to those of the current ContainerPool/Proxy > implementation. As Dave mentioned, for the ContainerRouter it will be ver= y > critical to know how many containers it can handle in reality, hence I'm > shooting for an as efficient implementation of its innerts as possible to > flesh out how far we can push the boundaries here. > > In any case: Yes we can stick to Scala here, but at least the > ContainerRouter might be 100% new code and we might not even be able to > rely on things like akka-http for its implementation for the reasons > mentioned above. > > ### Seperate repo vs. branch ### > > Towards Michaels points: The prototype repo is supposed to be used for > experimenting/prototyping and for that purpose only. As Dave pointed out > above, we'd want these experiments to happen with Apache visibility. Ther= e > will never be a completely working system available in that repository. T= he > goal of it is to find out if certain assumptions of a new design are > feasible or not. The goal is **not** to build productised components that > we can take over to the mainline. > > I always thought of that rearch as an incremental step as well and it > shouldn't need major changes to the API (or at least none that we are not > already introducing right now). I don't think we're going to see the true > potential of this though if we try to take the system's components as is > and reuse them in contexts they have never been built for in the first > place. > > As soon as we have clearance over which way we want to ultimately go with > the architecture, I agree we should come up with a nice migration plan an= d > start building it into the main repository through that migration plan. T= he > prototyping repository should vanish at some point. > > ### Summary ### > > I don't feel super strong about a choice of language, I just thought I'd > throw that in the ring as well. As sentiments seem quite strong against > doing that right now, which is perfectly fine, I'd be fine doing the > implementations in Scala. The disclaimer though is, that I'd like to writ= e > critical components afresh to not have to fight with existing architectur= al > choices to much but to be able to think freely about the problems at hand= . > > Which is why I do feel quite strongly about not doing this in a branch. T= he > structure of the project will be very different and I can easily see peop= le > confused if we start having pull-requests against a "prototype" branch > mixed in with our usual pull-requests. > > I do however agree that we eventually will need to build this in an > incremental way, once we know what we want to build in the first place. F= or > me, it's off the table to attempt to rewrite the system from scratch, we'= ll > likely never get that done (I think that's version 2 syndrome Michael?). = I > agree that might end up in a dead end and we shouldn't do that. > > Does that make the intention more clear? I hope I addressed all the point= s > asked. Opinions welcome :) > > Cheers, > Markus > > Am Mi., 29. Aug. 2018 um 00:55 Uhr schrieb Dascalita Dragos < > ddragosd@gmail.com>: > > > I also click on the clean and lean upgrade path, with gradual > improvements > > to the existing system (which is production-proof), as Michael and Rodr= ic > > are suggesting. > > > > At the same time I see how Go would make sense from the Kubernetes and > > Knative impl POV, how the trends favor Go over Scala [1], [2], and the > > potential benefits from addressing a larger dev audience. @Markus, feel > > free to keep me honest if this is where you're coming from. > > > > Trying to keep our options open, I'm thinking: why not take Markus' > > challenge, and design these enhancements now to support polyglot > > implementations in the future ? This would be the important decision we > can > > take. BTW, for the data plane itself, we could go at even lower levels = to > > Envoy or Nginx, to provide superior performance, should we choose to. > > > > [1] - > > > > > https://trends.google.com/trends/explore?geo=3DUS&q=3D%2Fm%2F091hdj,%2Fm%= 2F09gbxjr > > > > [2] - https://octoverse.github.com/ > > > > On Tue, Aug 28, 2018 at 2:53 PM Rodric Rabbah wrote: > > > > > Thanks Michael for raising these points. I share the same opinion and > > > sentiment and think a branch with a clean migration story is better a= nd > > > makes more sense. I am not entirely convinced that the choice of > language > > > itself will make the difference vs the new architecture which is quit= e > > > different and should in itself be more efficient. > > > > > > -r > > > > > > On Tue, Aug 28, 2018 at 4:51 PM Michael Marth > > > > wrote: > > > > > > > Hi Markus, > > > > > > > > IMHO what you propose below is a rather severe change in scope of > this > > > > discussion and effort. > > > > Up until so far this was about _evolving_ the OW architecture. We > have > > > not > > > > explicitly discussed it, but one could assume that it is at least > > > feasible > > > > to gradually adopt the new architecture. So there would be a smooth > > path > > > > between the current state of the code base and a future one. > > > > > > > > Your proposal below breaks this assumption somewhat (by proposing a > new > > > > repo instead of a branch - which will inevitably make the 2 code > bases > > > > drift apart) as well as explicitly by suggesting a new implementati= on > > > > language. Especially the latter would create a schism between OW-no= w > > and > > > > OW-future. > > > > This schism has implications like the perception of OW-now being > > > > deprecated, the _possibility_ of no clean upgrade path, the immedia= te > > > split > > > > of the community between *-now and *-future and of course carries t= he > > > risk > > > > of the version 2 syndrome. > > > > > > > > I would propose to implement the future architecture in a branch an= d > in > > > > Scala first. If it turns out to be good, then subsequent experiment= s > > can > > > > show or not-show if a switch of language is of additional value. Th= at > > > would > > > > allow to make a decision based on data rather than anything else. > > > > > > > > My2c > > > > Michael > > > > > > > > > > > > =EF=BB=BFOn 28.08.18, 14:26, "Markus Th=C3=B6mmes" > > wrote: > > > > > > > > Hi all, > > > > > > > > Am Mo., 27. Aug. 2018 um 20:04 Uhr schrieb David P Grove < > > > > groved@us.ibm.com > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > "Markus Th=C3=B6mmes" 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, s= ee > > > what > > > > works > > > > > > and what doesn't. > > > > > > > > > > > > Some things will need some testing out to see the scale tha= t > > 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 an= d > 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 th= e > > work > > > > to be > > > > > at Apache (community visibility). I'm not sure if the best w= ay > > is > > > a > > > > new > > > > > repo or an experimental branch of the main repo (we could dia= l > > 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. > > > > > > > > > > > > > I actually think we should generate a new repository for this. > > > Opening > > > > PRs > > > > etc. will then not clutter the "main" repository and we don't > need > > to > > > > worry > > > > about breaking anything. > > > > > > > > If nobody objects I'm going to get "incubator-openwhisk-protoyp= e" > > > > generated > > > > and will create a rough outline in the repository (different > > folders > > > > for > > > > different parts of the system). > > > > > > > > One more basic question (and this is going to be controversial)= : > > Most > > > > of > > > > the componentry in the execution layer will have to be build > anew. > > > I'd > > > > like > > > > to switch the implementation language of at least the > > ContainerRouter > > > > to > > > > Golang. Why? Because scale/performance matters a lot for them. = As > > > Dave > > > > mentioned on multiple occasions, it will greatly matter how man= y > > > > containers > > > > such a Router can handle under load and that scale will define > the > > > > implementation alternatives we will have at hand. I therefore > would > > > > like to > > > > optimise these Routers for minimal overhead. We could go even > lower > > > > level, > > > > but I guess that'd be at a kinda big maintenance cost. > > > > > > > > I can envision the ContainerManager to be simpler to implement = in > > > > Golang as > > > > well, at least for some of the deployment alternatives > (Kubernetes > > > > comes to > > > > mind). The Golang based clients seemed superior to me vs. clien= ts > > in > > > > any > > > > other language. > > > > > > > > As all of the communication will probably be HTTP only anyway, > > these > > > > implementations should be swappable anytime. > > > > > > > > Comments very welcome! Let me know your opinions. > > > > > > > > Cheers, > > > > Markus > > > > > > > > > > > > > > > > > > --00000000000014388105748ed83f--