Heroku 的「得」與「失」

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

限時福利：張磊、李響等人撰寫的《cncf x 阿里巴巴雲原生技術公開課》限時 0 元領取中。

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

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

正是這樣強大的能力，使得 heroku 成為了 paas 領域事實上的標準，無論是後續的 cloud foundry 還是 openshift，似乎都沒有對 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 的模式早已暴露出許多問題。

2017 年 9 月份，heroku 最終還是支援了基於 docker 映象的執行時部署，然而至今為止依舊有不少限制，其中最大的限制是儲存，只能使用 heroku 的臨時儲存，這幾乎就決定了你不可能自己編寫像 etcd、tidb 這類複雜的有狀態應用。

而 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 的專案統計：

從上述觀察來看，heroku 過去最重要的教訓，在於不夠開放而錯失了原本屬於自己的雲原生應用生態。而在 kubernetes 專案成為基礎設施主流之後，heroku 以及它的開源繼任者 cloud foundry 還是很難走出「被故意忽視」的困境。這個困境的關鍵並不在於它們是不是基於 k8s 構建的，而是它們能不能帶來像 k8s 一樣的開放與自由。

可是，另一方面，kubernetes 本身從始至終都不是乙個面向終端使用者的體驗，也不是終端使用者想要的東西。kubernetes 自身「白盒化」的體驗正在為越來越多的業務研發和運維帶來「太複雜」的困擾。而這個社群裡大量的 crd operator 則像乙個個煙囪，彼此孤立，不能聯動，而且有大量的冗餘（比如：kubernetes 中永無止盡的 ingress 實現）。這一切都說明，純粹使用 kubernetes 並非託管雲原生應用的「標準答案」。而那些試圖「給 k8s 寫個介面」的 paas 構建者們，似乎又陷入了 heroku 的困境。這種變化，也讓 paas 與 kubernetes 之間的關係越來越複雜和不清晰。

「阿里巴巴雲原生關注微服務、serverless、容器、service mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。」

閱讀全文:

Heroku 的「得」與「失」

人生得與失

2018，蘋果的得與失

車禍後的思考得與失

Heroku 的「得」與「失」

人生得與失

2018，蘋果的得與失

車禍後的思考 得與失

相關推薦

車禍後的思考得與失