Heroku 的「得」與「失」

時間 2020-02-22

標籤 heroku 简体版

原文原文鏈接

做者 | 孫健波（天元）阿里巴巴技術專家git

2011 年，Heroku 的聯合創始人 Adam Wiggins 根據針對上百萬應用託管和運維的經驗，發佈了著名的「十二要素應用宣言（The Twelve-Factor App）」。不知那時候他們有沒有想到，這份宣言會在從此數年時間裏，成爲 SaaS 應用開發的啓蒙書。同時也奠基了 Heroku 在 PaaS 領域的地位，成爲了雲上應用開發規範化的基石。github

Heroku 無疑是一家偉大的公司，它關注應用與開發者，「以應用爲中心」的理念讓咱們至今受益。然而在過去這一兩年裏，咱們看到許多 Heroku 的用戶開始尋找別的選擇。這不由讓咱們好奇，站在「雲原生」如火如荼的今天回望過去，Heroku 的「得」與「失」究竟在哪裏？數據庫

「以應用爲中心」的先進理念

Heroku 創辦於 2007 年，是最先成熟的 PaaS 產品之一。Heroku 也是最先喊出「以應用爲中心」，大規模幫助應用上雲的產品。正是圍繞「以應用爲中心」這樣先進的理念，使得 Heroku 從一開始便擁有了至今看來都很是誘人的功能：緩存

用戶能夠直接從開發語言出發，選擇對應的技術棧，經過 heroku create 這樣簡單的命令，將應用託管到雲上。主流的開發語言，均能在 Heroku 中找到對應的選擇。從代碼的變更自動觸發軟件的部署交付，清晰的工做流、多樣的發佈策略，直到後來的不少年都是 DevOps 們求之不得的功能；安全
**用戶無需關心應用背後的基礎設施是什麼，Heroku 負責維護背後的一切。**這句看似簡單的話背後隱藏了巨大的複雜性，試想下某個軟件或系統爆出安全漏洞後給你帶來的窘境，又或者你想使用一個數據庫服務時卻不得不維護一個數據庫實例。而在 Heroku，這一切麻煩你都無需關心；網絡
**高可用與彈性做爲附加能力。**Heroku 平臺託管的服務具有高可用等附加能力，更讓人驚喜的是，知足 12-factor 的應用還自然具有了擴縮容的能力，能夠很輕鬆的抗住突發流量，這在當時無異於黑科技般的存在。app

**正是這樣強大的能力，使得 Heroku 成爲了 PaaS 領域事實上的標準，**不管是後續的 Cloud Foundry 仍是 OpenShift，彷佛都沒有對 Heroku 有實質性的超越。less

Heroku 再也不物超所值

衆所周知，相對於只是提供純粹計算能力的 IaaS 而言，以服務能力著稱、提供衆多開箱即用附加功能的 PaaS，價格上素來都是廣泛偏貴的。畢竟 PaaS 可使你專一於業務自己，貴一點天然也無可厚非。更況且 PaaS 一般根據開通附加能力的數量收費，剛開始甚至更便宜，Heroku 亦是如此。運維

一開始，用戶可能感受只是比本身在 IaaS 上搭建服務貴一點點。當你發現應用能夠便捷綁定 Heroku 提供的高可用 PostgresSQL 數據庫時，甚至會以爲它貴的物超所值。不過，隨着業務邏輯逐漸複雜、部署規模愈來愈大，需求天然而然就變了。好比爲了讓用戶的數據更安全，你可能須要一個只能私有網絡訪問的 PostgresSQL 實例，而 Heroku 默認不具有這樣的功能，你必需要配置一個 VPC 才能作到，你天然要爲這個 VPC 額外付費。這類需求逐漸覆蓋了你每個實例，增長的費用直接變成了增加的單價，成本快速上升。與此同時，IaaS 廠商的能力也正在爆炸式的增加。今天，幾乎全部的雲服務商都開始提供數據庫服務，而且這些數據庫實例的 VPC 一般是免費的。微服務

