Should Knative Be Under Google?

This week at GoogleNext 2018, Google and some other partners announced the launch of a new open source project called Knative. Knative is a higher level abstraction that offers some of the primitives needed to build and deploy the code on top of Kubernetes. Google along with Pivotal, SAP, IBM, Red Hat and others have got this project off ground after keeping it secret for the past several months. Right now, Knative is a Google project but it should be brought under CNCF as soon as possible. I do understand that the project was released only a couple of days back but this is needed for the long term success of the project.

Why should it be under CNCF so early in the lifecycle?

  • A truly open source project should happen in an open community that is independent of any vendor. Like a proprietary software launch, the Knative launch was planned in complete secrecy till the announcement this week. This is not all that surprising because Google launched Kubernetes, Istio, Tensorflow, etc. like this. Even if we discount this fact as the corporate approach to open source, a move to an independent community is needed, if Knative has to emerge as the standard abstraction layer on top of Kubernetes. Till it is made available under an independent community governance, it is a Google project even though it has the support of Pivotal, SAP, Red Hat, IBM, etc.
  • Already there are complaints from other vendors in the Kubernetes ecosystem that Knative is closely aligned to another Google project Istio. This might work well for Google which is trying to offer cloud services using these open source software. In fact, Google’s plan is to make Knative the underlying fabric for all their Serverless offerings. But, it is not going to help make Knative an industry standard like Kubernetes unless these dependencies are eliminated. This will only happen faster if the project is under an independent community
  • One could argue that Google did the same with Kubernetes. They only brought it to an independent foundation after the project matured to a certain level. It worked because there was no independent cloud-native community before Kubernetes became the CNCF project. The community was frustrated with Docker’s approach to the OSS. Kubernetes gave an opening to vendors who invested in Docker based containers and were gasping for a way forward with an independent open source project. The current situation is different. CNCF has grown strong as an independent organization for container based technologies with Kubernetes at the core. Unless the community around CNCF buys into Knative, the project cannot evolve as a standard on top of Kubernetes

Expected path forward

Ever since the early days of cloud, Rishidot Research has been an independent voice, advocating ideas that will ensure competitiveness in the market. Knative has the potential to emerge as a Kubernetes abstraction on top of which Serverless frontends (think of OpenWhisk, Project Riff and others sitting on top of Knative) can be built. If this has to happen, the following steps are immediately needed:

  • Bring it under independent foundation like CNCF and get other cloud providers like Microsoft to support the project
  • Make the project independent of Istio
  • Make the installation simple independent of the underlying Kubernetes distribution
  • Bring diversity in contributions to the project and avoid any gerrymandering

We are already seeing AWS Lambda with a strong lead in the Serverless market. Google, Microsoft, and other hyperscale cloud providers can slow AWS down by emphasizing portability. For this to happen, Kubernetes community should coalesce around a standard. Knative has the potential but it cannot happen when Knative is under Google’s control. Thoughts?

Originally published at