openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <markusthoem...@apache.org>
Subject Re: Knative, Kubernetes, and Apache OpenWhisk
Date Wed, 25 Jul 2018 09:43:10 GMT
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