放棄“免費套餐”，Heroku的遺產又少了一個

Heroku

作者 | Tina ，劉志勇

| 來源

| InfoQ

8 月 25 日，Heroku 釋出通告，表示為了防止欺詐和濫用，將從 2022 年 11 月 28 日開始停止提供免費產品計劃，並關閉免費的 dynos 和資料服務，以後將重點關注核心客戶。

Heroku 的免費計劃，曾為眾多想進入科技行業的人打開了一扇門。

Heroku 是一種平臺即服務 （PaaS），是 2007 年建立的第一批雲平臺之一，可讓開發者將 git 儲存庫推送到雲端，然後神奇地獲取在某處執行的應用程式的 URL。一位開發者說，這種魔法對他的職業生涯起到了很大的催化作用，“當年作為學生，沒有信用卡，也窮，Heroku 的免費計劃幫助我打開了真正瞭解網站如何工作的大門。如果沒有 Heroku，我永遠無法達到今天的水平，以至於現在我真的無法說清它對我的職業生涯曾經有多麼重要！”

像他這樣透過 Heroku 學習程式設計的，不是少數。在今年 StackOverflow 2022 年度開發者調查報告中，有一個關於“雲平臺”調查問題，以瞭解開發者在過去一年中主要在哪些雲平臺中進行開發工作。在針對“Learning to Code”群體中，Heroku 以 35。24% 的比例位列第一，超過了 Google、AWS 和 Microsoft 。

實際上，這個革命性的產品，從技術上講已經停滯不前，其產品也名存實亡，一位 Heroku 前員工在 HN 上寫道：“你必須追溯到 Heroku Changelog 才能找到任何不是語言版本升級或特性刪除的內容：

https：//devcenter。heroku。com/changelog

。我認為特性凍結是發生在 2018 年。”

今年 4 月，Heroku 還曾發生一起嚴重的安全事故，社群反應激烈，當時一名攻擊者獲取了 Heroku 的主資料庫（在我們那個時代稱為 core-db）的訪問權，並洩露了它的內容，包括雜湊密碼和用於 GitHub 整合的機密。

現在，短短几個月過去，Heroku 再次讓社群感到悲傷，它關閉了免費計劃。

對此，一位開發者說，“Heroku 對我來說已經死了，我看到一扇又一扇進入科技的門被牢牢地關閉和鎖定。”

“我只是希望下一個時代能給每個人帶來公平的技術。希望資本有點耐心，在它發光之前不要殺死它。”

雖然 Heroku 在走向衰落，但它也給如今的軟體行業留下了很多遺產。

Heroku 有哪些遺產

Heroku 由三位 Ruby 開發人員（James Lindenbaum、Adam Wiggins 和 Orion Henry）於 2007 年建立，僅僅三年後就被收購，SaaS 巨頭 Salesforce 最終擊敗 VMware，以 2。12 億美元的價格將 Heroku 收到囊下，當時該公司只有 30 名員工。

2011 年，Heroku 的聯合創始人 Adam Wiggins 根據針對上百萬應用託管和運維的經驗，釋出了著名的“十二要素應用宣言（The Twelve-Factor App）” 。他們那時候絕對不會料到這份宣言會在之後數年時間裡，成為 SaaS 應用開發的啟蒙書。同時這也奠定了 Heroku 在 PaaS 領域的地位，成為了雲上應用開發規範化的基石。

Heroku 的工程負責人 Jason Warner 說：“我相信 Heroku 是在 2014 年到 2017 年之間最具革命性的產品，對 Web 開發產業的推動作用非常大。它也是同時代最受爭議的專案之一，因為它實在太超前了。當時它看起來就像魔法一般，人們都被它深深震撼了。”

Heroku 的人氣一直都歸功於其簡潔、優雅和可用性的優勢，它率先將重心放在了開發人員的體驗上，致力於讓部署像開發流程那樣無縫流暢。

Heroku 是最早喊出“以應用為中心”，大規模幫助應用上雲的產品。正是圍繞“以應用為中心”這樣先進的理念，使得 Heroku 從一開始便擁有了至今看來都非常誘人的功能：

使用者無需關心應用背後的基礎設施是什麼，Heroku 負責維護背後的一切。

