PaaS 的祖先 Heroku，连相当值钱的“免费套餐”遗产都丢掉了

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