Heroku 的衰落

作者 | Scott Carey

策劃 | Tina

IT 史上隨處可見一時風光，最終卻銷聲匿跡的平臺。它也有過輝煌，影響力一度廣泛，但世上沒有不散的筵席。

1Heroku 的革命性遺產

在實踐中，使用 Heroku 時通常需要一個部署到唯一域的通用運行時，這個域會將 HTTP 請求路由到一個虛擬的 Linux 容器（Heroku 稱之爲 dyno），這種容器散佈在運行於 AWS 服務器上的一個 “dyno 網格” 中。Heroku 的 Git 服務器負責存放由授權用戶推送的應用程序存儲庫。高級企業客戶還有專用的單租戶專用空間的選項可用。

Gartner 知名副總裁 Yefim Natis 說：“Heroku 是第一個真正的雲原生開發環境。他們實質上發明了基於容器的計算模型，這種模型如今廣泛流行。”

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

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

2 從技術上講，Heroku 已停滯不前

十年過去了，最初的聯合創始人都沒有留在 Heroku。與此同時，在 Salesforce 的領導下，該公司的收入穩步增長，但核心產品基本沒有變化，只能眼睜睜看着行業飛速前進。

Jacob 在推特上寫道：“Heroku 就像是一個失落的文明。美麗、不朽，但卻沒有未來可言。”

Gartner 的 Natis 表示，儘管 Heroku 幫助開拓了很多簡便的雲原生軟件開發技術，但它花了很長時間才能適應由 Kubernetes 編排的 Docker 容器引出的那些新興行業標準。“鑑於它的架構和先鋒元素，我認爲這種停滯始於 Salesforce 的收購。我覺得他們被留在了那個時代。”

從 2013 年到 2016 年擔任 Heroku 首席執行官的 Tod Nielsen 從業務角度給出了一個看法：“Salesforce 在將 Heroku 擴展到更多公司方面做得很好，但是從技術上講，他們放棄的是年輕人的那股創新勁頭。”

Heroku 的底層 dyno 網格系統基於 AWS EC2 實例構建，自然可以在複雜性和可定製性與簡單性和速度之間做出權衡。這些權衡讓這個平臺優雅易用，但某種程度上也缺乏靈活性。

但是，隨着 Heroku 擴展到其他語言，越來越多的問題浮出水面。“我認爲我們想簡化一切的想法可能爲時過早了。當你試着轉向 Java 這個擁有大量工具鏈和深度集成工作方式的社區時，事情變得非常棘手，”Blake Mizerany 說，他是 Heroku 在 2008 年的第一位全職工程師。“當我們告訴那些想要在 Heroku 上構建產品的公司時，這讓他們很失望，因爲他們總要做一些不在 Heroku 理想路徑上的事情。”

對於需要更多靈活性，在需要的位置運行應用程序的組織而言，來自競爭對手 VMware 的 PaaS Cloud Foundry 允許本地部署以及掛接到企業環境所需的一系列複雜定製，從而提供了一條更誘人的路徑。VMware 還投資了一家諮詢機構 Pivotal Labs，該機構的任務是在 2010 年代初向更傳統的組織（例如 Orange 或美國銀行）宣傳平臺方法。

相比之下，Heroku 在允許企業客戶以混合模式和多雲模式運營方面進展緩慢。2016 年，Salesforce 希望使用新增的 Private Spaces 來解決這一問題，其允許客戶在一個專用環境中運行，連接到本地系統，並有六個地理區域可選。類似地，Salesforce 最近推出的 Hyperforce 應該能讓所有 Salesforce 客戶在公共雲中的服務位置方面有更多選擇。

Heroku 和其他 PaaS 選項之所以能夠蓬勃發展，是因爲它們能夠卸除開發團隊面對的複雜性，從而讓團隊更專注於爲客戶提供新功能。問題是，大多數組織都存在固有的技術債務和無法繞過的工作方式，像 Heroku 這樣特立獨行的事物侷限性太大了。

RedMonk 的另一位聯合創始人 Stephen O’Grady 說：“到頭來，人們需要自己組裝和維護的零件太多了，在這種情況下，我們看到大家想要的就是 Heroku 之類的東西，希望開發人員只專注於編寫應用程序。我們聽到的很多抱怨，例如用戶花費大約 40％的時間糾纏於 Jenkins。訣竅是要具有足夠的靈活性以適應各種用例，而 Heroku 這樣的產品被證明侷限性太大，或者太特立獨行了。”

