Serverless 风起云涌，为什么阿里，微软，AWS 却开始折腾 OAM？

作者 | 张磊邓洪超

**导读：**近日，AWS ECS 团队在官方 GitHub 上发布了一个名叫：Amazon ECS for Open Application Model 的开源项目，越来越多的厂商开始探索 OAM 的落地实践。OAM 到底有什么魅力，让多家云厂商联合起来共同拥抱呢？

Serverless 与 AWS

Serverless 这个词第一次被是 2012 年一篇名为《Why The Future of Software and Apps is Serverless》的文章。不过，如果你真去考古的话就会发现，这篇文章谈到的内容是其实是持续集成和代码版本控制的软件工程理念，跟我们今天谈 Serverless 所提到的 “scale to zero”、“pay as you go”，FaaS/BaaS 这些东西，完全不是一个事情。

在 2014 年，AWS 发布了一个叫做 Lambda 的产品。这个产品的设计理念很简单：它认为云计算最终是面向应用提供服务的，而当用户想要部署一个应用的时候，它只需要有一个地方放自己编写程序来执行具体任务，而不用关心这个程序运行在哪个机器或者哪个虚拟机上。

正是 Lambda 的发布，才让“Serverless”这一范式提高到一个全新的层面。Serverless 为云中部署和运行应用程序提供了一种全新的系统体系结构，强调用户不需要关心复杂的服务器配置，只需要关心自己的代码以及如何把代码打包成一个可以被云计算平台托管的“可运行实体”。在随后发布了一系列譬如根据实际流量扩展应用实例、按照实际使用量而不是预分配资源来计费等经典特性之后，AWS 才逐步奠定了 Serverless 领域的事实标准。

2017 年，AWS 发布了 Fargate 服务，将 Serverless 的理念推广到了基于容器的可运行实体中，很快这个思想也被 Google Cloud Run 等进行了跟进，开启了“下一代”基于容器的 Serverless 运行时热潮。

Serverless 与 Open Application Model (OAM)？

那么 Open Application Model（OAM），跟 AWS 和 Serverless 又是什么关系呢？

首先，OAM（开放应用模型）是一套由阿里云和微软共同发起、由云原生社区共同维护的应用描述规范（spec）。OAM 的核心理念是：“以应用为中心”，它强调研发和运维围绕着一组声明式的、灵活可扩展的上层抽象进行协作，而不是直接去使用复杂晦涩的基础设施层 API。

比如，对于一个基于容器的、使用 K8s HPA 进行水平扩展应用，在 OAM 规范下会通过如下两个 YAML 文件定义出来。

研发负责编写的 YAML 文件：

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: web-server
spec:
  # 待部署的应用详情
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
      containers:
        - name: frontend
          image: frontend:latest

运维（或者 PaaS 平台）负责编写的 YAML 文件：

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: helloworld
spec:
  components:
    - name: frontend
      # 该应用运行所需的运维能力
      traits:
        - trait:
            apiVersion: autoscaling.k8s.io/v2beta2
            kind: HorizontalPodAutoscaler
            metadata:
              name: scale-hello
            spec:
              minReplicas: 1
                          maxReplicas: 10

可以看到，在 OAM 规范下，研发和运维的关注点是完全分离开的。研发与运维只需要编写非常少量的、跟自己相关的一些字段，而不是完整的 K8s Deployment 和 HPA 对象，就可以轻松的定义和发布应用。这就是“上层抽象”为我们带来的好处。

像上述这样的 YAML 文件被提交给 K8s 之后，就会由 OAM 插件自动转换成完整的 Deployment 和 HPA 对象真正运行起来。

由于 OAM 规范了“应用”、“运维能力”、“发布边界”等一系列云原生应用交付的定义标准，应用管理平台的开发者们就可以使用这个规范、通过更简洁的 YAML 文件描述各种各样的应用和运维策略，最后通过 OAM 插件把这些 YAML 文件跟 K8s 的实际资源（包括 CRD）映射起来。

也就是说，OAM 给出了一个定义“上层抽象”的事实标准，而这个“上层抽象”最重要的作用，就是防止各种各样的基础设施细节（比如 HPA、Ingress、容器、Pod、Service 等）泄露给研发同学，带来不必要的复杂性。所以说，OAM 一经发布，就被称作是开发 K8s 应用平台的“神兵利器”。

但更重要的是，这种从以应用描述中“剥离基础设施层细节、为开发者提供最友好的上层抽象”的思想，与 Serverless “去基础设施化” 的理念不谋而合。更确切地说，OAM 天生就是 Serverless 的。

也正因为如此，OAM 一经发布，就受到了 Serverless 领域的重点关注。这其中，当然也少不了 AWS。

极致体验：AWS ECS for OAM

2020 年 3 月底，AWS ECS 团队在官方 GItHub 上发布了一个名叫：Amazon ECS for Open Application Model 的开源项目。

项目地址：https://github.com/awslabs/amazon-ecs-for-open-application-model

这个项目，正是 AWS 团队基于 Serverless 服务对 OAM 进行支持的一次尝试。这个项目的底层运行时，正是我们前面提到的 Serverless 容器服务：Fargate。而这个 AWS ECS for OAM 项目给开发者带来的体验非常有趣，我们来看一下。

准备工作有三步，一次性执行完即可。

1.用户需要在本地有 AWS 账户的认证信息，这个可以通过 AWS 官方客户端 aws configure 命令一键生成； 2.编译项目，然后你就可以拿到一个叫做 oam-ecs 的可执行文件； 3.你需要执行 oam-ecs env 命令来为你后面的部署准备环境。这条命令结束后，AWS 会自动为你创建 VPC 和对应的公有/私有子网。

