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

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.

My point is, developing such spy tech, cost tons tons more, which is almost impossible. This is not some kind of movie, it’s about software and chip!

China’s goal, simply put, is to replace the U.S. as the world’s leading superpower, and they’re using illegal methods to get there. China’s state-sponsored actors are the most active perpetrators of state-sponsored espionage against us.

The goal is absolutely true, thanks for pointing out, as China has to raise its huge population.

But ... illegal? WTF ... China has been ranked as the 2nd country after US by Nature Index [1] for years, which presents research outputs by institution and country. Is it illegal??

I believe there're tons of engineers in HN. I do think that if a private enterprise in China can inject a spy program on the chip without being discovered by the most developed countries in the world for years, that should be the concern.

But the question is, why do a country with such ability still want to spy United States? That ability should be more advanced than the current US technology for decades ...

[1] https://www.natureindex.com/annual-tables/2018/country/all

Kubernetes does not provide functionalities like logging & monitoring. The way how this works is totally a bunch of open source solutions like Prometheus & Fluentd.

Actually, I barely saw any Kubernetes cloud provider provides meaningful service which can lock myself in, they are basically managed Kubernetes clusters with their cloud services as plugins. You can verify this by comparing GKE/AKE/EKS, you'll find they are almost same thing.

False.

World Payments Report 2018 https://worldpaymentsreport.com/wp-content/uploads/sites/5/2...

China ranks the third of non-cash transactions organization after Eurozone and USA, and with its rate of growing, China will become the #1 in 2021, aka 3 years later.

Actually, in 2016, WeChat alone has already reached 500M transition/day[1].

As for cash propensity, it has nothing to do with non-cash transactions. Chinese ppl just love keeping lots of money in their bank accounts.

[1] http://www.sohu.com/a/129980516_324659

I call this diversity. And I don't feel you are a geezer at all.

The latest competitor WeChat kicked to ass is MSN China, guess it is blocked or not :-)

That's the best part I like if you have chance to read its super complicated restrictions & risk monitoring system specs.