为了解决业务用户到k8s-api之间的鸿沟，大致有两种直接的方式。第一种就是把业务变成k8s专家，这样业务方就可以直接使用k8s而不会出现不会用不好用的感受，但这会导致一个很大的问题，就是业务发开的认知负荷爆炸。

另外一个看起来也很直接的解决方式，就是由我们的k8s工程师和平台工程师，充分利用k8s的能力，去构建一套面向用户的应用管理平台。面向用户，意味着，我们的模型或API是业务侧熟悉和理解的。 具体的，可以在k8s上面，搭建一个上层的应用管理平台，对业务研发和运维暴露上层的API，这个API可以但不限于底层的pod，deployment之类，更多是业务易于理解的。比如对于研发暴露一个CICD流水线，或一个webservice应用。

对于运维，暴露一组诸如扩缩容、发布策略、流控等这样的经过抽象后的API。这样，研发和运维就会跟之前一直接触的devops流水线或用户体验有一个更好的结合点。

问题来了，如果我们在k8s上架起一个Paas平台，就会使得k8s的底层无限能力没法向最终用户透出。换句话说，如果在k8s繁荣多样的基础设施能力，和用户日益增长的应用管理诉求之间，存在一个传统paas，那paas就会成为一个瓶颈。

第一个，平台必须提供用户友好的API，这是最基础的要求。要做到用户友好，我们必须站在用户或业务的角度思考问题，或者说以应用为中心。 第二个，就是打破传统paas的瓶颈，做到高可扩展，而高可扩展的核心就是能无缝衔接k8s，从而用上k8s的无限扩展能力。综合起来看，我们其实要打造的是一个以应用为中心的k8s。

首先，最核心的地方一定是k8s， 也就是蓝色的这一条。 我们可以很容易的在k8s上定义一组crd和controller， 自然可以用crd做我们的用户侧API， 比如说pipeline就是一个api，同理，运维侧的扩缩容、流控等都都可以通过crd装起来。 这就解决了我们的第一个问题--应用层抽象。做应用层抽象，基本上等同于写crd+contoller

另一方面，k8s内置的controller或能力是有限的，绝大多数能力都是通过社区提供的。为了充分利用社区的这些能力或应用层驱动，我们必须有一个统一的插件管理能力。把支持的能力统一管理起来，使用户能够方便的查找和使用特定能力。

要构建这样一个应用管理平台，有没有开箱即用的方案呢？答案就是OAM，开放应用模型，OAM是一个 构建以应用为中心的管理平台的 标准和规范。OAM专注于三个层次 。第一个是应用层抽象，这层定义的第一个抽象是component，帮助用户定义应用的workload如deployment，statefuset等等。 第二个概念叫应用特征， 把运维侧的能力 通过一个叫trait的概念暴露给用户。然后我们需要把运维特征也就是trait关联到我们的组件， 比如我们的depoyment组件，可能需要某种扩容策略或发布策略 ，这个就是application的概念。 这些概念的背后都是crd， 当我们把application组装好，就交给OAM的runtime ，runtime会把这些component和trait进行解析，最后交给k8s运行起来。