另外一方面，**Heroku 從 13 年前誕生至今，一直是閉源的商業平臺，關於 Heroku 的一切你都只能在其自己的平臺上玩。**這無疑給新人學習、上手形成了很高的門檻，甚至許多人所以不肯意體驗該產品。這也致使周邊生態的配套工具至關匱乏，只要官方不提供的能力，用戶就得本身開發。然而不管是招聘 Heroku 熟練工，仍是從零開始培養，這無疑都帶來了不小的人力成本。

反觀現在的雲原生社區，任何人均可以經過幾條簡單的命令在本身的開發環境中運行 Kubernetes，開發者能夠很輕易的體驗和學習，積累經驗。基礎設施主動對接 Kubernetes 生態。周邊的各種工具也在不斷的繁榮演進。

黑盒化的運行時體驗

提到 Heroku，另外一個表明性的技術無疑就是 Buildpack。在 Docker 鏡像機制出現以前，使用 Buildpack 管理用戶應用的運行時構建，使得 PaaS 的運行時最終與語言無關，這無疑是很是聰明的作法。然而十多年過去，Buildpack 的模式早已暴露出許多問題。

一方面是官方支持的 Buildpack 數量少，限制多，好比運行系統僅支持 Linux 的 Ubuntu 發行版；某些 Ubuntu 安裝包在 Buildpack 中沒有安裝你便沒法使用；相對小衆的開發語言（如 Elixir）均不支持；又或者是你的應用包含多種語言，使用起來就變得複雜；
另外一方面，你也許能自定義或者找到第三方的 Buildpack 知足需求，可是沒有人來保證它的穩定。一旦出了問題，你很難在本地運行 Buildpack 排查問題，而 Heroku 平臺的錯誤信息透出方式並不直接，日誌排查更是不便。

2017 年 9 月份，Heroku 最終仍是支持了基於 Docker 鏡像的運行時部署，然而至今爲止依舊有很多限制，其中最大的限制是存儲，只能使用 Heroku 的臨時存儲，這幾乎就決定了你不可能本身編寫像 etcd、TiDB 這類複雜的有狀態應用。

一切的本質，都在於 Heroku 給用戶提供的體驗是黑盒化的，爲用戶屏蔽基礎設施的同時，也使得用戶失去了改造的自由。這也是爲何即使像 Cloudfoundry 這樣理念極其相似的 PaaS 平臺，即使是開源的，依舊存在一樣的弊病。

**事實上用戶喜歡的是「白盒」，他們但願可以自定義基礎設施，能夠平行的替換或改造平臺的已有功能，而非只能侷限在平臺提供的能力之上構建。**就像咱們買了一輛車，在雨雪的極端天氣下，咱們但願能夠換雪地胎，而不是隻能加裝防滑鏈。

Kubernetes 的出現

而 Kubernetes 正是這樣一個白盒化體驗，它從何嘗試去屏蔽基礎設施，而是做爲一個標準化接入層，把基礎設施層的能力經過聲明式 API 暴露出來，將選擇權留給了用戶。正是在這樣一個開放世界裏，複雜有狀態應用的管理也終於得以在雲上落地了。另外一方面， Kubernetes 並非 PaaS。相比於 Heroku 官方提供了將近兩百個 add-ons（插件））用於加強包括數據庫、監控、日誌、緩存、搜索、分析、權限等能力，而 Kubernetes 則強調強可擴展能力，但願用戶本身能夠經過編寫 CRD Operator 新增任意能力。

那麼，這兩種作法的區別是什麼呢？

封閉、限制 vs 開放、自由

衆所周知，Heroku 一直是一個「主觀」的 PaaS 平臺，12-factor 表明了應用必須雲原生化的強硬觀點，這一點毋庸置疑是正確的，並且很是了不得。但若是觀念不能與時俱進，那麼「主觀」就會變得危險。就好比容器和虛擬機都已經至關普及的今天，Heroku 依舊堅持應用只能運行在 Heroku Dynos 上面。雖然這種統一很大程度上爲管理提供了便利，可是這也使得用戶丟掉了不少靈活性，更重要的是，運行時的巨大差別，開始讓不少用戶以爲本身與更普遍的社區「格格不入」。

