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
