This content is part of the Conference Coverage: KubeCon + CloudNativeCon 2022 news coverage

Google changes tune on Knative, applies to CNCF

Google's decision to submit Knative to the CNCF for incubation prompts speculation about its future: a budding industry standard or a project not worth keeping to itself?

Google submitted its Knative serverless Kubernetes project to the Cloud Native Computing Foundation this week, an about-face from its stated plans two years ago that prompted speculation about the project's future.

Knative, launched by Google in 2018 and co-maintained by partners IBM, Red Hat, VMware and SAP, adds an event-driven abstraction and management layer to Kubernetes clusters that allows developers to ship container images to clouds for deployment without having to pre-configure Kubernetes clusters. The project underpins the Tekton event-driven CI/CD pipeline tool and Google's Cloud Run serverless Kubernetes service. IBM Red Hat OpenShift also integrates Knative and Tekton as OpenShift Serverless and OpenShift Pipelines, respectively.

Google disclosed in 2019 that it had no plans to submit Knative or its Istio service mesh project to an open source foundation for governance, as it had when it donated Kubernetes to the Cloud Native Computing Foundation (CNCF) in 2018. The announcement caused unrest at the time in the open source community, where many community members had expected these projects to follow in Kubernetes' footsteps. Istio competitors, especially, were able to capitalize on doubts about Istio's governance after Google launched its own Open Usage Commons foundation to govern the service mesh project's trademark.

This week's decision to submit an application for incubation status for Knative to the CNCF similarly set IT industry watchers abuzz about what that move means for Knative's future. If Knative succeeds as an open standard, it could allow for cloud portability at a higher level of abstraction than the Kubernetes cluster infrastructure, potentially supporting multi-cloud compatibility between "scale to zero" services similar to Google Cloud Run.

David StraussDavid Strauss

"Google ... may be seeing increased momentum in this space to solidify the open source implementations around scale to zero and isolation technology for containers," said David Strauss, founder and CTO at Pantheon Platform, a web operations platform in San Francisco that runs primarily in Google Cloud Platform, including Google Cloud Run. "They might have been worried that if they didn't actually cement Knative as the solution that people use by increasing its stature through CNCF, other things might ascend."

On the other hand, Strauss said, it could be a sign that Google didn't find Knative worthwhile to keep to itself, and that it instead prefers to offload its development to the open source community and move on.

"It could have a standardizing effect on the industry or this could be offloading [a project] that's targeting use cases that are increasingly supplanted by high-level cloud products like AWS Fargate," Strauss said.

The more clouds support a Knative-compatible runtime, the more confidence we can have that using that sort of technology on Google Cloud is not lock-in for us.
David StraussCTO, Pantheon Platform

While Strauss' company is committed to Google Cloud, he said he would like to see Knative emerge as a new cloud portability standard.

"We're not apt to split our workloads between the clouds that much, but that's for commercial reasons right now, primarily," he said. "The more clouds support a Knative-compatible runtime, the more confidence we can have that using that sort of technology on Google Cloud is not lock-in for us."

All eyes on IBM, cloud hyperscalers' Knative response

While not official yet, it seems safe to assume that the CNCF Technical Oversight Committee (TOC) will accept Knative's application for incubation status. What happens after that, however, depends on how entities outside the open source community respond.

Knative contributor IBM has already made its enthusiasm for Google's decision publicly known in a company blog post this week.

It may have been pressure from IBM specifically, which also publicly expressed displeasure at Google's announcement it wouldn't submit Knative and Istio to a foundation in 2019, that prompted Google to change course, one industry expert speculated.

Larry CarvalhoLarry Carvalho

"Google seemed to think that it was detrimental to keep Knative [governed separately]," said Larry Carvalho, an independent cloud computing consultant. "There may have been fear of someone forking Knative, or [they] could have received an ultimatum from IBM/Red Hat to release it or they would fork it."

IBM declined to comment beyond its blog post this week.

Google is choosing to donate Knative now following its 1.0 release and specification, an important milestone for the project.

"Knative ... has always been an open source project to define APIs for serverless, which has multi-vendor support," the company added in a statement through a spokesperson. "The transition to CNCF stewardship is more reflective of finding a home that accommodates a further broadening of that support."

Moving Knative's governance to a vendor-neutral foundation could accelerate its adoption among customers wary of committing to a project that seems to be under one vendor's control, Carvalho said, namely Red Hat OpenShift customers, who tend to be open source proponents.

For Strauss' serverless cloud portability dream to come true, however, will require a similar change of course from Google's cloud competitors to support managed Knative services. Savvy cloud users can already cobble together their own Knative environments on AWS Fargate and Azure Kubernetes Service, but neither cloud offers commercial support for that within hosted container services.

AWS Fargate doesn't yet support "scale to zero" as Cloud Run does. There are some requests for such support in AWS GitHub forums, but the AWS container roadmap, which describes Fargate scale to zero support as "coming soon," does not refer to Knative as part of that feature.

AWS officials were noncommittal about future support for Knative, saying they would watch for customer interest, but that support will not be part of Fargate.

"The world of Firecracker [micro-VMs] and the Fargate APIs are so different from Knative that that's probably not even tenable," said Deepak Singh, vice president of compute services at AWS. "It'll be interesting to see where it goes and what adoption it gets. So far, we haven't seen it, so it's not been a priority at all."

Still, Strauss said he holds out hope that Knative governed by the CNCF might prompt more cloud vendors to support it. "Scale to zero" and the container isolation made possible through the gVisor hypervisor under Google Cloud Run are important for Pantheon's cost management and security practices, and having similar resources available in other clouds would be ideal, he said.

"The only thing that's worse than having some things that you can't do [within a cloud service] is having that list of things you can't do be different on every cloud provider," he said.

Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.

Dig Deeper on Containers and virtualization

SearchSoftwareQuality
SearchAppArchitecture
SearchCloudComputing
SearchAWS
TheServerSide.com
SearchDataCenter
Close