不過，Heroku 有屬於本身的封閉生態，除了上文提到官方維護的 Add-ons 之外，還有方便用戶一鍵部署到 Heroku 平臺的 4700 多個 Buttons 應用和用於自定義運行時和構建流程的 6300 多個 Buildpacks，這兩大功能都容許用戶自定義並能夠申請註冊到官方的應用市場中，數量着實驚人。這樣繁榮的社區怎會被人詬病？出於好奇，筆者總體分析了一下這些項目。

下面兩張圖分別是 Heroku Buildpack 和 Buttons 的項目統計：

咱們能夠看到，Buildpack 只能在 Heroku 平臺使用，因此 star 數量表明瞭你們對項目的關心，而下載量則表明了用戶的使用頻度。圖中，6000 多個 Buildpack 的 star 數和下載安裝量均在 50 之內，而超過 500 個 star 和 500 次下載部署的項目均只有 30 個左右。再來看 Buttons 中的項目，因爲這些項目自己還能夠部署到 Heroku 之外的其餘平臺，因此就只看在 Heroku 的部署下載量反映你們的使用頻度，而圖中超過 500 次部署的 Buttons 項目只有 6 個。原來這一切竟只是表面繁榮。

面對這樣一個統計數據，咱們很難說 Heroku 的封閉生態是成功的。

Buildpack 本質上是對進程的構建和打包，一樣的工做業界幾乎都已經統一經過 Dockerfile 構建鏡像解決。與 Buildpack 只能在 Heroku 平臺上使用的封閉生態不一樣，Docker 鏡像以及 OCI 容器和鏡像規範的出現，大大推進了基於容器鏡像的應用打包方式走向了全面繁榮。而用於存儲鏡像的 Docker Registry 也是人人均可以搭建的鏡像倉庫。從數字上看，僅官方鏡像倉庫上的鏡像數量就超過了 300 萬，更有數千鏡像下載量超過了 100 萬，這纔是成功生態應該有的力量。

而在 Kubernetes 生態中幫助應用打包並能夠一鍵部署 CRD Operator 的 Helm Chats 也與 Heroku 的 Buttons 相似。一樣， Helm Charts 的託管平臺是能夠自由搭建的，而 Chart 自己則在任何一個開源或者商業版本的 Kubernetes 上均能運行。雖然沒有明確的統計數據，可是像 Helm Hub、Kubeapps Hub、CloudNative App Hub 等 Charts 託管網站裏的內容看起來也已經取得了不小的成功。

Heroku 們的將來？

從上述觀察來看，Heroku 過去最重要的教訓，在於不夠開放而錯失了本來屬於本身的雲原生應用生態。而在 Kubernetes 項目成爲基礎設施主流以後，Heroku 以及它的開源繼任者 Cloud Foundry 仍是很難走出「被故意忽視」的困境。這個困境的關鍵並不在於它們是否是基於 K8s 構建的，而是它們能不能帶來像 K8s 同樣的開放與自由。

但是，另外一方面，Kubernetes 自己從始至終都不是一個面向最終用戶的體驗，也不是最終用戶想要的東西。Kubernetes 自身「白盒化」的體驗正在爲愈來愈多的業務研發和運維帶來「太複雜」的困擾。而這個社區裏大量的 CRD Operator 則像一個個煙囪，彼此孤立，不能聯動，並且有大量的冗餘（好比：Kubernetes 中永無止盡的 Ingress 實現）。這一切都說明，純粹使用 Kubernetes 並不是託管雲原生應用的「標準答案」。而那些試圖「給 K8s 寫個界面」的 PaaS 構建者們，彷佛又陷入了 Heroku 的困境。這種變化，也讓 PaaS 與 Kubernetes 之間的關係愈來愈複雜和不清晰。

從 Kubernetes 到「以應用爲中心」的美好將來之間，全世界的 PaaS 工程師其實都在期待一項全新的技術可以彌補這之間的鴻溝。阿里雲原生應用平臺團隊的作法是，經過爲應用「建模」的方式來解決這個問題，這也正是 Open Application Model (OAM) 開源項目得以建立的重要目的。