作者 | 孫健波（天元）? 阿里巴巴技術(shù)專(zhuān)家

2011 年，Heroku 的聯(lián)合創(chuàng)始人 ?Adam Wiggins 根據(jù)針對(duì)上百萬(wàn)應(yīng)用托管和運(yùn)維的經(jīng)驗(yàn)，發(fā)布了著名的 “十二要素應(yīng)用宣言（The Twelve-Factor App）”。不知那時(shí)候他們有沒(méi)有想到，這份宣言會(huì)在今后數(shù)年時(shí)間里，成為 SaaS 應(yīng)用開(kāi)發(fā)的啟蒙書(shū)。同時(shí)也奠定了 Heroku 在 PaaS 領(lǐng)域的地位，成為了云上應(yīng)用開(kāi)發(fā)規(guī)范化的基石。

Heroku 無(wú)疑是一家偉大的公司，它關(guān)注應(yīng)用與開(kāi)發(fā)者，“以應(yīng)用為中心”的理念讓我們至今受益。然而在過(guò)去這一兩年里，我們看到許多 Heroku 的用戶開(kāi)始尋找別的選擇。這不禁讓我們好奇，站在“云原生”如火如荼的今天回望過(guò)去，Heroku 的“得”與“失”究竟在哪里？

“以應(yīng)用為中心”的先進(jìn)理念

Heroku 創(chuàng)辦于 2007 年，是最早成熟的 PaaS 產(chǎn)品之一。Heroku 也是最早喊出“以應(yīng)用為中心”，大規(guī)模幫助應(yīng)用上云的產(chǎn)品。正是圍繞“以應(yīng)用為中心”這樣先進(jìn)的理念，使得 Heroku 從一開(kāi)始便擁有了至今看來(lái)都非常誘人的功能：

• 用戶可以直接從開(kāi)發(fā)語(yǔ)言出發(fā)，選擇對(duì)應(yīng)的技術(shù)棧，通過(guò) heroku create 這樣簡(jiǎn)單的命令，將應(yīng)用托管到云上。主流的開(kāi)發(fā)語(yǔ)言，均能在 Heroku 中找到對(duì)應(yīng)的選擇。從代碼的變動(dòng)自動(dòng)觸發(fā)軟件的部署交付，清晰的工作流、多樣的發(fā)布策略，直到后來(lái)的很多年都是 DevOps 們夢(mèng)寐以求的功能；

• **用戶無(wú)需關(guān)心應(yīng)用背后的基礎(chǔ)設(shè)施是什么，Heroku 負(fù)責(zé)維護(hù)背后的一切。**這句看似簡(jiǎn)單的話背后隱藏了巨大的復(fù)雜性，試想下某個(gè)軟件或系統(tǒng)爆出安全漏洞后給你帶來(lái)的窘境，又或者你想使用一個(gè)數(shù)據(jù)庫(kù)服務(wù)時(shí)卻不得不維護(hù)一個(gè)數(shù)據(jù)庫(kù)實(shí)例。而在 Heroku， 這一切麻煩你都無(wú)需關(guān)心；

• **高可用與彈性作為附加能力。**Heroku ?平臺(tái)托管的服務(wù)具備高可用等附加能力，更讓人驚喜的是，滿足 12-factor 的應(yīng)用還天然具備了擴(kuò)縮容的能力，可以很輕松的抗住突發(fā)流量，這在當(dāng)時(shí)無(wú)異于黑科技般的存在。

**正是這樣強(qiáng)大的能力，使得 Heroku 成為了 PaaS 領(lǐng)域事實(shí)上的標(biāo)準(zhǔn)，**無(wú)論是后續(xù)的 Cloud Foundry 還是 OpenShift，似乎都沒(méi)有對(duì) Heroku 有實(shí)質(zhì)性的超越。

Heroku 不再物超所值

眾所周知，相對(duì)于只是提供純粹計(jì)算能力的 IaaS 而言，以服務(wù)能力著稱(chēng)、提供眾多開(kāi)箱即用附加功能的 PaaS，價(jià)格上素來(lái)都是普遍偏貴的。畢竟 PaaS 可以使你專(zhuān)注于業(yè)務(wù)本身，貴一點(diǎn)自然也無(wú)可厚非。更何況 PaaS 通常根據(jù)開(kāi)通附加能力的數(shù)量收費(fèi)，剛開(kāi)始甚至更便宜，Heroku 亦是如此。

