OAM角色定义

https://github.com/oam-dev/spec/blob/master/introduction.md

关注点分离

开放应用程序模型提出了开发人员负责的部分与平台工程师负责的部分之间明确的关注点分离。

Open Application Model proposed a clear separation of concerns between the parts that developers are responsible for, and the parts that platform engineers are responsible for. 

角色定义

以基于故事的格式介绍开放式应用程序模型的角色。尽管这不是可能角色的详尽列表，但是这些角色被确定为本规范的主要目标。

• 开发人员****Developers：以代码形式交付业务价值。尽管他们应该了解所交付代码的操作特性operational characteristics，但他们并不关心_如何_满足操作要求。例如，开发人员可能知道他们的代码将数据写入文件系统上的特定路径，而不必自己关心将哪种类型的卷（磁盘）装入该路径或如何实现这种依赖性。
• 应用维护者****Application operators：通过配置，安装和管理组件和/或应用程序（例如更新，扩展，自动恢复等）来交付业务价值。与开发人员和应用程序 composers 不同，维护者关注如何满足组件或应用程序的操作要求。 例如，如果开发人员声明组件将数据写入文件系统上的特定路径，则操作员保证在该路径上安装了适当的卷。
• 基础架构维护者（也称为平台构建商）通过构建以应用程序为中心的平台并管理底层基础架构组件来创造价值。 范围可能从管理本地网络中的物理硬件到直接管理公共云中的云服务产品。 基础架构运营商不太关心应用程序的特定配置需求，而是关注于如何管理企业整体基础架构的全局。 例如，基础架构运营商可以管理用于供应持久性存储的基础存储产品。

案例

我们将讲述一个故事，该故事描述了基于OAM平台的应用程序交付生命周期。故事情节如下所示：

1. 基础架构运营商决定平台上哪些可用的基础工作负载类型和运营功能可用于处理部署和运营。
2. 开发人员创建一个Web应用程序，定义其特征；
3. 应用程序维护者或平台本身会实例化该应用程序，并使用自动扩展等操作特性对其进行配置。（实际这就是运维要做的，基于k8s，创建出kubevela，基于kubevela构建一些应用供开发人员使用）

基础架构运营商：维护平台功能

开放应用程序模型(Open Application Model)的最强大功能来自实现该模型的底层平台（underlying platforms that implements the model），这些平台可以通过OAM以在支持该模型的任何平台上都一致的方式，提供使底层平台具有唯一性和实用性的功能。

基础架构运营商负责声明，安装和维护平台上可用的基础功能。

下图演示了平台架构：

借助OAM，基础架构运营商和平台维护者可以从 Components, Traits, and Scopes 格式的可重用模块（reusable modules）中受益。

允许构建以应用程序为中心的平台，这些平台将这些更高级别的抽象作为应用程序级别的API公开，或将它们组合到预定义的应用程序模板中。开发人员可以通过选择模板来选择如何运行其应用程序，例如，具有较高SLO要求的微服务应用程序，具有持久卷的有状态应用程序或具有水平自动缩放功能的事件驱动功能。归功于模块化设计，这以云原生方式为终端用户带来了无服务器serverless 的体验。

同时，OAM本质上支持跨运行时的可移植应用程序定义。如果一个应用可以在一个提供商上部署和使用，那么它应该能够在任何其他提供商上运行。我们在 core, standard, and extended API 中定义必须实现、推荐和候选类型。这将确保可移植性，并在同一规范中提供可扩展性。当然，并非所有东西都是可移植的，这种接口的主要关注点是它是一个“最小公分母”。我们的目标是构建一个与供应商无关的、社区拥有的规范，随着时间的推移，最流行的api将被接受并添加到规范中。这样，演进将确保大多数用户能够通过开放应用模型成功地定义云原生应用程序。

应用程序开发人员：编写和测试代码

假设基础架构运营商已经使用某些运行时系统构建了基于OAM的平台。

一个在线购物应用的开发人员知道如何编写和测试代码。应用程序采用一些参数，例如日志级别和HTTP端口。为了让开发人员专注于实现应用程序的业务逻辑，我们让应用程序维护员（人工或自动操作平台）负责操作任务。这为应用程序开发人员提供了“serverless”体验：他们只需要开发和打包应用程序，然后将其交付给运维即可。

要交付其应用程序，开发人员需要定义_Component YAML文件。在_OAM 中，程序开发人员将程序的每个单独组件描述为 Component__ YAML。该文件封装了 工作负载workload 以及运行它所需的信息。例如，它可以包含包装程序的容器映像，是否需要终结点endpoint 。

下图演示了此工作流程：

应用程序维护者：部署和操作应用程序

为了运行和操作应用程序，应用程序运维为开发者的components 设置参数值，并在 ApplicationConfiguration yaml 中应用操作特性，例如副本大小replica size，自动缩放策略autoscaling policy，入口点ingress points 和流量路由规则 traffic routing rules 。在OAM中，这些操作特征称为_traits。编写和部署_ApplicationConfiguration yaml 等同于部署应用程序。基础平台将创建定义的工作负载的实时实例，并根据ApplicationConfiguration 规范(spec)将 operational traits 附加到工作负载workloads。

应用程序维护可以是平台本身，即自动化操作平台（automated operation platforms）将根据应用程序开发人员的意图将 traits 分配给components 。在小型组织中，应用程序运维和应用程序开发人员可以是同一个人，但此人仍遵循OAM工作流程，以自助方式分配特征，并清楚地知道他/她正在任何地方配置可部署组件或运营能力时间。此人仍然遵循OAM工作流，以自助方式分配特征

但是我真的没有“应用程序维护者”角色

在许多组织中，应用程序操作员角色并不是一件常事。在这种情况下，应用程序开发人员自己负责配置特征和部署应用程序（例如DevOps），或者该平台实际上采用“serverless”风格，因此只要应用程序工件准备就绪，系统将从此处接管（例如NoOps）。

在DevOps工作流程中，明确定义哪个部分是application component ，哪个部分是operational configuration，是避免由于 mixed mindsets 而引起的通信事故，错误甚至服务中断的关键。例如，在推出应用程序组件的版本时，我将选择同时禁用自动缩放trait。

在NoOps工作流程中，OAM很自然，因为平台本身将充当应用程序运维的角色，并根据应用程序的特性自动为组件配置特征（例如，组件是否为公开服务？是否可复制？）。