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.
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.
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.
It’s a huge misunderstanding that the competitive advantage of China is cost of human resource, otherwise Tesla should build super factory in India or South Asia countries.
The short answer is Waypoint is a dev facing tool but KubeVela mostly focus on platform team side. So one could integrate Waypoint to KubeVela if needed.
Unfortunately, that's not what OAM could provide to you.
OAM is just a contract between dev and ops so ops could tell what he has (Trait) in a way dev understand, and dev could tell ops what he want (Components) in a way easy to manage by ops. That's all.
OAM is the app mgmt API for K8s, while not only for K8s. So implement it firstly on K8s is a natural choice. You may argue hey why I need app mgmt API for K8s. Well, have you ever tried to expose full Deployment api for developers to describe their app? My personal experience is super messy ...