一開(kāi)始，用戶可能感覺(jué)只是比自己在 IaaS 上搭建服務(wù)貴一點(diǎn)點(diǎn)。當(dāng)你發(fā)現(xiàn)應(yīng)用可以便捷綁定 Heroku 提供的高可用 PostgresSQL 數(shù)據(jù)庫(kù)時(shí)，甚至?xí)X(jué)得它貴的物超所值。不過(guò)，隨著業(yè)務(wù)邏輯逐漸復(fù)雜、部署規(guī)模越來(lái)越大，需求自然而然就變了。比如為了讓用戶的數(shù)據(jù)更安全，你可能需要一個(gè)只能私有網(wǎng)絡(luò)訪問(wèn)的 PostgresSQL 實(shí)例，而 Heroku 默認(rèn)不具備這樣的功能，你必須要配置一個(gè) VPC 才能做到，你自然要為這個(gè) VPC 額外付費(fèi)。這類(lèi)需求逐漸覆蓋了你每一個(gè)實(shí)例，增加的費(fèi)用直接變成了增長(zhǎng)的單價(jià)，成本快速上升。與此同時(shí)，IaaS 廠商的能力也正在爆炸式的增長(zhǎng)。今天，幾乎所有的云服務(wù)商都開(kāi)始提供數(shù)據(jù)庫(kù)服務(wù)，并且這些數(shù)據(jù)庫(kù)實(shí)例的 VPC 通常是免費(fèi)的。

另一方面，**Heroku 從 13 年前誕生至今，一直是閉源的商業(yè)平臺(tái)，關(guān)于 Heroku 的一切你都只能在其本身的平臺(tái)上玩。**這無(wú)疑給新人學(xué)習(xí)、上手造成了很高的門(mén)檻，甚至許多人因此不愿意體驗(yàn)該產(chǎn)品。這也導(dǎo)致周邊生態(tài)的配套工具相當(dāng)匱乏，只要官方不提供的能力，用戶就得自己開(kāi)發(fā)。然而無(wú)論是招聘 Heroku 熟練工，還是從零開(kāi)始培養(yǎng)，這無(wú)疑都帶來(lái)了不小的人力成本。

反觀如今的云原生社區(qū)，任何人都可以通過(guò)幾條簡(jiǎn)單的命令在自己的開(kāi)發(fā)環(huán)境中運(yùn)行 Kubernetes，開(kāi)發(fā)者可以很輕易的體驗(yàn)和學(xué)習(xí)，積累經(jīng)驗(yàn)?；A(chǔ)設(shè)施主動(dòng)對(duì)接 Kubernetes 生態(tài)。周邊的各類(lèi)工具也在不斷的繁榮演進(jìn)。

黑盒化的運(yùn)行時(shí)體驗(yàn)

提到 Heroku，另一個(gè)代表性的技術(shù)無(wú)疑就是 Buildpack。在 Docker 鏡像機(jī)制出現(xiàn)之前，使用 Buildpack 管理用戶應(yīng)用的運(yùn)行時(shí)構(gòu)建，使得 PaaS 的運(yùn)行時(shí)最終與語(yǔ)言無(wú)關(guān)，這無(wú)疑是非常聰明的做法。然而十多年過(guò)去，Buildpack 的模式早已暴露出許多問(wèn)題。

• 一方面是官方支持的 Buildpack 數(shù)量少，限制多，比如運(yùn)行系統(tǒng)僅支持 Linux 的 Ubuntu 發(fā)行版；某些 Ubuntu 安裝包在 Buildpack 中沒(méi)有安裝你便無(wú)法使用；相對(duì)小眾的開(kāi)發(fā)語(yǔ)言（如 Elixir）均不支持；又或者是你的應(yīng)用包含多種語(yǔ)言，使用起來(lái)就變得復(fù)雜；

• 另一方面，你也許能自定義或者找到第三方的 Buildpack 滿足需求，但是沒(méi)有人來(lái)保證它的穩(wěn)定。一旦出了問(wèn)題，你很難在本地運(yùn)行 Buildpack 排查問(wèn)題，而 Heroku 平臺(tái)的錯(cuò)誤信息透出方式并不直接，日志排查更是不便。

2017 年 9 月份，Heroku 最終還是支持了基于 Docker 鏡像的運(yùn)行時(shí)部署，然而至今為止依舊有不少限制，其中最大的限制是存儲(chǔ)，只能使用 Heroku 的臨時(shí)存儲(chǔ)，這幾乎就決定了你不可能自己編寫(xiě)像 etcd、TiDB 這類(lèi)復(fù)雜的有狀態(tài)應(yīng)用。

一切的本質(zhì)，都在于 Heroku 給用戶提供的體驗(yàn)是黑盒化的，為用戶屏蔽基礎(chǔ)設(shè)施的同時(shí)，也使得用戶失去了改造的自由。這也是為什么即便像 Cloudfoundry 這樣理念極其類(lèi)似的 PaaS 平臺(tái)，即便是開(kāi)源的，依舊存在同樣的弊病。

