作者 | 張磊 鄧洪超
導讀：近日，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 項目中文讨論群
作者簡介
張磊 阿裡雲進階技術專家。他是 Kubernetes 項目的維護者之一。張磊目前在阿裡的 Kubernetes 團隊工作，其工作領域包括 Kubernetes 和雲原生應用管理系統。
鄧洪超 阿裡雲容器平台技術專家。原 CoreOS 公司工程師、 K8s Operator 項目的核心作者之一。
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”