這句看似簡單的話背後隱藏了巨大的複雜性，試想下某個軟體或系統爆出安全漏洞後給你帶來的窘境，又或者你想使用一個數據庫服務時卻不得不維護一個數據庫例項。而在 Heroku， 這一切麻煩你都無需關心。使用者可以直接從開發語言出發，選擇對應的技術棧，透過 heroku create 這樣簡單的命令，將應用託管到雲上。主流的開發語言，均能在 Heroku 中找到對應的選擇。從程式碼的變動自動觸發軟體的部署交付，清晰的工作流、多樣的釋出策略，直到後來的很多年都是 DevOps 們夢寐以求的功能。

Heroku 的聯合創始人，如今是初創企業加速器 Heavybit 的合夥人 Linden baum 說：“震撼人心的是 Git 推送部署，這也是人們從 Heroku 學到的核心思想，大家原本以為必然要做的很多事情都用不著操心了。我們的願景不是給豬塗口紅，而是重新思考怎樣徹底解決這個問題。”

賣給 Salesforce 算是一種成功嗎？

之前有人在 Twitter 上提出了一個不那麼簡單的問題：“Heroku 是成功還是失敗？”

對此問題，答案分成了兩派，正反雙方都有很多人參與。一部分人認為 Heroku 已經失敗了，但是另一部分人恰恰相反——他們認為 Heroku 是一個不折不扣的成功。

從成功的角度來講，以 2。12 億美元賣給 Salesforce 是一個明顯的勝利。但從產品壽命或持久的行業技術方面來說，它又是失敗的。

以 2。12 億美元賣給 Salesforce ，最顯而易見的是，在如此規模的收購中，有些人發了財，也給一些新員工享受著高科技薪酬和優厚待遇的條件。

Heroku 的粘附力出乎意料。鑑於這一產品已經多年基本未變，加上市場中的新成員眾多，也接受了更大範圍的雲計算競爭，但是直到今天，Heroku 依然可以成為可信的平臺。很多開發者很瞭解這個產品，並且它的廠商鎖定是最低的，讓開發者不需要在企業的非核心服務的運營 / 基礎設施上動手。各大雲計算提供商都推出了新的業務，這些業務都是為了滿足 PaaS 層（像亞馬遜雲科技那樣，也不只是一家），但是直到現在，幾乎沒有什麼公司可以與 Heroku 的簡化工作流程和簡單操作相媲美。

除此之外，這家公司還做了許多了不起的工作。

外包運維：

長期以來，很難在網際網路上部署軟體。後來，PHP 問世，它的語法簡練，部署過程簡單，贏得了整個世界，但是也存在許多缺陷。部署一個通用的棧非常困難，那時候，Rails 需要安裝一個負載均衡器，為每個伺服器提供反向代理，CGI 程序，並且可以隨時監控和執行所有必要的操作。Heroku 使這一問題得到了極大的簡化，它使開發者集中精力在構建軟體上，而非在配置和執行基礎設施上。在當今世界，這顯然是一種有利條件，但在那時並非如此。

Postgres：

Postgres 在過去的十年裡的發展得益於很多方面的原因，其中包括其卓越的核心進展以及其競爭對手的相對衰退，但是透過使其成為平臺提供的核心部分並高調宣傳，Heroku 成了平臺的重要組成部分。

容器：

很少有人記得它，但 Heroku 在容器還不流行的時候就已經開始運行了，使用 LXC 作為其 Cedar 棧的核心技術。

CLI：

和 Git 本身一樣，Heroku 的 CLI 也是該產品中很關鍵的一環。Unix 命令列工具已有數十年之久，但是一家公司推出一種專用 CLI 還是很有創意的，並且很快就得到了推廣。

DX 和 CLI：

CLI 以及一個廣泛的面向開發者的產品，播下了最終發展成 DX 的種子，現在 DX 已經成為科技行業的一個專門分支。

Buildpack：

Buildpack 是如何部署用特定語言編寫的應用的通用公式，是 Dockerfile 的前身，也可以說是一種更合適的抽象層。在 Cedar 棧的初期，自定義 Buildpack 就已經為使用者提供了支援。目前，Heroku 之外的其他幾個雲計算提供商也支援這些技術，比如 Digital Ocean 和 GCP。