**事實(shí)上用戶喜歡的是“白盒”，他們希望能夠自定義基礎(chǔ)設(shè)施，可以平行的替換或改造平臺(tái)的已有功能，而非只能局限在平臺(tái)提供的能力之上構(gòu)建。**就像我們買(mǎi)了一輛車(chē)，在雨雪的極端天氣下，我們希望可以換雪地胎，而不是只能加裝防滑鏈。

Kubernetes 的出現(xiàn)

而 Kubernetes 正是這樣一個(gè)白盒化體驗(yàn)，它從未嘗試去屏蔽基礎(chǔ)設(shè)施，而是作為一個(gè)標(biāo)準(zhǔn)化接入層，把基礎(chǔ)設(shè)施層的能力通過(guò)聲明式 API 暴露出來(lái)，將選擇權(quán)留給了用戶。正是在這樣一個(gè)開(kāi)放世界里，復(fù)雜有狀態(tài)應(yīng)用的管理也終于得以在云上落地了。另一方面， Kubernetes 并不是 PaaS。相比于 Heroku 官方提供了將近兩百個(gè) add-ons（插件）） 用于增強(qiáng)包括數(shù)據(jù)庫(kù)、監(jiān)控、日志、緩存、搜索、分析、權(quán)限等能力，而 Kubernetes 則強(qiáng)調(diào)強(qiáng)可擴(kuò)展能力，希望用戶自己可以通過(guò)編寫(xiě) CRD Operator 新增任意能力。

那么，這兩種做法的區(qū)別是什么呢？

封閉、限制 vs 開(kāi)放、自由

眾所周知，Heroku 一直是一個(gè)“主觀”的 PaaS 平臺(tái)，12-factor 代表了應(yīng)用必須云原生化的強(qiáng)硬觀點(diǎn)，這一點(diǎn)毋庸置疑是正確的，而且非常了不起。但如果觀念不能與時(shí)俱進(jìn)，那么“主觀”就會(huì)變得危險(xiǎn)。就比如容器和虛擬機(jī)都已經(jīng)相當(dāng)普及的今天，Heroku 依舊堅(jiān)持應(yīng)用只能運(yùn)行在 Heroku Dynos 上面。雖然這種統(tǒng)一很大程度上為管理提供了便利，但是這也使得用戶丟掉了很多靈活性，更重要的是，運(yùn)行時(shí)的巨大差異，開(kāi)始讓很多用戶覺(jué)得自己與更廣泛的社區(qū)“格格不入”。

不過(guò)，Heroku 有屬于自己的封閉生態(tài)，除了上文提到官方維護(hù)的 Add-ons 以外，還有方便用戶一鍵部署到 Heroku 平臺(tái)的 4700 多個(gè) Buttons 應(yīng)用 ?和 用于自定義運(yùn)行時(shí)和構(gòu)建流程的 6300 多個(gè) Buildpacks，這兩大功能都允許用戶自定義并可以申請(qǐng)注冊(cè)到官方的應(yīng)用市場(chǎng)中，數(shù)量著實(shí)驚人。這樣繁榮的社區(qū)怎會(huì)被人詬病？出于好奇，筆者整體分析了一下這些項(xiàng)目。

下面兩張圖分別是 Heroku Buildpack 和 Buttons 的項(xiàng)目統(tǒng)計(jì)：

我們可以看到，Buildpack 只能在 Heroku 平臺(tái)使用，所以 star 數(shù)量代表了大家對(duì)項(xiàng)目的關(guān)心，而下載量則代表了用戶的使用頻度。圖中，6000 多個(gè) Buildpack 的 star 數(shù)和下載安裝量均在 50 以內(nèi)，而超過(guò) 500 個(gè) star 和 500 次下載部署的項(xiàng)目均只有 30 個(gè)左右。再來(lái)看 Buttons 中的項(xiàng)目，由于這些項(xiàng)目本身還可以部署到 Heroku 以外的其他平臺(tái)，所以就只看在 Heroku 的部署下載量反映大家的使用頻度，而圖中超過(guò) 500 次部署的 Buttons 項(xiàng)目只有 6 個(gè)。原來(lái)這一切竟只是表面繁榮。

面對(duì)這樣一個(gè)統(tǒng)計(jì)數(shù)據(jù)，我們很難說(shuō) Heroku 的封閉生態(tài)是成功的。

Buildpack 本質(zhì)上是對(duì)進(jìn)程的構(gòu)建和打包，同樣的工作業(yè)界幾乎都已經(jīng)統(tǒng)一通過(guò) Dockerfile 構(gòu)建鏡像解決。與 Buildpack 只能在 Heroku 平臺(tái)上使用的封閉生態(tài)不同，Docker 鏡像以及 OCI 容器和鏡像規(guī)范的出現(xiàn)，大大推動(dòng)了基于容器鏡像的應(yīng)用打包方式走向了全面繁榮。而用于存儲(chǔ)鏡像的 Docker Registry 也是人人都可以搭建的鏡像倉(cāng)庫(kù)。從數(shù)字上看，僅官方鏡像倉(cāng)庫(kù)上的鏡像數(shù)量就超過(guò)了 300 萬(wàn)，更有數(shù)千鏡像下載量超過(guò)了 100 萬(wàn)，這才是成功生態(tài)應(yīng)該有的力量。

