PaaS大迁移：创业公司到底该怎么选平台

说真的，Heroku这一出消息，整个开发者圈子都炸了。Salesforce宣布免费dyno没了，定价也改了，Twitter和Discord上哀嚎一片。

曾经那个"上手就能跑"的省心平台，突然变成了一个让人觉得"该分手了但得体面退场"的贵价选项。

于是乎，迁移大潮开始了。Render、Railway、Fly.io这些平台突然成了香饽饽，开发者们都在问同一个问题："你靠谱吗？"

我自己也算在这波迁移潮里摸爬滚打过，有些肺腑之言想聊聊——离开Heroku之后，你到底会遇到什么。

便宜是真便宜吗

先说最吸引人的卖点："迁移过来能省30%到40%的账单。"

这话不假。看看你现在的Heroku账单，dyno、worker进程、数据库实例加起来，确实挺肉疼的。省下来的钱，搁谁谁都心动。

但问题是——广告不会告诉你的那些事：你迁移的不只是主机，而是一整套思维方式和工作流程。 还有很多Heroku悄悄帮你打理好的运维工作，现在都得你自己扛了。

思维模式得转个弯

这才是有意思的部分。

Heroku用的是"应用为中心"的思路。你部署一个App，这个App里包含各种进程类型（web、worker、clock等等），它们天然就是一个整体。平台知道这些进程是一伙的。生命周期、环境配置、部署流水线，都顺着这个关系走。

很多新型PaaS平台不太一样。它们的基本单位不是"App"，而是单个的服务或进程。这样更灵活——你可以独立扩缩、配置、部署各个组件。但代价是，你得变成那个协调者。

打个比方：就像租一套带家具的精装公寓，和自己盖一个小木屋的区别。公寓（Heroku）家具配好了，水电都安排妥当，有物业帮你修修补补。小木屋（新型PaaS）给你完全的自由，但突然你得自己琢磨水管怎么走、电线怎么接、沙发摆哪儿。

说说迁移的真实情况

聊聊迁移过程中实际会发生什么。

大部分平台在"首次部署"的体验上做得挺棒的。连接GitHub仓库，配置几个环境变量，点一下部署——好了，已经在线上跑了。这部分确实让人眼前一亮，看来大家都是从Heroku的成功里学到了东西。

但问题是，你的应用不是一个服务，而是五个、十个，甚至更多。每一个都得单独配置、部署、维护。每一个有自己的构建流程、扩缩规则、健康检查。

这时候你才发现，你不再只是部署代码，而是在管理一整套互相配合但本身"互不相识"的服务群。

那些让人头疼的地方

有个场景我见过好几次：

你写了个blueprint.yaml之类的配置文件来定义基础设施即代码。这很好，一切都文档化了，可以版本控制，可以复现。

然后你顺手打开网页后台查个东西，发现页面上有个设置跟你的YAML文件对不上。于是你顺手在UI里改了。

现在问题来了——到底哪个说了算？是git里那个文件，还是刚才保存的页面设置？

这不是杞人忧天。这种模糊性会造成混乱，而基础设施上的混乱是很危险的。半夜两点出故障的时候，你得能立刻知道去哪找问题。

"拥有更多"背后的代价

现代PaaS平台经常宣传"你会拥有更多基础设施的控制权"。听起来像是赋能，实际上也确实是。更多控制、更多可见性、更多定制空间。

但拥有是有代价的。Heroku的路由层出问题，你开个工单等着。Render的部署遇到网络问题，你得自己调试负载均衡配置。Fly.io的应用需要特定内核参数，你得去翻文档——那些文档默认你懂底层原理。

问题不是这些平台不好。它们其实挺好的。问题是，你的团队有没有精力、有没有能力、愿不愿意为了省点钱去扛这些运维复杂度。

怎么选才适合你

所以，到底该不该迁移？

说实话，这事没有标准答案。

如果你更需要一个省心的方案：

• 还在早期阶段，跑得越快越好
• 团队人少，一人身兼多职
• 基础设施需求比较常规
• 开发体验和迭代速度比省那点钱更重要

如果你愿意接受更复杂的玩法：

• 团队里有专职DevOps
• 基础设施有特殊需求
• 成本优化是核心KPI
• 团队对基础设施即代码和分布式系统调试都不发怵

说在最后

换平台这件事，从来都不像"快速入门指南"写的那么简单。离开Heroku的真正成本，不只是迁移那点功夫，而是你要一直权衡的那个选择题：省心还是自主？托管服务还是亲力亲为？

跳之前，先对自己诚实一点，想清楚你到底在放弃什么。省钱是好事，但要是让你的团队减速了，或者引入了比省下来的钱还贵的运维复杂度，那就本末倒置了。

说到底，最好的主机平台就是那个能让你专心做产品的。能让你少操心基础设施的。有时候是那个贵一点但啥都帮你弄好的，有时候是那个便宜灵活但得自己多出力的。

认清自己，认清团队，再做选择。

你迁移过程中有什么故事？留言聊聊呗——很想知道大家在这波PaaS大迁移里都怎么样了。