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 名字。打开浏览器，输入这个访问信息，你就能够直接访问到这个应用了，以下所示：

而若是你要修改应用配置，好比更新镜像或者修改 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 是一个中立的开源项目，咱们欢迎更多的人参与其中，共同定义云原生应用交付的将来。

参与方式：

• 钉钉扫码进入 OAM 项目中文讨论群

• 经过 Gitter 直接参与讨论
• OAM 开源实现地址
• 点击 star 一下

做者简介

张磊  阿里云高级技术专家。他是 Kubernetes 项目的维护者之一。张磊目前在阿里的 Kubernetes 团队工做，其工做领域包括 Kubernetes 和云原生应用管理系统。

邓洪超  阿里云容器平台技术专家。原 CoreOS 公司工程师、 K8s Operator 项目的核心做者之一。

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”