而在 Kubernetes 生態(tài)中幫助應(yīng)用打包并可以一鍵部署 CRD Operator 的 Helm Chats 也與 Heroku 的 Buttons 類(lèi)似。同樣， Helm Charts 的托管平臺(tái)是可以自由搭建的，而 Chart 本身則在任何一個(gè)開(kāi)源或者商業(yè)版本的 Kubernetes 上均能運(yùn)行。雖然沒(méi)有明確的統(tǒng)計(jì)數(shù)據(jù)，但是像 Helm Hub、Kubeapps Hub、CloudNative App Hub 等 Charts 托管網(wǎng)站里的內(nèi)容看起來(lái)也已經(jīng)取得了不小的成功。

Heroku 們的未來(lái)？

從上述觀察來(lái)看，Heroku 過(guò)去最重要的教訓(xùn)，在于不夠開(kāi)放而錯(cuò)失了原本屬于自己的云原生應(yīng)用生態(tài)。而在 Kubernetes 項(xiàng)目成為基礎(chǔ)設(shè)施主流之后，Heroku 以及它的開(kāi)源繼任者 Cloud Foundry 還是很難走出“被故意忽視”的困境。這個(gè)困境的關(guān)鍵并不在于它們是不是基于 K8s 構(gòu)建的，而是它們能不能帶來(lái)像 K8s 一樣的開(kāi)放與自由。

可是，另一方面，Kubernetes 本身從始至終都不是一個(gè)面向最終用戶的體驗(yàn)，也不是最終用戶想要的東西。Kubernetes 自身“白盒化”的體驗(yàn)正在為越來(lái)越多的業(yè)務(wù)研發(fā)和運(yùn)維帶來(lái)“太復(fù)雜”的困擾。而這個(gè)社區(qū)里大量的 CRD Operator 則像一個(gè)個(gè)煙囪，彼此孤立，不能聯(lián)動(dòng)，而且有大量的冗余（比如：Kubernetes 中永無(wú)止盡的 Ingress 實(shí)現(xiàn) ）。這一切都說(shuō)明，純粹使用 Kubernetes 并非托管云原生應(yīng)用的“標(biāo)準(zhǔn)答案”。而那些試圖“給 K8s 寫(xiě)個(gè)界面”的 PaaS 構(gòu)建者們，似乎又陷入了 Heroku 的困境。這種變化，也讓 PaaS 與 Kubernetes 之間的關(guān)系越來(lái)越復(fù)雜和不清晰。

從 Kubernetes 到“以應(yīng)用為中心”的美好未來(lái)之間，全世界的 PaaS 工程師其實(shí)都在期待一項(xiàng)全新的技術(shù)能夠彌補(bǔ)這之間的鴻溝。阿里云原生應(yīng)用平臺(tái)團(tuán)隊(duì)的做法是，通過(guò)為應(yīng)用“建?！钡姆绞絹?lái)解決這個(gè)問(wèn)題，這也正是 Open Application Model (OAM)?開(kāi)源項(xiàng)目得以創(chuàng)建的重要目的。

最后

OAM（Open Application Model）開(kāi)放應(yīng)用模型是阿里聯(lián)合微軟針對(duì)云原生應(yīng)用的模型，第一次對(duì)“以應(yīng)用為中心”的基礎(chǔ)設(shè)施和構(gòu)建規(guī)范進(jìn)行了完整的闡述。應(yīng)用管理者只要遵守這個(gè)規(guī)范，就可以編寫(xiě)出一個(gè)自包含、自描述的“應(yīng)用定義文件”。

OAM 相關(guān)內(nèi)容在 github 上完全開(kāi)源，同時(shí)我們也為 Go 生態(tài)編寫(xiě)了 oam-go-sdk 方便快速實(shí)現(xiàn) OAM。

目前，阿里巴巴團(tuán)隊(duì)正在上游貢獻(xiàn)和維護(hù)這套技術(shù)，如果大家有什么問(wèn)題或者反饋，也非常歡迎與我們?cè)谏嫌位蛘哚斸斅?lián)系。

參與方式：

• 釘釘掃碼進(jìn)入 OAM 項(xiàng)目中文討論群

（釘釘掃碼加入交流群）

• 通過(guò) Gitter 直接參與討論
• OAM 開(kāi)源實(shí)現(xiàn)地址
• 點(diǎn)擊 star 一下

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的Heroku 的“得”与“失”的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。