![1.png](https://ucc.alicdn.com/pic/developer-ecology/9e6ee2f03b6944ce9b9f09a77661e444.png)

作者 | 張磊  鄧洪超

> **導讀：**近日，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 檔案：

```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 檔案：

```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](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 也就是完整應用描述的內容如下所示：

```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](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 名字。開啟瀏覽器，輸入這個訪問資訊，你就可以直接訪問到這個應用了，如下所示：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/fd28051b43664e2c86ec1c4775874a89.png)

而如果你要修改應用配置，比如更新映象或者修改 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](https://help.aliyun.com/product/29500.html)
> Crossplane：[https://github.com/crossplane/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/](https://github.com/awslabs/amazon-ecs-for-open-application-model/)
> Open Application Model 專案：[https://github.com/oam-dev/spec](https://github.com/oam-dev/spec)
> CNCF SIG App Delivery：[https://github.com/cncf/sig-app-delivery](https://github.com/cncf/sig-app-delivery)

目前，OAM 規範和模型實際已解決許多現有問題，但它的路程才剛剛開始。OAM 是一箇中立的開源專案，我們歡迎更多的人參與其中，共同定義雲原生應用交付的未來。

參與方式：

- 釘釘掃碼進入 OAM 專案中文討論群

![3.png](https://ucc.alicdn.com/pic/developer-ecology/deac256ca8d24677b5e1d20781497ad1.png)

- [透過 Gitter 直接參與討論](https://gitter.im/oam-dev/)
- [OAM 開源實現地址](https://github.com/oam-dev/rudr)
- [點選 star 一下](https://github.com/oam-dev/rudr)

**作者簡介**

**張磊**  阿里雲高階技術專家。他是 Kubernetes 專案的維護者之一。張磊目前在阿里的 Kubernetes 團隊工作，其工作領域包括 Kubernetes 和雲原生應用管理系統。

**鄧洪超**  阿里雲容器平臺技術專家。原 CoreOS 公司工程師、 K8s Operator 專案的核心作者之一。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490190&idx=1&sn=f196688c2324d6905cefe9b55b619e14&chksm=fae51141cd9298576e8b4955601d57a79672ff35ac140668b115ded17ea9b4bca57b061a5595&token=1845419206&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

Serverless 風起雲湧，為什麼阿里，微軟，AWS 卻開始折騰 OAM？

相關文章