這是一份相當令人印象深刻的清單——即便是其中的一兩個，也會比大多數科技公司在世界上留下的印記更多。

但是，這些專案也有一個共同的潛在趨勢——儘管它們的創意很偉大，並且在未來的服務部署方式中會留下持久的印象，但它們都並沒有為 Heroku 產品本身帶來持久的剩餘價值——其他平臺抓住了這些概念並獲得了收益，即使撇開商業方面，也沒有具體的技術會被歸於 Heroku。儘管 Docker 作為一家公司可能註定以失敗告終，但它將作為基於容器的部署的始祖而被記住幾十年。未來關於 2010 年代的歷史將談論 Docker 到 OCI 的演變，但是 Heroku 充其量只能算是一個註腳。

Heroku 是雲計算的終極創意工廠——比如 “十二要素應用宣言（The Twelve-Factor App）” 、抗侵蝕和 DX，這些概念將會經得起時間的檢驗，但是在它們的受益者中，很少有人會認識到它們與 Heroku 的關係。

想象力與現實

沒有多少持久的產品或技術影響是硬幣的一面，而另一面，則是對一個擁有無限潛能卻從來沒有實現過的宏偉願景感到失望。

Cedar 棧確實是一個真正的天才之作。之前的 Aspen 和 Bamboo 棧都有很大的限制，僅能支援特定棧的特定版本，並且有很多特殊的條件。Cedar 讓 Heroku 成為可以執行一切的平臺——使用者可以透過 Buildpack 和 Procfile 帶來自己的棧，它複雜的內部狀態機和路由層使得執行在其上的應用變得非常強大。

2012 年，Cedar 的交付勢頭非常好，雖然取得了巨大的成功，但是它僅僅被認為是一個更加雄心勃勃的專案的第一步。很快，它就會被推廣到可以處理不同形狀和大小的軟體，而現在 512MB 的容器僅僅是附帶的第一選項。即使是最大的資料處理應用也可以部署在 10GB 或 100GB 記憶體的容器上，一直到最小的一次性雲 grep 執行只需要幾兆位元組。如此快速和簡單，以至於不在 Heroku 上執行簡直就是瘋了。

它已經成為模組化。對於大多數用途來說，共享路由器是一個足夠的選擇，但是大使用者可能希望實現自己的路由，從而避開其他企業的雲計算，或者提供他們自己高度定製的路由配置。甚至在 Heroku 的“核心”中，你也可以進行交換，因此你仍然可以使用 Heroku 來構建、編排和監控你的應用，但是它們會在你自己的專用單租戶伺服器上執行。

自託管的奇點

Heroku 雲將變得如此可擴充套件，如此健壯，就像一個自引導的語言編譯器一樣，它能夠自託管。像平臺 API、動態狀態機和路由器這樣的核心元件，都將作為 Heroku 應用執行，並獲得所有 DX 的人體工程學和健壯性。這種充滿樂觀和雄心勃勃的願景被稱為“自託管的奇點”。

它將是反亞馬遜雲科技的。亞馬遜雲科技在新使用者首次登入時，就向他們展示了成千上萬個錯綜複雜、相互交叉的原始概念，而 Heroku 公司的願景就是不讓新使用者看到。他們從基本的 git push heroku master 和單一的 dyno 應用起步，但是當他們的軟體不斷髮展，他們的要求也越來越複雜，當他們需要的時候，新的原語就會逐漸顯露出來，比如帶有入口 / 出口規則的 VPC、帶有備選基本映象或架構的可配置主機。SSH 訪問、靜態 IP 等等。就像洋蔥一樣，可以一層一層地剝開。

還有一些其他的東西。“十二要素應用宣言（The Twelve-Factor App）”中的“支援服務”描述了諸如資料庫等永續性服務的“額外資源”，它作為孤立的資源存在，能夠被任意地附加和分離到更短暫的應用中。Heroku 用了好幾年的時間來開發這一特性，儘管他們成功了，但是 Heroku 在產品領導力方面的黃金時代已經結束，而且他們也沒有取得什麼進展來說服別人相信它是個好點子。

定價又是一頭難以捉摸的野獸。從免費層跳到付費應用的成本是一個巨大的飛躍，從產品推出的第一天起，使用者就抱怨過這個問題。最終，一個新的定價模式確實推出了，但是並沒有幫助人們消除最初的憂慮。

