openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Browning <bbrow...@redhat.com>
Subject Re: Knative, Kubernetes, and Apache OpenWhisk
Date Tue, 07 Aug 2018 16:29:29 GMT
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
<markusthoemmes@apache.org> 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 <bbrownin@redhat.com>:
>>
>> 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

Mime
View raw message