Heroku怀旧陷阱：为什么“一键部署”不是唯一的答案

---

前言：我也曾是那个喊“想要Heroku”的人

说实话，我在Slack频道、Hacker News评论区、深夜的Discord吐槽里，看到过无数次这句话：“我就想要个像Heroku一样的东西。”我自己也说过。但后来我发现，我当时根本不知道自己在说什么。

不是说Heroku不好。它确实牛逼。那些打造它的人，理解了很多基础设施公司至今没搞明白的事情。但2022年Salesforce砍掉免费套餐（最近又宣布停止向新企业客户销售）之后，大家开始迁移，有意思的事情发生了：几乎所有人都抓错了重点。

他们以为人们爱Heroku是因为“部署简单”。于是他们造了更简单的部署工具。但根本不是这回事。

Heroku真正卖的是什么

大概2019年左右，我跑着一个副业项目在Heroku上。我压根不用考虑基础设施。push到Git，它就部署了。Postgres数据库就在那里。如果需要消息队列，加个插件就行。所有东西都在同一个心智模型里，而这个模型在正常工作日子里，在我脑子里占的空间几乎为零。

Heroku卖的不是部署流水线。它卖的是认知归零——你完全不需要把基础设施当成一个需要思考的东西。

这个区别比你想象的重要得多。因为一旦你开始考虑基础设施，哪怕只是一点点，它就会渗透到所有事情里。你会根据“什么部署起来简单”来做产品决策，而不是“什么是对的”。你会因为不确定各个组件怎么连起来而推迟发布。你会花一个周五下午调试为什么你的应用在两家不同的云服务商之间连不上自己的数据库，而不是去开发那个能带来三个新客户的功能。

Heroku把这一切都消除了。一个平台，所有东西预配好，一张账单，出问题了一个地方查。

替代方案们：只做对了一件事，其他全搞错了

Heroku免费套餐死后，Render、Railway和Fly.io站了出来。这三家都比你自己折腾EC2强得多。我都用过，不想对任何一家不公。但实际用起来是什么样呢？

你在Render上部署应用。然后你创建一个Postgres数据库（也在Render上），把连接字符串粘贴到环境变量里。然后你发现需要后台任务，于是注册Upstash或者加个Redis实例。然后你需要对象存储，所以去AWS开个S3 bucket——因为Render没有这功能。

现在你有三个控制台、三份账单、三套网络规则要搞定，以及用环境变量和祈祷拼凑起来的三家服务商带来的心智负担。

Railway更接近Heroku当年的愿景，感觉更集成。但它底层跑在AWS上。你在付Railway的利润，再加上Amazon的利润，等于你付了两次超大规模云服务商的税：一次给Amazon买实际计算资源，一次给Railway换取不用直接跟Amazon打交道的特权。

Fly.io做了最大胆的选择：他们用裸金属。真实硬件，没有AWS在底下，从结构上解决了双重利润问题。但集成故事一直没讲完。你的Postgres在Fly上仍然是一个需要单独连接的东西。那种让Heroku显得神奇的“万物互联”的感觉并不存在。你仍然需要自己拿着那些线。

没人谈论的事：你自己的服务之间的出站流量费

有件事我花了比预期更长的时间才完全理解。当你的应用、数据库和存储桶分属不同的服务商，或者甚至只是同一个云服务商的不同服务时，数据在它们之间传输是要花钱的。通常不多，但直到突然变得很多。

一个应用每天从数据库读取10000次，处理一些结果，然后写入S3——这个数据流向是三个方向持续进行的。在超大规模云服务商支持的平台上，其中一些数据流动会跨越计费边界。但在一个计算、Postgres、存储和队列都跑在同一套裸金属网络上的平台呢？这些移动是免费的，因为数据从未离开过机房。

这不是假设。这是平台架构上的结构性差异，而且它会随着时间累积，以不会清晰显示在任何一张单独账单上的方式体现出来。

“有主见”的平台其实在干真正的活儿，不只是营销

我跟一些团队合作过，他们花了实际的工程时间来争论该用哪个消息队列系统。不是实现它，而是争论它。SQS vs. BullMQ vs. RabbitMQ vs. 某人在三年前一篇博客里读到的东西。

认为“有主见”的平台是好的，这个论点不是说你没有能力做那个决定。而是说那个决定没有你想象的那么重要，而你花在做决定上的时间，本可以用来做真正能让你的产品与众不同的东西。

Postgres对几乎所有的初创公司来说都是正确的数据库。S3兼容的存储能处理几乎所有的文件存储场景。一个可靠的消息队列就是一个可靠的消息队列。这些都不是有趣的决策。它们在大概十年前就已经不再有趣了。有趣的决策在你的产品里。

一个有主见的平台会强迫你停止重新争论那些早已被解决的问题。这不是限制。这正是它的意义所在。

关于锁定问题的诚实回答

当人们看到一个垂直整合的平台时，最常见的反驳是：“如果我想离开怎么办？”这是个公平的问题，我以前也问过。现在我意识到的是：锁定问题几乎总是理论上的，而且通常是由那些从未真正从某个平台迁移过的人提出的。

真正的锁定需要一些专有的、你的代码依赖的东西。一个只在该服务商那里能用的自定义SDK。一个在其他地方不存在的查询语言。一个需要重写你的应用才能离开的部署模型。

如果你的应用跑在容器里，使用标准的Postgres连接字符串，用AWS SDK跟S3通信，通过标准协议向队列发布任务，那么你没有被锁定。你只是部署在某个地方而已。迁移路径就是一个pg_dump、一个bucket复制、再加一个docker push。我周末就能完成这样的迁移。

真正制造锁定的平台，是那些把所有东西抽象成它们自己的专有层的平台。带有自定义运行时的Serverless函数。带有专有查询特性的服务商特定数据库。只存在于一个网络上的边缘计算。这些才是值得警惕的东西。

每个替代方案到底在哪里掉链子

Render是最容易推荐也最容易“长出去”的。部署一个Next.js应用，托管一个Postgres，搞定。问题大概在第三个月出现，那时你需要后台任务和对象存储。Render这两样都没有原生支持。于是你去Upstash搞队列，去AWS搞S3存储。现在你有三个控制台、三份账单、三个需要互相信任的网络。部署那一步花几分钟。但周围的所有事情要花一下午。

Railway感觉比Render更集成，开发者体验确实好。但它跑在AWS上。这不是对团队的批评，这是一个结构性事实，会带来下游后果。就像我之前说的，你在付Railway的利润加上Amazon的利润，而且你的应用和数据库之间的数据传输可能跨计费边界——取决于Railway怎么配置的。成本在任何一张单独的账单上看起来都不吓人，但它会累积。

Fly.io做了最有趣的架构选择。真实硬件，没有超大规模云服务商在底层，从结构上打破了双重利润问题。我在Fly上部署过，边缘性能是真的。但计算和Postgres仍然是需要你自己连接的两样东西。存储仍然需要跟外部服务商打交道。那种“万物互联”的感觉不存在了。