檢查失敗

那麼，到底發生了什麼呢？一切成功的基石都已經就位，因此無法實現其雄心勃勃的願景並非必然。

運營陷入困境：

Cedar 進入後，由於一些不能控制的因素（us-east-1 在那段時期尤其糟糕），以及內部因素（有一段時間，Heroku 似乎每隔一天就會有一個糟糕的部署），導致了產品的頻繁故障，已經升級到了成為生存責任的地步。產品的工作被取消，取而代之的是對運營的支援——設定指標、警報、安全部署流程，並且廣泛地建立運營能力。

產品週期：

尤其是初期，沒有制度上的框架來交付新特性。這是有可能的，但是經常需要你自己發出拉取請求或者給某個人傳送一個請求來幫助你修改。即使有推動新特性的強烈動機，它也常常會從組織 / 服務的邊界中消失殆盡。Heroku 也存在著令人不齒的退化情形，比如將組織功能構建在核心 API 之上，變成了一個單獨的微服務，這是由於沒有任何使其更加整合的機制。

Docker 視野狹隘：

Docker 的第一個版本引起了如此大的轟動和廣泛的興趣，以至於 Heroku 之中的很多人對它產生了一種不健康的痴迷。Heroku 的前員工說道：“我們內化了一種失敗主義的態度，認為 Docker 容器是未來，而我們所做的是過去的事。”從某些方面來說，這是對的，但是 Dockerfile 仍然是非常低的抽象層次，低到有些不可取。我們現在所見，容器技術已經成為許多部署棧的基石，但更多的是作為一種原始技術，其中有許多技術可以提高其工作效率。在很多方面，Buildpack 對應用開發者來說，是一個更好的抽象層，他們不必為任何事情編寫 Dockerfile，只要用 Gemfile、Cargo。toml 或 go。mod 等棧中常用的工具，然後讓構建過程找出如何將其“烘焙”成一個可部署的映象。從那以後，如果說基礎層需要更新，或者某種程式語言的次要級別 / 補丁級別需要更新，都可以廣泛地進行，而不必調整每個專案的 Dockerfile。

下一個棧的固定性：

Heroku 的棧是以樹命名的。Aspen、Bamboo、Cedar。Cedar 比 Bamboo 有了質的飛躍，雖然 Heroku 的下一個目標是建立一個比 Cedar 更好的棧，就像 Cedar 比 Bamboo 好一樣，但在這種情況下，員工會把 Cedar 作為一個過去的種子埋在他們的腦海裡，從而阻礙了他們對它的大量投資。回顧過去，從目前可用技術的融合情況來看，可能並沒有一種棧能比 Cedar 好得多，就像 Cedar 對 Bamboo 那樣。最好還是把精力集中在逐步改善 Cedar 上，而不要在地平線上找什麼“靈丹妙藥”。

構思者 / 運營者的分歧：作為一家大公司內部資金雄厚的小公司，曾經有過一段時期，我們有一個相當獨特的情況，就是僱傭了一批員工，他們花費大量的時間進行實驗、原型設計和創意，就好像在公司內部開著一個小型的貝爾實驗室或者施樂 PARC。隔著籬笆，就是那些頑固的服務工程師，他們經常忙於解決運營問題，很少露面。構思者們沒有能力把所有的事情都投入到生產中，同時，運營人員也沒有足夠的時間和精力去進行實質性的產品改善。這導致了很酷炫的內部演示，但是可以預料的是，他們不會有所動作。

總而言之，特別是考慮到之前發生的安全問題，Heroku 作為一個自維持的產品是一個失敗。作為一個多產的思想創造者，以及無數當前和未來工具和平臺的直接祖先，Heroku 取得了巨大的成功。

參考資料：

Heroku 的下一章：

https：//blog。heroku。com/next-chapter

https：//xeiaso。net/blog/rip-heroku

如何理解 Heroku 提出的 12 要素應用？

https：//mp。weixin。qq。com/s/EUPo12ZPpBp_P1b7wouYtw

Heroku 的衰落：

https：//www。infoq。cn/article/gvcgP6XitdHjy169oAk5

https：//brandur。org/nanoglyphs/033-heroku