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 是成功還是失?。?rdquo;
對此問題，答案分成了兩派，正反雙方都有很多人參與。一部分人認為 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
