openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <>
Subject Re: OpenWhisk Apps on Knative
Date Thu, 14 Mar 2019 01:45:29 GMT
I echo Dave’s words 

To add:

OpenWhisk was born before Kubernetes was mainstream 

OpenWhisk took advantage at that time of Docker CLI and Docker Engine avoiding to re-invent
the wheel. 

OpenWhisk was build and deploy using bash and ant at one point, then gradle, ansible, compose
and later Helm

Kubernetes has become mainstream and there are things that OpenWhisk do and is concerned today
that could be delegated to Kubernetes or Kubernetes ecosystem tools and patterns such as Istio,
CRD, Controllers, Operators, etc...

Like Dave said OpenWhisk can still provide a a better developer experience to people that
just want to build serverless applications and don’t have any interest on how the low level
infrastructure, installation, deployment, or scaling layers work. 
Maybe it means additions to v1, maybe it takes a re-imagination as a v2, maybe it takes building
on top of Knative, maybe takes integrating trigger providers in the form of native CRDs and
Operators, or maybe fusing parts of both projects

Like Dave said is up to the community and not a single person or single company 

- Carlos Santana

> On Mar 13, 2019, at 9:17 PM, David P Grove <> wrote:
> "Michele Sciabarra" <> wrote on 03/13/2019 04:08:15
> PM:=
>> 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 :)
> --dave

View raw message