Serverless 風起雲湧,為什麼阿里、微軟、AWS 紛紛擁抱開源 OAM?

【前言】作為全球首個雲原生應用標準定義與架構模型,Open Application Model(OAM)的核心理念是:“以應用為中心”,它強調研發和運維圍繞著一組聲明式的、靈活可擴展的上層抽象進行協作,而不是直接去使用複雜晦澀的基礎設施層 API。近日,AWS ECS 團隊在官方 GitHub 上發佈了一個名叫:Amazon ECS for Open Application Model 的開源項目,越來越多的廠商開始探索 OAM 的落地實踐。OAM 到底有什麼魅力,讓多家雲廠商具體聯合起來共同擁抱呢?

Serverless 風起雲湧,為什麼阿里、微軟、AWS 紛紛擁抱開源 OAM?

作者 | 張磊,阿里雲原生應用平臺高級技術專家

鄧洪超,阿里雲技術專家

責編 | 唐小引

頭圖 | CSDN 下載自東方 IC

出品 | CSDN(ID:CSDNnews)

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 風起雲湧,為什麼阿里、微軟、AWS 紛紛擁抱開源 OAM?

Serverless 與 Open Application Model (OAM)?

那麼 OAM,跟 AWS 和 Serverless 又是什麼關係呢?

首先,Open Application Model(OAM)是一套由阿里雲和微軟共同發起、由雲原生社區共同維護的應用描述規範(spec)。OAM 的核心理念是:“以應用為中心”,它強調研發和運維圍繞著一組聲明式的、靈活可擴展的上層抽象進行協作,而不是直接去使用複雜晦澀的基礎設施層 API。

比如,對於一個基於容器的、使用 K8s HPA 進行水平擴展應用,在 OAM 規範下會通過如下兩個 YAML 文件定義出來:

<code># 研發負責編寫這個 

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

/<code>

這樣的 YAML 文件被提交給 K8s 之後,就會由 OAM 插件自動翻譯成完整的 Deployment 和 HPA 對象真正運行起來。可以看到,在 OAM 規範下,研發和運維的關注點是完全分離開的,研發只需要編寫非常少量的、跟自己相關的一些字段,而不需要去學習 K8s 的完整 API,就可以輕鬆的定義和發佈應用。

由於 OAM 規範了“應用”、“運維能力”、“發佈邊界”等一系列雲原生應用交付的定義標準,應用管理平臺的開發者們就可以使用這個規範、通過更簡潔的 YAML 文件描述各種各樣的應用和運維策略,最後通過 OAM 插件把這些 YAML 文件跟 K8s 的實際資源(包括 CRD)映射起來。

也就是說,OAM 給出了一個定義“上層抽象”的事實標準,而這個“上層抽象”的最重要作用,就是防止各種各樣的基礎設施細節(比如 HPA、Ingress、容器、Pod、Service 等)洩露給研發同學,帶來不必要的複雜性。所以說,OAM 一經發布,就被稱作是開發 K8s 應用平臺 的“神兵利器”。

但更重要的是,這種從以應用描述中“剝離基礎設施層細節、為開發者提供最友好的上層抽象”的思想,與 Serverless “去基礎設施化” 的理念不謀而合。更確切地說,OAM 天生就是 Serverless 的

也正因為如此,OAM 一經發布,就受到了 Serverless 領域的重點關注。這其中,當然也少不了 AWS。

Serverless 風起雲湧,為什麼阿里、微軟、AWS 紛紛擁抱開源 OAM?

極致體驗: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 項目給開發者帶來的體驗非常有趣,我們來看一下。

準備工作有三步,一次性執行完即可。

  • 用戶需要在本地有 AWS 賬戶的認證信息,這個可以通過 AWS 官方客戶端 aws configure 命令一鍵生成。

  • 編譯項目,然後你就可以拿到一個叫做 oam-ecs 的可執行文件。

  • 你需要執行 oam-ecs env 命令來為你後面的部署準備環境。這條命令結束後,AWS 會自動為你創建 VPC 和對應的公有/私有子網。

而準備工作完成後,你只要在本地定義一個 OAM 應用 YAML 文件(比如前面提到的 helloworld 應用的例子)那麼你就可以通過如下所示的一行命令把一個完整的、帶了 HPA 的應用在 Fargate 上部署起來,並且可以直接在公網訪問到:

<code>

oam-ecs

app

deploy

-f

helloworld-app

.yaml

/<code>

是不是非常簡單?

在 AWS ECS for OAM 項目的官方文檔中,它給出了一個更加複雜的例子,我們來講解一下。

這次我們要部署的應用由三個 YAML 文件組成,依然劃分成研發和運維兩個關注點:

  • 研發負責編寫:

server-component.yaml

這個文件裡的內容是應用的第一個組件(component),具描述的是我們要部署的應用容器。

worker-component.yaml

這個文件裡的內容應用的第二個組件(component), 具體描述的是負責檢查當前環境的網絡是否暢通的一個循環 Job。

  • 運維負責編寫:

example-app.yaml

這個文件裡的內容是完整的應用組件拓撲以及各個組件的運維特徵(traits),具體描述的是一個“手動擴容(manual-scaler)”的運維策略,它專門用來擴容 worker-component。

所以,上述 example-app.yaml 也就是完整應用描述的內容如下所示:

<code>

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/<code>

可以看到,它定義了兩個組件(worker-v1 和 server-v1),並且 worker-v1 組件有一個叫做 manual-scaler 的手動擴容策略。

本 Demo 所有的三個 YAML 文件可以查看這個目錄下的內容:

https://github.com/awslabs/amazon-ecs-for-open-application-model/tree/master/examples

而上述複雜應用的部署,依然是一條指令搞定,非常簡單:

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

上述指令執行完成後(在國內的同學因為特殊的網絡問題可能需要一點耐心),你就可以通過 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 風起雲湧,為什麼阿里、微軟、AWS 紛紛擁抱開源 OAM?

最後:當應用模型遇上 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

作者簡介:

張磊,阿里雲原生應用平臺高級技術專家,CNCF 中國大使,CNCF Application Delivery Sig 主席。

鄧洪超,阿里雲技術專家,Kubernetes Operator 機制的初始作者之一,對 K8s 應用管理體系有較多的研究和經驗。

Serverless 風起雲湧,為什麼阿里、微軟、AWS 紛紛擁抱開源 OAM?
Serverless 風起雲湧,為什麼阿里、微軟、AWS 紛紛擁抱開源 OAM?

今日福利

遇見陸奇

同樣作為“百萬人學 AI”的重要組成部分,2020 AIProCon 開發者萬人大會將於 7 月 3 日至 4 日通過線上直播形式,讓開發者們一站式學習瞭解當下 AI 的前沿技術研究、核心技術與應用以及企業案例的實踐經驗,同時還可以在線參加精彩多樣的開發者沙龍與編程項目。參與前瞻系列活動、在線直播互動,不僅可以與上萬名開發者們一起交流,還有機會贏取直播專屬好禮,與技術大咖連麥。


分享到:


相關文章: