#10 Heroku 后继者们

随着 Heroku 没落，越来越多的 PaaS 后继者出来，比如 Fly、Render、DigitalOcean App Platform、Railway。

我粗略研究了每个平台功能和使用文档，新平台的体验其实都挺好，git push 后自动构建镜像并发布，继承了 Heroku 的精髓。俞军老师曾经提过一个衡量产品价值的公式——产品价值 =（新体验-旧体验）- 迁移成本。平台价值还得考虑迁移成本。从这个维度看，我更喜欢 Render 和 DO App Platform，因为迁移上云的心智负担较小。通常服务端应用包括 server、worker、job 几类不同类型服务。server 暴露 http/grpc 接口提供对外服务，worker 处理异步任务，job 执行一次性任务。Render 有 blueprint spec，DO App Platform 有 app spec，都是按照这个思路设计的规范，对后端开发者而言会比较熟悉亲切。

而 Fly 和 Railway 则走另外的路线，Fly 推崇应用全球化设计，让应用运行在更靠近用户的边缘节点，数据库支持多地区读写分离。我也很认同这个理念，全球化肯定是趋势，只是其中存在一些取舍，比如是否服务上云就必须多区域部署？能否通过 cloudflare argo 等类似路由优化方案降低用户请求到源服务器时延？再看 Railway，出来的较晚，可能 Dashboard 的交互设计比较 fancy，使用体验上更好点，还没发现其他亮点（没有黑的意思）。

除了产品发展路线外，功能差异不是很关键，后期大家肯定会趋同补全，无非是拼性价比和稳定性。希望有一天这些 PaaS 新贵们能成长为云时代的新巨头，避免 Heroku 的命运。

最后祝大家周末愉快！

好文品读

HashiConf Europe 2022 我的走马观花 — 大家上云都很担心 vendor lockin 这件事，在 IaC 领域同样如此，用户选择 Terraform 不是因为具体的工具，而是认同这种基础设施的交互方式。这也构成了 HashiCorp 的护城河。

The Beauty of Unix Pipelines (2020) — 通过几个常见的场景展示 Unix 管道的威力。我是挺喜欢 Unix 的设计哲学。

谈谈这两年在业务中做技术的思考 — 赞同作者的观点。“业务系统技术同学的价值体现在：1. 业务域80%通用问题的技术抽象识别；2. 根据抽象识别选择合适的底座或必要时候能打造适合业务状态的轮子；3. 支撑业务是基线，加速业务达成，扩大业务基本面价值是生命线。对于技术同学来说，要时刻思考：抽离掉技术底座和业务后，你的价值是否归零。”

如何进行技术面试（面试官视角） — 明确哪些是加分项，哪些是底线。我一直认为面试是双向选择，文章是从面试官视角给了些注意事项，从面试者角度看也要考察面试官是否符合自己的期望。

我的一年独立开发经历 — 一次非常好的创业经历，有值得借鉴的地方。

产品和工具

fresh — 发布了 1.0 稳定版，感兴趣的可以看看，反正我学不动了。

Nook Calendar — 又一个做日历和会议安排的产品。

Improve Git monorepo performance with a file system monitor — 针对 Monorepo 做了优化，增加了 file system monitor 异步缓存计算。

Collection of texts that are commonly used around the web — 有时候想不到词，抄抄别人的也不错，缺点是容易泛滥乏味。

我的 Logseq 使用习惯 — 从这篇文章里学到了新的小技巧，推荐给喜欢 logseq 的朋友。