而准备工作完成后，你只要在本地定义一个 OAM 应用 YAML 文件（比如前面提到的 helloworld 应用的例子）那么你就可以通过如下所示的一行命令把一个完整的、带了 HPA 的应用在 Fargate 上部署起来，并且可以直接在公网访问到：

oam-ecs app deploy -f helloworld-app.yaml

是不是非常简单？

在 AWS ECS for OAM 项目的官方文档中，它给出了一个更加复杂的例子，我们来讲解一下。

这次我们要部署的应用由三个 YAML 文件组成，依然划分成研发和运维两个关注点：

1. 研发负责编写

server-component.yaml：这个文件里的内容是应用的第一个组件（component），具描述的是我们要部署的应用容器；
worker-component.yaml：这个文件里的内容应用的第二个组件（component），具体描述的是负责检查当前环境的网络是否畅通的一个循环 Job。

2. 运维负责编写

example-app.yaml：这个文件里的内容是完整的应用组件拓扑以及各个组件的运维特征（traits），具体描述的是一个“手动扩容（manual-scaler）”的运维策略，它专门用来扩容 worker-component。

所以，上述 example-app.yaml 也就是完整应用描述的内容如下所示：

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: example-app
spec:
  components:
    - componentName: worker-v1
      instanceName: example-worker
      traits:
        - name: manual-scaler
          properties:
            replicaCount: 2
    - componentName: server-v1
      instanceName: example-server
      parameterValues:
        - name: WorldValue
          value: Everyone

可以看到，它定义了两个组件（worker-v1 和 server-v1），并且 worker-v1 组件有一个叫做 manual-scaler 的手动扩容策略。

本 Demo 所有的三个 YAML 文件可以查看这个目录下的内容：https://github.com/awslabs/amazon-ecs-for-open-application-model/tree/master/examples

而上述复杂应用的部署，依然是一条指令搞定，非常简单：

oam-ecs app deploy \
  -f examples/example-app.yaml \
  -f examples/worker-component.yaml \
  -f examples/server-component.yaml

上述指令执行完成后（在国内的同学因为特殊的网络问题可能需要一点耐心），你就可以通过 oam-ecs app show 命令查看到应用的访问信息和 DNS 名字。打开浏览器，输入这个访问信息，你就可以直接访问到这个应用了，如下所示：

Serverless 风起云涌，为什么阿里，微软，AWS 却开始折腾 OAM？

而如果你要修改应用配置，比如更新镜像或者修改 replicaCount 的值，那么只需要修改上述 YAML 文件然后重新 deploy 即可，完全是声明式的管理方式。

实际上，上述操作如果通过 AWS 的 Console 来完成，至少需要在 5 个云产品页面之间互相跳转进行各种各样的配置；或者，你就需要学习 CloudFormation 语法然后编写一个非常非常长的 CF 文件，以便拉起应用运行所需的 Fargate 实例、LoadBalancer、网络、DNS 配置等等所有资源。

但是通过 OAM 规范，上述定义和部署应用过程不仅变得极其简单，而且还把原来流程化的云服务操作直接转换成了更简洁、更友好的声明式 YAML 文件。而这里所需的实现 OAM 规范的具体工作，其实也就几百行代码而已。

更重要的是，当 AWS Fargate 这样的 Serverless 服务跟 OAM 这样开发者友好的应用定义结合在一起之后，你才会真正感受到：原来，这种简洁、爽快和极低的心智负担，才是 Serverless 为开发者带来的极致体验。

最后：当应用模型遇上 Serverless

OAM 模型在云原生应用交付生态引起了巨大的反响。目前，阿里云 EDAS 服务已经成为了业界第一款基于 OAM 构建的生产级应用管理平台，并很快推出下一代“以应用为中心”的产品体验；在 CNCF 社区，知名的跨云应用管理与交付平台 Crossplane 项目也已经成为了 OAM 规范的重要采纳者和维护者。

EDAS 官网：https://help.aliyun.com/product/29500.html Crossplane：https://github.com/crossplane/crossplane

实际上，不止 AWS Fargate，我们云计算生态里的所有 Serverless 服务都可以很容易的使用 OAM 来作为面向开发者的表现层和应用定义，从而实现对原本复杂的基础设施 API 进行简化和抽象，将原本复杂的流程化操作“一键”升级为 Kubernetes 风格的声明式应用管理方式。更重要的是，得益于 OAM 的高可扩展性，你不仅可以在 Fargate 上部署容器应用，你还可以用 OAM 来描述 Function，虚拟机，WebAssembly 乃至任何你能想到的工作负载类型，然后把它们轻松的部署在 Serverless 服务上，甚至在不同的云服务之间无缝迁移。这些看似“神奇”的能力，都是当一个标准化、可扩展的“应用模型”遇见一个 Serverless 平台之后能够碰撞出来的创新火花。

应用模型 + Serverless，已经逐渐成为了云原生生态最热门的话题之一，欢迎你一起来加入 CNCF 云原生应用交付领域小组（SIG App Delivery），推动云计算生态朝着“以应用为中心”的方向不断前进起来！

AWS ECS on OAM 项目：https://github.com/awslabs/amazon-ecs-for-open-application-model/ Open Application Model 项目：https://github.com/oam-dev/spec CNCF SIG App Delivery：https://github.com/cncf/sig-app-delivery

目前，OAM 规范和模型实际已解决许多现有问题，但它的路程才刚刚开始。OAM 是一个中立的开源项目，我们欢迎更多的人参与其中，共同定义云原生应用交付的未来。

参与方式：