3 超越 Heroku 的侷限

對沖基金和金融服務公司 Two Sigma 的平臺工程主管 Camille Fournier 將 Heroku 描述爲軟件開發流程部署領域的 “黃金標準”。但是根據她的經驗，“開發人員遲早遇到 Heroku 這樣的平臺所能達到的極限，並開始走上新的道路。”

Fournier 相信，任何快速發展的工程組織最終都會面臨這些侷限。“當你需要構建自己的平臺時，這種趨勢會變得顯而易見。如果你使用的是 Heroku，就會遇到擴展限制，看到團隊開始離開平臺並做自己的事情，“她說。許多決定脫離 Heroku 的組織（例如流媒體平臺 Hulu）都在尋求構建自己的內部平臺，他們花了無數時間來追求類似 Heroku 體驗但滿足其業務特定要求的平臺願景。

RedMonk 分析師 Governor 在推特上寫道：“現代技術行業中，人們基本上都在不斷髮明着 Heroku 的各種翻版。”Jacob 說：“當一個事物如此美好時，它會有種種變體也就不足爲奇了。”

Jacob 同時指出：“但這是有代價的。接觸它的每個人都有一種看法。問題在於這些看法不僅是看法，當你在軟件上開展業務時，它們是硬約束。它不是可替代的，而且與普遍的看法相反，這些限制實際上是獨一無二的。”

對於許多像 Mizerany 這樣的 Heroku 早期工程師來說，模仿確實是最高的致敬。“對我來說，我們當年構建的東西是每個人今天都必須構建的，這可能是至高的讚譽，” 他說。

4Heroku 太昂貴了嗎？

對於那些很快就覺得自己正在超越 Heroku 方案限制的組織來說，即便他們真的很喜歡那種開發體驗，Heroku 的定價也往往成爲關鍵的阻礙因素。

Warner 說：“定價一直是一個錯誤，我們從未解決過。在 Salesforce，你必須在定價中包含利潤。我認爲你可以擴展 Heroku（它運行着一些世界排名前 20 位的網站），但是你必須換一種思考方式。”

Heroku 通常是按 dyno 定價的，爲企業客戶提供了許多高級附加組件和高性能選項，因此隨着業務的增長，成本會迅速上升。性能最高的 14GB dyno 每月每個 dyno 的價格爲 500 美元，這僅僅是一個開始。RedMonk 的 Governor 說：“有些人願意爲這種令人難以置信的體驗付費，但對於許多人來說這樣的成本越來越難以接受。”

以軟件測試公司 Rainforest 爲例，該公司在開始達到其數據庫計劃的限制，並且成本開始呈螺旋式上升之後，於 2019 年從 Heroku 遷移到谷歌的 Kubernetes 託管服務（GKE）。Rainforest 的前高級架構師在一篇公司博客中寫道：“到去年末爲止，Rainforest 的大多數生產應用程序都運行在 Heroku 上…… 它讓我們得以擴展並在不維持大型運營團隊的情況下保持敏捷，整體開發體驗也是無與倫比的。但在 2018 年，我們顯然已經開始超越 Heroku 的限制了。”

Evans 寫道，即便對於那些通過小規模運營團隊來打理一切，以節約成本的企業來說，Heroku 也相當昂貴。至少對於某些計算密集型工作負載而言，當 Rainforest 添加了一些重要的與安全性相關的功能（例如虛擬私有云）時，Heroku 從昂貴變成了無法承受。

然後是金融科技公司 PensionBee，該公司在 2015 年在 Salesforce 的支持下從頭開始在 Heroku 上構建了其單體 Node.js 應用程序，所有數據均通過名爲 Heroku Connect 的高級附加產品同步。

PensionBee 的首席技術官 Jonathan Lister Parsons 認爲，如果考慮到總體擁有成本，圍繞 Heroku 的價格擔憂就顯得過分了。他說：“我考慮的重點是 Heroku 能夠讓你擺脫的所有那些麻煩事，這個名單上起碼有 20 件運維事項。是的，與 AWS 相比它很昂貴，但是你得到的是一個由上千人組成的團隊，他們負責的服務可以讓你的代碼順暢運行。”

話雖這麼說，“Heroku Connect 的價格仍然高得令人難以接受，而且隨着我們的發展和擴展，繼續使用這個方案已經沒有意義了，而且他們知道這一點，”Lister Parsons 補充說。

