The Knative serverless project recently graduated from the Cloud Native Computing Foundation (CNCF), capping a multi-year journey for the Kubernetes-linked cloud-native platform and setting the stage for Knative to support an expected explosion of AI-generated applications.

Dave Protasowski, who is a Knative steering committee member and serving lead, explained to SDxCentral in an interview that the CNCF graduation was the result of Knative’s steering committee working through refinement of the project. This work was mostly focused on cleaning up documentation, “rather than anything critical that we needed to change in our governance structures.”

CNCF noted that to officially graduate, projects need to normalize their governance documentation, merge distinct committees into a single steering committee, define annual elections and the project maintainer lifecycle, and document contributed processes.

“We did simplify a whole bunch of things,” Protasowski said, adding, “but since 1.0, a lot of those things have been very stable.”

The Knative project was launched in mid-2018 with a focus on providing 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. Google was the initial founding vendor, and IBM, Red Hat, VMware, and SAP also contributed to Knative's development.

That development followed in the shadow of the Kubernetes container orchestration project, which also sprang out of Google. Knative was viewed as the serverless equivalent.

Broadly, Knative provides 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 targeted at unchaining 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.

The project hit its 1.0 status in late 2021, and soon after it was adopted into CNCF.

Knative’s development focus

Knative’s development has been focused on two specific functions: serving and eventing. Serving is targeted at reducing developer effort to manage autoscaling, networking, and the rollout of stateless services on Kubernetes. The eventing focus is on exposing event routing that is used to trigger a function between on-cluster and off-cluster components.

Knative has also been more tightly integrated into other cloud-native environments. It’s linked with the CloudEvents specification for interoperable events; the Knative Functions component integrates with Buildpacks; and it shares base packages with the Tekton project.

Protasowski touched on a number or project roadmap items, including updates to eventing that will allow for synchronous and asynchronous workloads. This will allow clients like model context protocol (MCP) or legacy applications to communicate with applications built on newer platforms.

There is also work on the eventing side, with Knative adopting Gateway API to simplify the networking stack and provide safer container settings as a default in support of a more robust security posture.

Maintainers also contribute features to the Gateway API in order to support Knative workloads. As a Kubernetes-native project, it also complements other cloud native technologies such as observability, networking, and security.

Knative’s AI opportunity

This history and work has set Knative up to be an important option for AI-generated application development.

Serverless platforms act to abstract away resource management from lower-level container or virtual machine (VM) infrastructure. They basically allow developers to set an application to run by allowing the underlying component to decide where the most efficient resource is to run that application.

This also allows serverless platforms in general to scale to zero, or to not use any infrastructure resource when it’s not needed. This is as opposed to containerized or VM infrastructure that always require a minimum of resources.

Protasowski explained that this structure aligns with the growing base of non-technical developers that can use AI to produce applications.

“The exposure of this much wider audience just means the number of apps that will need to run will grow,” Protaswoski said. “I view it from this point of, if you're having your whole workforce that can kind of write these one-off apps, they might only be using them during work hours or maybe for their team. This is where I can see what's going to be the compute demand then for all these apps. And this is where I think, especially if you're a customer and you have on-premises clusters, that scale-to-zero would be very crucial.”

Despite that explosive opportunity, Protaswoski did note that the Knative team is maintaining a goal of paced development. This means plans for four releases per year and plenty of time to decide what is necessary as opposed to just adding something new for newness.

“mM personal goal is just that we don't want to regress,” Protaswoski said. “People have laid this as a foundational layer for a lot of their platform engineering teams, and we don't want to just say ‘we're going to break you because we feel like it’ type of thing, and kind of similar to how Kubernetes you could slow down releases just to have more predictable things.”