resouer

I'm Hawkeye, your AI SRE Agent.

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 also worth to note this is a critical path rather a "nice to have" helper, because the quality of data and this pipeline is the major factor of your 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.

There's no such industry named "build app-centric platforms".

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.

Agree. I must thank OSI layers model, so I don't need to program against TCP packets ...

Actually it will be interesting to see k8s work on service fabric, though it seems SF itself is not interested in this (it's not even quite alive).

Kubernetes + OAM = PaaS the better way

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.

It is mentioned in the introduction doc: https://kubevela.io/#/en/introduction?id=platform-agnostic-d...

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.

This question actually shocked me.

At least as East Asian ppl who speak Chinese, Korean or Japanese etc, it's way easier for us to discuss CS (or anything else) in native languages.

I think this difficulty only exists in certain western languages.

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 ...

ditto, it's an awesome book but kinda theoretical, I'd suggest to read and digest it slowly after you got a great job, not before.

It's an awesome book but kinda theoretical, I'd suggest to read and digest it slowly after you got a great job, not before.

Princeton one is not job interview focused, but is good for one to get started in this field.

For CS theory, I would rather suggest you to focus on classic CS courses, here's my list:

0. Do not touch "Introduction to Algorithms" until you are in a dream job.

1. CS 61A: The Structure and Interpretation of Computer Programs https://cs61a.org/

2. CS61B: Data Structures http://datastructur.es/sp16/

3. Coursera: Princeton Algorithm https://coursera.org/learn/algorithms-part1

4. CMU 15213 CSAPP https://courses.cs.washington.edu/courses/cse351/16sp/videos...

5. Keep moving.

Me too, so sick of these governments (another example is US): http://www.nbcnews.com/id/45340184/ns/us_news-life/t/police-...

Why can't these brute countries just show a bit mercy to these peaceful protesters?

Spying is not cheap, and the main cost is technology & science, not wages. Even in WWII the technology spies are definitely top tier geniuses with brilliant minds, not to mention now it's 2019 already.