Because there's a lot to digest here, I've created a page on the Apache OpenWhisk Project Wiki that goes into some more details around the proposed marriage of OpenWhisk and Knative - https://cwiki.apache.org/confluence/x/WwpPBQ
It's a document that will continue to evolve but right now outlines the high level goals of the proposal (as well as non-goals), links to a prototype implementation with a couple of demos, and digs into some of the details of how the two projects work together. Markus, I hope that page helps you understand how I envision OpenWhisk and Knative working together as you continue to refine your ideas around a next-generation architecture. Feedback, questions, and comments are encouraged. Thanks, Ben On Wed, Jul 25, 2018 at 5:43 AM, Markus Thömmes <[email protected]> wrote: > Hi Ben, > > thanks for the write-up! For full disclosure to the rest of the > dev-list: I've been > involved with Knative and have contributed some bits especially to > their autoscaling > strategy. > > The usual word of caution: Knative is in its very early stages (which > is actually > a good thing, because we can shape things then!). It's very exciting in that > it > has the potential to drive serverless requirements into Kubernetes directly. I > don't want it go unsaid though that it's absolutely in an alpha state and not > production ready as of today. This is not to say we should not embrace it but > I want to manage expectations a little bit. > > 2018-07-25 3:28 GMT+02:00 Ben Browning <[email protected]>: >> >> So, to that end, I'd like to open a discussion on whether and how we >> should rearchitect OpenWhisk to take advantage of Knative. >> >> >> To kick things off, here's my personal opinion: >> >> Kubernetes has won the container orchestration battle. Knative builds >> on top of Kubernetes and will make Kubernetes the best place to build >> serverless platforms. Apache OpenWhisk should go all-in on Knative and >> Kubernetes. We should become the best serverless platform that can be >> deployed by any cloud provider or company in their own datacenter. > > I agree we should become the best serverless platform out there. I'm a little > hesitant to take "will make Kubernetes the best place to build serverless > platforms" as a fact and set in stone though. > > While we should go all-in on knative and Kubernetes I don't think we should > drop support for the other deployment topologies that we support today. > Supporting at least Mesos adds to the pluralism in the field and at least in > theory could be a driver for more innovation in the future. Continue to > support > "raw" VMs and/or Kubernetes directly is beneficial I believe as well. > Some of the niceties we are experimenting with continually like stemcell > containers, pre-warming etc. are way harder if not impossible under the model > that Knative sports today. This might well change but I feel like we > should keep > the door open in OpenWhisk to experiment with these optimizations ourselves. > > We could in theory use a layered approach where the whole "execution > system" is an implementation detail to the "Controller" (just using today's > terms). We can then experiment with using Knative as our execution layer > but can continue to support whichever other execution layer we want to > support. > > I cannot say the proposal I wrote up here > https://cwiki.apache.org/confluence/display/OPENWHISK/OpenWhisk+future+architecture > was not sparked by the inception of Knative. We could take that proposal > as a base to work out how to integrate Knative into OpenWhisk and ideally > make the "execution layer" pluggable in itself. It was kinda created with > Knative in mind but has some rough edges to sort out in that direction. > >> We should take the best parts of the OpenWhisk server-side components >> and get those concepts and knowledge, even if not the direct code, >> into Knative. OpenWhisk has a lot of real-world knowledge around >> container pooling, load-balancing, warm and pre-warm containers, etc >> that Knative will need. >> >> Then, we should take the OpenWhisk client tools and extend them to >> work not just with functions and containers but also more traditional >> applications. Knative brings the concept of event-driven autoscaling >> to more than just functions and we should embrace that. We should also >> integrate Knative's concept of Builds into OpenWhisk client tools, >> which fills a gap we have today. > > I agree we can widen the surface of what applications you can run via > OpenWhisk if we start to provide an "apps" API (need to be very careful > on the wording here, "apps" here means: a long-running container with a server > in itself). > > It could be a great value-proposition to allow the user to run a continuum > of different workloads (functions, long-running applications) under one > API to not have to handle different auth, terms etc. > >> >> Finally, we need to reach out to other serverless projects and figure >> out how we can work together. There's going to be a lot of overlapping >> and wasted effort in OpenWhisk, Riff, Kubeless, Fission, OpenFaaS, and >> so on all competing on the developer experience when we're all running >> on top of Kubernetes and Knative. OpenWhisk is already at the Apache >> Foundation which makes us a natural vendor-neutral choice for a >> combined effort. > > That'd be super exciting! > > Very exciting times ahead, the gears are moving! > > Cheers, > Markus
