Knative Serverless Kubernetes Is Off to a Bumpy Start
I really like Knative. It’s the cloud native computing answer to Amazon Web Services‘ (AWS) Lambda. It’s an open source community project which integrates serverless, cloud native applications with Kubernetes. The name of the game is to enable developers to focus on their code and eliminate the donkey work of provisioning and managing servers. But I’m not too keen on Knative already making it to the 1.0 level.
It’s just a version number, but when I see 1.0 today, especially in an open source project, I expect a program that’s had years of production use. I expect mature code that’s as trustworthy as anything ever is. That’s not the case with Knative 1.0.
Instead, as the release team comes right out and says, “Knative is composed of many components that are versioned together. Those components have different levels of maturity, ranging from ‘experimental’ to ‘already GA’ (Generally Available). We still want to keep the versions in sync, and so have decided to move all components to version 1.0. GA levels are marked for components individually.”
Experimental? In a 1.0 release? Really?
Why? They explain, “Two reasons: one user-facing, and one contributor-facing. The big, user-facing reason is that it gives users a single number to hang on to when understanding what they’ve installed and what works together. The smaller, contributor-facing reason is that all our infrastructure is designed to manage a single version number, and updating it to support multiple version numbers doesn’t seem like a good use of time given the first point.”
Really? I don’t have any trouble with multiple versions of programs underlying a single platform. I mean, we run Linux, don’t we? Are you confused? I’m not.
As for your infrastructure being set to manage a single version number… Well, I wouldn’t do that, but whatever.
Going forward they add, “Unless we wait for everything related to Knative to be done, we’ll always have some components or features that are in an alpha or beta state. While this sometimes happens along a component boundary, it can also happen within a component, so the version number can’t be a sole indicator of ‘GA or not.'”
They also add that the project “will be clear about the maturity level of various components or features, and moving features along the path to either GA or retirement.” You know that seems to me like a lot of words to describe something that most of you use version numbers for without any problems.
What does all that mean? Knative’s core components, such as Serving and Eventing will be generally available (GA). The various extension components, including serving/eventing features, net-* plugins, channel/broker, and sources will be in Alpha, Beta, or GA state. To see what’s what with each component, you’ll need to look into their README.md or documentation pages.
This still sounds confusing to me. It doesn’t help any that Knative’s always been a bit confusing. It started with three separate parts: Serving, Eventing, and Build. Knative Build was spun out and became the Tekton project.
Today Knative gives you eventing and serving. As Google software developer Ahmet Alp Balkan put it, “This creates confusion that likely impaired adoption decisions because the project really does two things; not one. It’s perfectly normal for a developer trying to learn more about Knative to ask questions ‘do I have to use both,’ ‘can I install them separately,’ and end up not using the project due to perceived complexity.”
Still, as Balkan pointed out, “it brings a ton of features like request-based autoscaling, concurrency controls, meat shielding, reproducible deployments (revisions) with traffic splitting abilities, rollbacks, out-of-the-box telemetry, scale-to-zero and so on that developers actually care about.
All this aside, here’s what Knative 1.0 brings to the table. It will enable you to use an event-driven architecture with serverless applications. Specifically, it:
- Provides fast, stand up scalable, secure, stateless services.
- Has a focused API with higher-level abstractions for common app use-cases.
- Offers pluggable components, which will enable you to bring your own logging and monitoring, networking, and service mesh programs to bear.
- Can theoretically run anywhere you can run Kubernetes.
- Features support for multiple HTTP routing layers. This includes Istio, Contour, Kourier, and Ambassador
- Provides support for HTTP/2, gRPC, and WebSockets.
- Supports GitOps, DockerOps, and ManualOps
- Supports many common programming tools and frameworks such as Django, Ruby on Rails, Spring, and others.
Looking ahead, Knative will be moving to an extremely fast six-week release code. Will users adopt it? It’s already popular and it has great potential.
As Balkan observed, “Knative Serving is a lot more useful beyond just being a ‘building block:’ I think it is the missing serving layer for running microservices on Kubernetes.” And, “If all you are doing on Kubernetes is to run services, you can just use the Knative Service API and touch pretty much nothing else in Kubernetes.”
