kubeless
kubeless copied to clipboard
vmware-archive
Consider migrating or using knative components
There seems to be a lot of interest in knative, which has reusable components. Let's consider migrating or using components of that project:
https://github.com/knative/build
Hi @jamding, the knative project is indeed interesting. Many of the features for the "build" sub-project are present in Kubeless though. Were you thinking in some specific component that we can reuse?
@andresmgot I haven't investigated in detail which pieces in knative or future components might be useful or good candidates to migrate kubeless functionality to, but I plan to learn more about knative.
@sebgoa are you working on the knative project, or incorporating components from knative into kubeless?
It seems like both Kubeless and Knative have their place. Kubeless for very simple deployments (like GCF) and Knative is even more feature filled than Cloud run. Could the experts (@sebgoa and @andresmgot ) give more insight on the differences?
kubeless was created as an early FaaS prototype before 2 years or so before knative. Knative has a much larger community and a higher pace of innovation. As creator of kubeless I have been recommending knative for the past 3 years.
Having said that @sebgoa, there are more stars in kubeless than in Knative serving and eventing repos combined. It seems like the community appreciates both. Knative seems more complex and powerful, but not everyone needs this.
fair. openfaas has way more stars than all these projects, so if we follow that thinking everyone should use openfaas.
if you want insight on the differences: knative is a much stronger codebase with high quality controllers, strong testing and a 6 month release cycles. Support is available from commercial vendors, serving provides scale to zero and eventing provides multiple event sources and support for different eventing channels. kubeless has a function UX at its core and early eventing triggers, however it is not actively developed despite a little bit of community support. knative started from the standpoint that the deployable artefact was a container (just like the new AWS lambda for containers), while Kubeless started from the standpoint that people were going to write small functions and that they would need to be injected in runtimes at deployment time (even though docker build capability was added).
In the end, people should test software, evaluate and make a decision. I always think that in the long run and at feature parity you are better off using the software that has the highest development velocity so instead of stars I look at contributions.