A CRD controller is expected, especially it will allow your clean up logic long running in cluster or periodically. But writing code inside YAML is very weird, at least there are CEL as option here.
> The 10M context ability wipes out most RAG stack complexity immediately.
This may not be true. My experience of the complexity of RAG lays in how to properly connect to various unstructured data sources and perform data transformation pipeline for large scale data set (which means GB, TB or even PB). It's in the critical path rather a "nice to have", because the quality of data and the pipeline is a major factor for the final generated the result. i.e., in RAG, the importance of R >>> G.
Really nice project, and really hoping these efforts could make devs lives easier! Alibaba indeed built a OSS project named KubeVela (https://kubevela.io) with similar goal though with a bit different approach:
1. Modeling all platform capabilities with Helm/CUE modules, so essentially a PaaS built with Helm/CUE.
2. Self-service workflow based on above LEGO-style components.
3. No specific add-on system, so just Helm charts.
We also auto-gen forms based on Helm/CUE, it's great more and more products are leveraging this capability and wider ecosystem.
It's great to see enterprises like Alibaba build out these types of internal developer platform (IDP) around Helm. We've talked to the engineers who built out these IDP's at different companies because we wanted to build a generalized solution that is not specific to one company's devops culture. We hope to democratize IDP's to smaller companies who can't afford to build things out themselves internally!
Reusing Kubernetes Resource Model to build app-centric platform have many benefits:
1. Work seamlessly with any CI CD solutions which work with Kubernetes.
2. Clarity in api versions in the spec entity.
3. Adopt widely used best practices such as metadata, spec & status.
Overall, we should be aware that the complexity of Kubernetes does NOT lie in its api model (Group, Version, Kind etc). Also, an abstraction adopts this model does not leak anything in underlying Kubernetes runtime.
The shoveling of "Cloud Native" is in part a bid to sell cloud services at AWS, Azure, GCP, Oracle, Alibaba, etc. Just because the engineers on the ground doing the work conveniently ignore this point doesn't mean that the executives who ultimately green light and fund these projects aren't considering it the #1 priority.
More and more applications will be built on cloud with or without "cloud-native", we can't stop this trend or arguing technologies that intend to make this process smoother/easier.
And yes I agree those cloud providers will make more money with this trend.
Actually, almost every big company built massive abstractions on top of Kubernetes and it is what Kubernetes is designed to do (and good at).
That's why if you had a chance to look at Dokku and any other "better" self-hosted PaaS offerings, they are dead. Ppl today choose to use Kubernetes to build abstractions atop and OAM is a battle tested option to achieve this with better clarity and interpretability. Many companies are shifting away from Cloud Foundry and OpenShift to this approach.
Complaining OAM should not be implemented on K8s doesn't make sense to me.
Kubernetes is NOT a PaaS, it's by design for you to create abstractions atop and serve your own purposes. And OAM is a great option if you want to build things like app PaaS or app delivery systems with k8s.
It seems you either have mis-understanding on OAM or Kubernetes, based on you are involved in OAM, it's likely the later case.
