Knative, Kubernetes, and Apache OpenWhisk

[Ben Browning <bb...@redhat.com>]

The Kubernetes serverless space just got a lot more interesting with
the public announcement of the Knative open source project from Google
- https://github.com/knative/

The Knative docs (https://github.com/knative/docs) and this Hacker
News thread (https://news.ycombinator.com/item?id=17602377) provide
more context on what Knative is and who the target audience is.

Essentially, Knative is a set of building blocks that can be used to
create a serverless platform on top of Kubernetes. It's not something
intended to be used directly by serverless developers but instead
integrated into other projects and vendor platforms.

Several OpenWhisk contributors are involved in Knative, as are
contributors from a number of other projects in the Kubernetes
serverless space. I believe we're going to see the combined knowledge
of all Kubernetes serverless projects end up in these common building
blocks. And this combined community will improve the serverless
experience on Kubernetes for all that layer on top of it.

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.

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.

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.


So, discuss!

Ben

Re: Knative, Kubernetes, and Apache OpenWhisk

[Ben Browning <bb...@redhat.com>]

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
<ma...@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 <bb...@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

Re: Knative, Kubernetes, and Apache OpenWhisk

[Markus Thömmes <ma...@apache.org>]

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 <bb...@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