Where do you see Knative in 5 years?

[aliok]

Hello @knative/steering-committee , @knative/technical-oversight-committee , @knative/ux-wg-leads , @knative/client-wg-leads, @knative/serving-wg-leads , @knative/eventing-wg-leads , @knative/security-wg-leads

I am curious about your opinion here. Where do see Knative in 5 years?

Reason for bringing this up is, it has been 6 years since Knative was open sourced and Knative's value proposition is also 6 years old. Do you think we've stayed up-to-date with the value proposition? Would the current value be valid in 5 years? Do we need to pivot? Or, have we pivoted enough?

[cardil]

This is an Elephant in the room kind of question.

[aliok]

No one?

I start:

Serving

Serving is still very valuable IMO. However, not as a serverless enabler, but more as a better and simplified deployment.

The scale-to-zero part might/will be (Serving WG can talk better about this) kind of obsolete if/when Gateway API implements such feature. AFAIK, it is coming.

All the other benefits (TLS provisioning, simplified deployment, auto networking, etc.) IMO would be still very valuable, but there could be other projects providing these benefits. In that case, we should probably market Serving as something else.

With the AI hype, there's a huge opportunity for Serving, but, we need to work towards integrating Serving with other Cloud Native AI projects. Serving is actually in a position to be true enabler for AI workloads and I think we should focus more on that.

These are my opinions though. I am really curious to see what other vendors think. Would you like to protect status quo? Would you like Serving to evolve towards AI enabler? Anything else?

Currently, there's contributions from Red Hat and Broadcom mostly. Do we think this would change ever?

Eventing

Eventing's value proposition is still up-to-date IMO. However, do we think we have enough adoption? Or, will we have enough adoption in N years?

Similar to Serving, I think Eventing should focus on enabling AI workloads. Things like getting data in/out to/from AI opaque boxes. I think there's already enough functionality to support the initial value proposition: enabling cloud native microservices (my interpretation). That would mean more integration (e.g. more sources/sinks via Apache Camel) and more demos, etc.

Currently, Eventing is mostly driven by Red Hat, and we see some contribution from Broadcom. IBM, SAP and others dropped.

Functions

I don't see much uptake on Functions. I don't even know if there's any interested vendors/people in Knative community other than Red Hat. I can't talk about how much Red Hat emphasizes Functions, but if Red Hat is not successful making its customers use Functions, I don't see Functions effort sustainable. Again, I am not in the place to talk about Red Hat customer adoption for Functions.

[aliok]

IBM folks @lionelvillard @aslom and SAP folks @eric-sap @travis-minke-sap what do you think? Obviously, I can't know what Knative is/was used for in your internal systems, but would you see a way to get your employers contribute to Knative again?

@vaikas @mattmoor @n3wscott as founders of the project, do you see any opportunities for Knative? I'd appreciate your opinions.

[evankanderson]

Sorry, I missed this earlier. I sort of wrote a book with some of my ideas, so I'll be brief:

Serving

While serving is useful on its own for 12-factor-ish apps, it would be great to have it continue to develop as the general Kubernetes ecosystem makes it easier to attach supporting services. Examples of supporting services would include:

• Gateway API policy support. We're just starting to use Envoy-Gateway here at Stacklok, and being able to attach security and rate-limiting policies to the routes under Knative Services would be great.
• Documentation and maybe infrastructure support for attaching sidecars like Dapr. I'm personally not a huge fan of the "sidecar away all my interfaces", but if we're going to do that, we should at least avoid needing to repeat it explicitly for each Service in a cluster.
• Data push via OCI container volume mounts is exciting to me, personally -- this is a k8s 1.31 alpha feature that feels hugely useful for separating software from data and being able to package and push both independently.

I'd also generally like to see Serving support folks who want to experiment with adding things on top, like KServe (and security-guard). I'd love to see further experiments with durable execution like (I think) Restate is doing as well.

Eventing

See chapter 6 of Building Serverless Applications with Knative. In particular, I'd love to see Knative-shipped interfaces for Task Queues (both a push model and a pull model, both of which support some sort of "lease extension" and query/notification interface for task completions to allow chaining tasks outside of code), and Workflow orchestrators (again, supporting integration with existing pipelines and a design which scales to 100k-1M workflow invocations being orchestrated). It feels like the Workflow orchestration piece might be well-implemented using durable execution from Serving for the implementation (with an interface that would allow a non-Serving implementation).

Functions

Better documentation -- make it really easy for me to throw together a new function runtime that's suited to my particular problem. For example, maybe I'm doing processing of OSS repos -- I'd want a function which checks out the repo, puts it on disk, and then lets me execute my code against that.

I'd also like to see explicit support for Azure Durable-Functions style execution in some of the functions -- you'd need some sort of key-value backing store to save state between executions, but the model seems really interesting and worth exploring further.