Open aliok opened 3 months ago
This is an Elephant in the room kind of question.
No one?
I start:
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'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.
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.
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.
Sorry, I missed this earlier. I sort of wrote a book with some of my ideas, so I'll be brief:
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:
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.
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).
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.
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?