点击查看目录
OAM 和 Crossplane 社区共同致力于建设一个聚焦在标准化的应用和基础设施上的开放社区。
前言
在 2020 年三月份，在来自 Crossplane 社区的协作和巨大贡献下，开放应用模型（即 OAM）项目发布了其v1alpha2 规范，旨在为 OAM 本身和任何采用 OAM 的 Kubernetes 应用平台带来绝佳的可扩展性。在 2020 年 5 月份，随着 Crossplane 最新的 v0.11 版本发布，Crossplane 现在具备了 OAM 规范的标准实现。我们十分激动看到两个社区间的合作，合作将标准的应用和基础设施定义与实施一起带入了云原生社区。
旅程的开始
从 Kubernetes 工程师的角度来说，我们很接受现在的 Kubernetes 抽象层级：容器和基础设施 API 资源。但是对于平台的终端用户而言还是太过底层。
为了在一定程度上提高终端用户的体验，一些团队试图通过引入 PaaS 或者 GUI 来向终端用户隐藏 Kubernetes API。初看上去，这似乎是一个好主意。但事实上，这极大的限制了平台的能力。Kubernetes 资源模型强调系统的所有能力都要能够可以表达成"数据"，例如 API 对象。向终端用户隐藏这些对象本质上会使得你的 PaaS 缺乏可扩展性，因而无法利用在生态圈中数不胜数的插件的能力。
带着我们必须使平台构建者能够定义应用级别的抽象而不引入对平台可扩展性限制的理念，我们开始探索这个领域。
建模你的应用，而不仅仅是描述
因为我们要定义应用级别的抽象，那么第一个问题就是：什么是应用？
一个现代应用通常是若干部分的组合 (如上图所示)。这样的模式广泛存在于现实世界：多层应用，机器学习训练应用（参数服务器和工作节点），更不用提微服务架构。但是经常被遗忘的是，这些应用的组件经常需要绑定一系列的运行策略。另外，分组策略也是一个特殊类型的运行策略。例如，我们需要在一个组内设置多个组件的安全组。
因此直观的方法是使用 CRD 作为描述应用的高级抽象。并且这样可以与应用运行所需的所有其他部分（如运行策略、基础设施）一起合并成一个 YAML 文件，如下：
上面的这个例子其实就是阿里巴巴“应用”定义的 1.0 版本。可以想象，开发人员会抱怨这样的“应用”太过于复杂，尽管它的初衷是使他们的生活更加简单。同样的，我们发现维护这个对象十分的混乱，并且基本上不可能扩展。更糟糕的是，越来越多的能力被安装到我们的 Kubernetes 集群中，这些都需要加进这个对象——Kubernetes 社区发展的十分迅速！
事实上，如果你仔细检查上述 YAML 文件，会发现开发者真正关心的只是运行他们应用的定义里的一些较小片段，如"commands"和"package"。
因此为何我们不把这个 YAML 分解成多个片段呢？开发人员只需要根据他们自己掌握的部分定义"运行什么 (what to run)"，运维人员（或者系统管理员）定义运行策略，基础设施运维人员处理基础设施部分。
在接触了社区中的各个公司之后，我们发现“关注点分离”的想法与微软的团队非常契合。在与微软经过了数周的合作之后，我们定义了如下的顶层草图：
看到了吗？与 all-in-one 式的 CRD 把所有东西揉在一起不同的是，OAM 的核心思想本质上是一个"框架（frame）"。因此，开发人员和运维人员可以在整个应用表单的“空格”里填充他们自己片段的数据。这种灵活性保证了任何平台都可以采用这个定义而不会受限于特定的工作负载和能力类型，并且这个系统可以支持任何工作负载（容器、函数、甚至虚拟机）与运行能力（例如 autoscaling、ingress、security policy)。
我们称这种方法为“应用模型”，因为当一个用户需要组合多个片段为一个应用时需要遵循这个规范，他们需要去思考哪些空白需要去填充，例如是否是描述“运行什么”？或者是否是运行策略？这个过程和数学建模十分类似，数学建模使用数学概念和语言来描述系统。我们现在使用 OAM 概念来描述应用的不同部分。好处是现在平台可以理解这些不同片段的类别，这样可以保证片段的拓扑，或是检查运行策略的兼容性——可发现性和可管理性是现代产品级应用平台的核心。
我们最终将这个理念发布为OAM spec v1alpha1
Crossplane + OAM：构建 Kubernetes 之上的现代应用
OAM spec v1alpha1 在阿里云的企业级分布式应用服务（EDAS）以及内部平台上得到了快速采用。然而，我们同样发现了一个在"运行什么"片段中的问题 (之前称之为ComponentSchematic)，我们需要发布新版本的 ComponentSchematic 来进行 YAML 中的任何修改。这是因为它被设计成了一个模式（schematic）对象，因此开发者可以定义他们需要部署的任何工作负载并与他人分享。一个类似的问题同样存在于运行策略部分（我们称之为"traits"）——它的模式同样将 schematic 暴露给了终端用户。
在 12 月份举行的 KubeCon 北美大会上，我们会见了来自 Upbound.io 的 Crossplane 维护者。我们讨论了 OAM，以及如何通过利用 CRD 作为模式 (CRD as schemas) 的方法将 OAM 规范与 Crossplane 无缝集成。我们都认为这个方向是有希望的，在经过了数月的头脑风暴，提案以及无数次的激烈讨论之后，这个想法最终演进成为了如下的 OAM spec v1alpha2:
OAM spec v1alpha2采用了 Kubernetes 资源模型，因此 Kubernetes 中的任何数据片段都可以通过简单的定义一个 WorkloadDefinition 或者 TraitDefinition 来无缝引用为一个 OAM 中的工作负载或者特征 (trait)。一个关于 OAM spec v1alpha2 的更深入的博客即将发布，这里可以先看看一个详细的说明。
在实现方面，我们开发了一个基于 Go 的实现版本，称之为oam-kubernetes-runtime，作为Crossplane的一部分。现在我们有一个用于 OAM 的标准 Kubernetes 运行时。
组合：完成整个图景
就像你可能看到的，我们仍然缺乏关于 OAM 的一个部分：我们如何定义组件依赖的基础设施片段，例如，一个来自阿里云 MySQL 数据库实例（RDS）？如何使这个定义适用于不同的云，就像 OAM 组件那样。
在 Kubernetes 中定义这样应用中心的和可移植的基础设施绝非易事，社区中有一些 operator 和产品来做这个事情，但是没有像 Crossplane 中的 Composition 那样好。Composition 组合多个基础设施片段，然后将其发布到与平台无关的 CRD 中，例如组合 CRD 来将 VPC 与 RDS 描述为一个新的数据库 CRD。这个 CRD，可以在之后引用为一个 OAM 的 WorkloadDefinition 并且成为一个应用的一部分。搞定！
组合的结果十分的有力，以团队为中心的平台，可以让基础设施运维人员为应用定义和组合供应商无关的基础设施，并且可以使应用开发人员和应用运维人员以 OAM 的方式定义，运行和管理可移植的应用，不用再关心基础设施的复杂性。基础设施运维人员现在可以管理运行这些应用的基础设施。OAM 和 Crossplane 一起提供了面向应用开发者和基础设施运维人员的优雅的解决方案。
下一步？
OAM 的核心理念是让开发人员描述自己的应用，使应用可以运行在一个无服务器平台，或者在一个本地的 Kubernetes 集群而无需修改应用的描述。这是阿里巴巴和微软一直在努力的云边协同（cloud/edge consistency）故事的一部分。很明显，与 Crossplane 的合作弥补了这个故事真正实现所缺失的重要部分，那就是在一个系统中同时涵盖统一的应用定义和基础设施定义。我们将继续努力使 Crossplane 成为 OAM 的标准 Kubernetes 实现，并且具有更好的工作负载/特征可移植性，互操作性，丰富的运行能力；构建一个聚焦于标准应用和基础设施的开放社区。
（原文地址：OAM and Crossplane: The Next Stage for Building Modern Application）
