北京
我喜欢掌控自己的基础设施，但不想事必躬亲地管理每一块拼图。
这种心态最终促使我开始把目光投向 Fly.io 之外的选项。Fly.io 给开发者提供了一种让应用靠近终端用户运行的强大能力，可一旦你需要的不仅仅是一个简单的服务，部署过程就得开始琢磨机器节点、地理区域、容器、网络配置、数据库、弹性伸缩，最后还有账单问题。到某个节点上，基础设施本身就会变成另一份全职工作。
对于我当时正在开发的应用来说，我并不需要更多的基础设施控制权。我需要的是更少的基础设施体力活。我的诉求很清楚：把 Git 仓库连上去，把整套应用部署起来，然后把绝大部分时间花在打磨产品而不是纠结底层基础设施怎么跑上。
于是，我挑了七家平台做个横向对比：Kuberns、Railway、Render、DigitalOcean App Platform、Heroku、Vercel 还有 Netlify。我也确实做了更详细的 Fly.io 替代方案比较，试图搞清楚这些平台在部署流程、自动化程度、定价机制和基础设施管理层面的根本差异。不过这一次，我更想从开发者的视角出发，只问一个最简单的问题：如果我手里有一个正儿八经的 Git 仓库放着现成的应用，哪个平台能在最少的不必要基础设施折腾中，帮我把代码推到生产环境？
我没有拿个静态网站或者另写一套 hello-world 玩具项目来糊弄自己。我选了一套相当常规的全栈应用需求作为比较基准——前端、后端 API、一个 PostgreSQL 数据库、环境变量、一个后台任务处理器、一个带 SSL 的自定义域名，以及每当我把改动推送至 Git 时自动触发部署的能力。没有哪一条特别冷门，但所有的零件凑齐之后，部署一个应用和管理它的基础设施这两件事之间的差异就变得极为刺眼。我的目标就是看每个平台要把整套应用顺利跑起来，我得费多少力气——要不要逐一创建服务、需不需要亲手写 Dockerfile、得配多少基础设施参数、要为弹性伸缩操多大心，以及在一切上线之后，还有多少运维的尾巴甩不掉。这个标准，就成了七家平台之间的那把尺。
Kuberns 是第一家让我感觉部署流程本身在替我打工，而非仅仅让手动配置变得更顺滑的平台。它的起步方式很简单，我连上 Git 仓库之后，它内置的智能代理就开始分析应用架构，自动识别出需要跑起来的关键组件。我不必手工创建每一个服务，也不用围绕它们逐一配置基础设施，大部分过程直接被自动化接管了。对于我当时需要部署的那种全栈应用来说，这种体验的打法完全不同——以往那些需要我根据项目结构自己判断并手动拼装的环节，这一回基本被抽走了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
