我要唱一句反调：** 不要看 Kubevela ，不要看 OAM 。**

关注点分离和 DevOPS 本身就是截然相反的两条路，K8s 作为后 DevOps 时代催生和成熟的平台，如果倒退回传统 Dev and Ops 的话， 那么 K8s 对开发/运维个人而言价值就大大下降了。

1. 对开发而言，看到了一个尝试抽象了的，但是处处抽象泄漏的、蹩脚的页面。如果对于 Java 程序员本来就是部署一个 Jar 包，连 Image 都不会打的那还好说。但是如果部署一个现成的 Chart 的时候，反而需要拆碎了去页面上点来点去点半天，出了问题去找平台解决一些本来可能不存在的问题。

2. 对平台而言，不管是用的 Mesos ，Swarm ，还是别的自己糊的系统，用什么不是用呢？区别只是用了 K8s 能自己少写几行代码，免费白嫖几个开源解决方案而已。如果之前有自己的系统，因为长期糊屎维护不下去的时候，领导一拍大腿迁移上 K8s ，一两年的 KPI 又有了。

3. 对运维而言，反正都是 oncall ，调监控，重启机器而已。

总之，OAM 是妥妥的反模式， 一个好的码农不应该被限制在一个固定的视角上，被告知什么应该关注什么不应该。