openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David P Grove" <>
Subject Re: OpenWhisk Apps on Knative
Date Thu, 14 Mar 2019 01:17:23 GMT

"Michele Sciabarra" <> wrote on 03/13/2019 04:08:15
> So, is the focus of the project shifting on Knative? Dropping the
> current invoker and controller, keeping the runtimes and run them
> with Knative?

My 2 cents as an individual is that there is quite a bit of value in being
able to program against the OpenWhisk programming model and its runtimes in
a more Kubernetes-centric world.

I think it is still an open question what the best underlying runtime
system for that programming model is (and even if there is a single best
runtime system that spans all the possible scenarios in terms of scale,
multi-tenancy, etc.). As a system researcher, one of the best ways I know
to explore that question is to be able to run the exact same
program/workload on multiple runtime systems under different scenarios and
measure what happens.

Our current runtime system probably does need to evolve to better exploit
Mesos/Kubernetes (eg Tyson's recent PR).  Kubernetes itself is likely to
evolve to better support FaaS-style workloads so we will be able to have a
thinner OpenWhisk-specific layer.  I don't think we should expect every
runtime system design decision we have made to hold constant as technology
evolves around us.  But the system-level OpenWhisk runtime could completely
change without any disruption to the user-level programming model and
developer tooling.   For example, IBM Cloud Functions switched from a
"classic" ansible-driven VM-based deployment to a Kubernetes-based
deployment of OpenWhisk in the middle of 2018.  None of our customers
noticed or cared (from their perspective nothing changed and all their
existing programs still run just fine).

Finally, the focus of this project is where the community takes it. We can
even go multiple directions simultaneously. That's how open source works :)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message