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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」