Knative’s maturation process now has a schedule that will see new releases based on a six-week cycle. That means there should be meaningful updates to the open source platform nearly twice as fast as those being pushed by the rapidly evolving Kubernetes ecosystem.
“As we move to a more predictable release schedule based on [a] six-week cadence, Knative releases will now be smaller and more frequent,” Chmarny wrote. “We did this to enable a tighter feedback loop with our users and allow for smoother course corrections as we continue to learn from our growing number of users.”
The update schedule is significantly faster than what the Kubernetes community has been working with, which some vendors have noted has made it a challenge to remain on top of the most recent releases. This has led some to initiate additional testing requirements for the latest Kubernetes releases that often has their hosted platforms one release cycle behind.
Chmarny’s post also touted the latest 0.3 release of the Knative platform. Highlights of the new release include updates to the serving API that tie the platform closer to Kubernetes; autoscaling updates that include a more aggressive “scale-to-zero” strategy; reducing the overhead on Istio networking; and bolstering updates that were introduced in the 0.2 release from last October.
The latest Knative release also now requires the use of at least the 1.11 version of Kubernetes to support some of the new updates.
As for adoption timing, William Markito Oliveira, senior principal product manager at Red Hat, said his company would integrate the updated Knative platform into its OpenShift product “within a few weeks, after our own testing.”
The scheduling move and latest update are significant steps for the platform that launched just last summer. It was developed by Google, Pivotal, IBM, SAP, and Red Hat as a way to provide an open source set of components that allow for the building and deployment of container-based serverless applications that can be transported between cloud providers. It’s specifically focused on orchestrating source-to-container builds; routing and managing traffic during deployment; auto-scaling workloads; and binding services to event ecosystems.
The platform is targeted at unchaining current serverless development platforms that are tied to their respective cloud parents. These would include hosted services like Amazon Web Services (AWS) Lambda, Microsoft Azure Functions, and Google Cloud Functions.
“This portability is really important and what is behind the industry aligning behind Knative,” explained Aparna Sinha, group product manager for Kubernetes at Google, during her keynote address at the recent KubeCon + CloudNativeCon North America 2018 event in Seattle.
A number of vendors have already jumped on the Knative bandwagon. The most obvious have been those that were part of its initial development. Pivotal, for instance, launched its Pivotal Functions Service (PFS) that uses components from the Knative project to manage deployment and operation of serverless functions across private and public cloud providers.
But, Knative has also attracted others to the ecosystem that see an advantage of using Kubernetes as a way to manage serverless deployments. As an example, startup TriggerMesh launched late last year with a serverless management platform that runs on top of Knative. That platform has already been tapped by GitLab to power its serverless product.
However, some vendors are still waiting for Knative to mature before committing. Platform9, which offers a different Kubernetes-native serverless framework, has questioned the need and motives behind the Knative push.
“I don’t fully understand the motive behind Knative,” Platform9 CEO Sirish Reghuram told SDxCentral last year. “Is this some sort of business-driven move that will give IBM and Pivotal some wind at their backs with the Kubernetes community at large?”
However, the company did say that it was watching how Knative was maturing and would be “happy to be involved in the process.”