Score 和 Kubevela 的区别

本文将解释开放应用程序模型 (OAM/Kubevela) 和 Score 之间的一些主要区别，以帮助您决定哪个更适合您的场景。

以workload为中心 vs 以app为中心

Score 旨在提供以开发人员为中心且与平台无关的workload规范，以提高开发人员的工作效率和体验：它确保本地和远程环境之间的配置一致。Score 受到开发人员的喜爱，因为他们可以在完全不同的技术堆栈上运行相同的工作负载，而无需成为其中任何一种技术的专家。

推出后，我们收到了有关 Score 与开放应用程序模型 (OAM) 和 Kubevela 有何不同的问题。在本文中，我们将深入研究它。

Score是一种workload规范，可以通过Score实现的命令行工具（例如score-helm或score-compose ）实现转换到多容器平台的能力（例如 Kubernetes 或 Docker Compose ）。Score 将workload及其依赖的资源视为开发人员关心的基本部署单元。

Score不描述目标平台如何实现Score，因为它是声明性的。这意味着它没有规定如何在目标环境中供应资源依赖性和检索配置。

OAM（Open Application Model）是一个专注于开放应用程序概念的模型。这些应用程序由可编程模块组成，例如组件、特征、策略、部署工作流等。每个组件对应一个workload或资源，具体取决于定义的类型。OAM 提供了一些核心workload定义，你也可以使用CUE语言来创建新的定义。

这使得 OAM 在描述特定类型的应用程序时功能更加丰富和可扩展，但这也要求 Kubernetes 配备能够理解这些自定义资源的 Kubernetes CRD 控制器。

本地开发 vs 远程开发

开发人员经常使用 Docker Compose 等轻量级工具进行本地开发，因为这样本地开发环境更加轻量。 

借助 Score，开发人员可以将他们的 Score 规范转换为 Docker Compose 用于本地开发和 Kubernetes (Helm) 用于远程生产环境，而同时避免配置不一致的风险。

而对于 OAM 则需要依赖 Kubernetes 环境，对于本地的轻量化开发支持不友好。比如对于本地环境，您需要使用Kind 之类的东西来配置本地集群，并确保在您的本地环境中也可以找到远程集群上的所有组件。

Workload 管理

Score 旨在部署单个workload。这些workload之间的依赖关系可以在规范中明确定义为资源，但规范本身并非旨在在一个规范中描述和部署多个工作负载。

与此相比，OAM 允许您在一个规范中定义多个workload，尽管Kubevela不推荐这样做：

“由于我们将应用程序视为微服务单元，最佳实践是控制一个应用程序只有一个核心服务以进行快速开发迭代，该应用程序内的其他组件可以是依赖项，例如数据库、缓存或其他中间件/云服务，应用程序中的最大组件数应低于 ~15。”

从这个意义上说，OAM 为您提供了额外的灵活性来定义您的应用程序，而 Score 则坚持通过将单个workload和其他所有内容定义为依赖资源来使您的workload尽可能简单。

OAM vs Score 实现

在撰写本文时，Kubevela 是唯一的 OAM 实现。它通过安装Kubernetes CRD 控制器在 Kubernetes 中运行，使您能够定义应用程序。 

另一方面，Score 不需要在目标平台上运行任何组件，也不会创建额外的 CRD。Score 规范的实现是纯粹的命令行界面 (CLI)，可将workload转换为平台原生表示（例如，通过 Helm 在 Kubernetes 中部署或在 Docker Compose 中提供服务）。

这并不是说未来的实现不会包含允许您提供资源或配置的 CRD，这在很大程度上取决于未来的社区需求。 

资源配置

使用 OAM，您可以将资源定义为workload类型，并将它们作为组件添加到您的应用程序中。这些资源可通过 Kubevela 中的附加组件进行扩展，您也可以创建自己的资源。您还可以使用策略定义这些组件将如何部署在您的应用程序上下文中。

Score 允许您声明资源依赖关系，但它不会为您创建这些资源。由Score实现根据名称、类型或分数规范文件中可用的任何其他元信息以目标环境中的平台可以使用的方式解决资源依赖关系。

简单 vs 功能丰富

Kubevela 和 OAM 的功能比 Score 丰富得多，因为它涵盖了一组额外的用例。如果您正在寻找一个持续部署平台来呈现、编排、部署和管理您的应用程序，那么这非常好。从开发人员的角度来看，Score 的简单性使 YAML 文件更小，并且只需要对现有最小设置更改即可。

角色模型

OAM和Score都体现了平台工程师和开发者（终端用户）的不同的关注点，只是管理范围不同。 

例如，对于 OAM，您必须在应用程序规范中定义资源用户名和机密、部署工作负载的策略、部署工作流程等。它为开发人员提供了更多功能，但另一方面，它也使 YAML 文件更加复杂。

Score 假设其中许多决策和实施将由平台团队（或团队中经验丰富的开发人员）做出，并且它们将由平台本身执行，而不是在开发人员的工作负载规范结束时执行。例如，即使您可以为 Score 中的资源定义默认的用户名和密码，目标平台也可以配置为根据环境上下文为您替换这些。

用户群

OAM 和 Kubevela 比 Score 成熟得多，因为它已经存在了几年。它主要由阿里云创建和维护，是一个 CNCF 沙箱项目。目前，大多数采用 Kubevela 的公司都位于中国。

在撰写本文时，Score 还不到两个月的历史，但它的发展速度很快，它已由 Humanitec 周围的团队开源。

结论

Score 和 OAM/Kubevela 侧重点不同。

Score 的目标是成为一个与平台无关的workload规范，以解决不同技术堆栈和环境之间的切换问题，尤其是本地与远程之间的切换问题。而 Kubevela/OAM 的目标是成为一个功能齐全的持续部署平台，以呈现、编排、部署和管理云-本机应用程序。

您是否希望您的团队专注于workload并使用可以转换为本地和远程平台（如 docker-compose 和 Helm）的通用规范，那么也许 Score 是您最好的选择。

您如果希望能够拥有灵活的云原生应用程序定义，正在寻找一个地方来定义应用程序策略和 CD 管道工作流程，并愿意安装 Kubernetes CRD 控制器来实现这一目标，那么也许 OAM/Kubevela 是您更好的选择。

原文链接：https://score.dev/blog/score-vs-open-application-model-kubevela