Salesforce 的一位發言人承認 Heroku 的成本確實高昂，但表示：“雲計算運維成本很高，我們需要確保考慮到所有成本。如果有人將 IaaS 成本與 Heroku 的 PaaS 產品進行比較，那麼他們可能會忽略 devops 的人員配備、管道、集成和 IaaS 基板對運維負載的影響。”

5Heroku 還剩下什麼？

像軟件產業中的所有事物一樣，Heroku 最近的掙扎可能在某種程度上反映了簡單的潮流趨勢。正如今天的一些開發人員會在裸機上構建應用程序一樣，一些開發人員也會在 Heroku 上構建，但在 Kubernetes 上構建纔是潮流。Jacob 說：“這並不是說在 AWS 或 Kubernetes 上做事會更好。實際上，對於那些非常適合 Heroku 和 Git 推送方式的事物來說，其他選項顯然不怎麼樣。”

如今，Heroku 的用戶通常來自資金雄厚的公司，這些公司擁有非常適合這種獨特 PaaS 的用例，並有足夠的財力來繼續在 Heroku 上大規模運營，例如現有的客戶 Everlane、Bonobos、Yobota 和 Cambly。

以 PensionBee 爲例，它將各種退休金合併爲一個計劃，供客戶通過 Web 和移動應用程序訪問。

CTO ListerParsons 表示：“我希望盡最大的努力盡快交付產品，因此像 Heroku 這樣的 PaaS 是一個有吸引力的起點。我們在努力確保當 PensionBee 擁有一百萬客戶時仍然適合 Heroku 和 Salesforce 的方案。是的，我們已經開始選擇其他最適合各種用例的東西，我們並不是 100％地依賴於 Heroku 和 Salesforce，但它們是基礎平臺。”

這是否意味着，作爲一種傳奇性的技術，Heroku 現在只侷限於爲有能力的企業提供優質的小衆服務？Wiggins 說：“我們經常會考慮像 AWS 這樣的優秀選項，它是爲所有人提供的方案，我不認爲 Heroku 是類似的方案。它是針對較小的受衆羣體的，而且效果很好。”

Jacob 說：“Heroku 尚未消亡，這是一家擁有數百名員工的龐大企業，而且很長一段時間都不會消失。但隨着時間推移，這一技術終會成爲歷史上的一個光輝時刻。”

6 無服務器能救得了 Heroku 嗎？

Heroku 在 Kubernetes 的世界中可能已經失去了光彩，但是無服務器應用程序的前景是否爲這一平臺的第二次輝煌打開了大門？

Gartner 的 Natis 表示：“無服務器的 Heroku 將是雲原生的 2.0 版，所有基礎設施函數都將由提供商隱藏並妥善維護。Heroku 想要繼續存在下去，他們必須走向無服務器，因爲他們開創的先河已成爲歷史。”

對於 Heroku 聯合創始人 James Lindenbaum 而言，考慮到與 Heroku 的關係，“無服務器是非常有趣的”，因爲 “這是少費多用趨勢的下一個潮流。但是，還沒有人想出如何將其整合到一個開發人員的完善心理模型中”，他說。“如果我們留下來的話，那可能是我們在 Heroku 所要解決的下一件事。這一般是需要創始人做的事情。你需要很高的威望才能承擔這種風險。”

目前尚不清楚無服務器是否是 Heroku 的發展方向，Heroku 目前由更大層面的 Salesforce Platform 總經理 Patrick Stokes 領導。但今年晚些時候 Salesforce Functions 的全面上市標誌着一個轉變即將到來。

Salesforce 發言人說：“Heroku 的下一件大事是通過 Salesforce Functions 將其功能與 Salesforce Platform 的其餘部分進行深度集成。”SalesforceFunctions“讓開發人員在 Salesforce 平臺上編寫與其數據和事件集成的代碼，然後在無服務器環境中按需以彈性規模運行它。”

如果無服務器成爲下一個行業標準，Heroku 肯定有機會重塑自己，以迎接下一波變革：“如果我今天再來一次，我會用無服務器代替微服務，”PensionBee 的 ListerParsons 說。“無服務器可以成爲 Heroku 涅槃重生的契機”。

作者介紹：

Scott Carey 是 IDG UK enterprise titles 的組編輯，主要爲 InfoWorld 撰寫文章。

原文鏈接：

https://www.infoworld.com/article/3614210/the-decline-of-heroku.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-JLUCMufD5rgNqMMU2cNYg