The announcement last week that Knative would not be donated to a foundation anytime soon was met with disappointment from many quarters.
Donna Malayeri, a product manager for Google Cloud Run and a member of the Knative steering committee, wrote that its future would be a steering committee decision, and it would be posting information on how project members can attain leadership positions with the group.
A couple of weeks ago, analyst, and regular TNS contributor, Janakiram MSV posited that “Knative has the potential to become the preferred serverless platform for k8s,” asking what should become of it.
The responses to his tweet clearly favored a home with the Cloud Native Computing Foundation, the home of Kubernetes as well.
Google released Knative in July 2018 as a way for organizations and service providers to set up a serverless infrastructure that can run the same containerized code across multiple public clouds or in-house with minimal customization.
“The whole point of Knative was to bring the building blocks of serverless together and give you this workload portability,” said Oren Teich, director of product management for Google Cloud, at the time.
Pivotal, IBM, Red Hat and SAP also have contributed to the project.
Knative’s key motive is to define vendor-agnostic standards for serverless computing, guest blogger Twain Taylor wrote in a recent post.
In an interview, Teich described Knative as a set of components to run applications on top of Kubernetes.
“[There are a] set of customers who have Kubernetes clusters, for many reasons … but they want the developer experience that a serverless platform offers,” he said. “If I have a stateless container that responds to HTTP, how do I get it up and running?
How do I scale it? How do I deliver events to it? How do I build it? How do I really make that developer experience from Day 1 as easy as possible?”
Knative is made of two loosely-coupled components:
- Serving provides the ability to easily run applications/functions and scale them. It takes care of getting your container running and handling everything from ingress, traffic splitting, deployment revisions and more.
“It also introduces some nice scale-to-zero components. I don’t mean the Kubernetes cluster itself scales to zero. If you’re running a service that responds to HTTP, in Kubernetes land, traditionally you’d always have to have that sitting there running. You could scale to 1. This can scale all the way to zero … It enables you to run very high quantity lightweight serverless workloads without resource strain on top of Kubernetes as well as great developer experience,” he said.
That serving part of Knative is scheduled to go to 1.0 very soon.
- Eventing allows apps/functions to publish to, and subscribe to, event streams such as Google Cloud Pub/Sub and Apache Kafka. It provides all the infrastructure for handling eventing — integrating with third-party systems and getting events delivered into your application and wired up and the control plane APIs.
It is the less mature of the two and will be the focus of future work, Teich said.
Initially, a third component, called Build, was part of the project, but since has “graduated” out and now is part of the continuous integration/continuous delivery (CI/CD) project Tekton, called Tasks. It provides a pluggable model for building containers from source code.
SAP’s Extension Framework
“When we started in this space, there were a lot of different projects. We counted well over a dozen. When we talked to customers, they wanted portability, they want to not feel locked in and they wanted capabilities, some of them that were very special purpose,” he said.
In the process of building Knative, some of the players in the space re-platformed on top of Knative.
SAP was one of them.
In late 2017, it started building a new side-by-side extension framework that was to operate across all product lines due to the need to provide rapid innovation in its Commerce Cloud space.
“We were 100% sure that we need a serverless architecture as the base of it and the combination of Kubernetes and Istio seemed to be the logical foundation for this at the time. We didn’t know that in the meantime, Knative is also being forged behind closed doors at Google,” said Krasimir Semerdzhiev, chief architect for SAP C/4HANA Core.
“In the course of our development, sprint after sprint, we kept enhancing the experience of building serverless functions. We abstracted away from the complexity around container networking on Kubernetes and took care of all the required transport encryption and security by leveraging Istio. Events were a central part of our story, as we envisioned business events to be the trigger in many of our extension scenarios.”
It unveiled its alpha product to select partners in early spring 2018 to positive reviews. The team first learned about Knative just before KubeCon Europe in Copenhagen, and after an introductory call, quickly realized the potential for future collaboration.
“On both sides, we’ve identified and addressed a very similar problem domain. Google approached it from the perspective of building and running applications, putting extra focus on lifecycle management (build, deployment, traffic management). On the SAP side, naturally, we have put additional emphasis on connectivity to business applications, standardized service consumption from multiple vendors, and reuse of already defined functions to build higher-level execution flows,” Semerdzhiev said.
They found the two projects complementary, and SAP decided to realign its Kyma open-source plans to run on top of Knative. At Google Cloud Next, both were announced as part of the serverless session.
“One and a half years later, we’ve come a long way forward. We’ve pushed some contributions (NATS Streaming Channel implementation, minor fixes) to Knative, as well as to several other related projects (AsyncAPI, Istio, etc.),” he said.
“We believe that Knative will be for serverless what Kubernetes is for container deployment and orchestration. … Going forward, we see the success of Kyma being closely related to the success of Knative. Both play a crucial role in the side-by-side extensibility strategy of many companies, spanning beyond SAP itself.”
Project Kyma is a side-by-side extension framework that SAP envisions to be sitting next to enterprise applications both in cloud and on-premise. It enables developers to react to events across multiple enterprise applications and develop lightweight lambda functions.
SAP has been developing products in the enterprise software market for more than 40 years, many of them heavily customized for customers.
“Having a lot of custom code sitting across multiple products turns to be a considerable hurdle for upgrades, patches, and further evolution of the business apps,” said Semerdzhiev. “That’s why we started project Kyma as a side-by-side extensibility framework, which can be placed next to any product, enabling customers and partners to innovate at their own pace and schedule, planning their digitization and expansion towards cloud offerings.”
Google also built its Cloud Run offering on Knative. It’s a managed platform that takes a Docker container image and runs it as a stateless, autoscaling HTTP service. It allows you to run arbitrary applications serving multiple endpoints, not small functions with a specific interface.
The ecosystem continues to grow. IBM initiated support for Knative as part of its managed Kubernetes service in February. One of its new open source projects, Appsody, aids developers in quickly creating microservices to their organization’s standards and requirements using pre-configured stacks and templates for Kubernetes and Knative deployments.
And in May, Red Hat unveiled a developer preview of Knative as part of OpenShift 4.
The Cloud Native Computing Foundation, Pivotal and Red Hat are sponsors of The New Stack.