← #791

我正在搭建一朵云

查看原文 HN 讨论

文章摘要

David Crawshaw（前 Tailscale 工程师，现 exe.dev 创始人）在这篇文章中宣告自己正在构建一朵全新的云，并系统性地阐述了他对当下主流云服务的不满与重构理由。他认为，随着 AI 智能体（agent）即将生成海量软件，市场对优质云基础设施的需求将远超想象，而现有的 AWS、GCP、Azure 等大厂却建立在一套已经过时、设计有缺陷的基础之上。

文章首先批判了云厂商的虚拟机售卖模式：用户被迫购买 CPU 与内存绑定的固定套餐，而理想形态应该是按裸资源购买，再由用户自行在共享硬件上灵活配置 VM 密度。其次是存储设计的代际错位——传统云磁盘是为机械硬盘时代设计的（10ms 随机寻道延迟），但 SSD 时代下，云盘的网络往返反而把 SSD 应有的性能（数十万 IOPS）降到几千 IOPS。作者举例：一台 MacBook 本地 NVMe 就能跑出 50 万 IOPS，而昂贵的云配置反而吃力。第三是网络出网（egress）费用：作者称这是机房直接租机柜成本的 10 倍，等于人为设置了一道经济壁垒，限制了用户能负担得起构建什么样的产品。

Crawshaw 反对在有缺陷的底层之上不断堆砌抽象层（如 Kubernetes），而是选择从零重建。exe.dev 的设计哲学包括：CPU/内存按需独立配置；本地 NVMe 存储 + 异步复制保障数据安全；全球 region 配合 anycast 网络；TLS 与认证代理一体化集成。他在文末略带浪漫地写道：”我喜欢计算机”，喜欢让它们正常工作。在 AI 智能体时代来临之际，他相信值得有人重新思考整个云的形态。

HN 评论精华

• 关于 Kubernetes 的争论占据了讨论主线：有评论犀利地称”让 Kubernetes 变好本质上不可能，那是给猪涂高级口红”。但也有反驳声音，一位三人小团队的工程师表示”K8s 一点都不难，我们每周花在它上面的时间几乎为零，写个脚本生成 YAML 扔进 CI，基本就是 fire-and-forget”。

• K8s 的合理使用场景：有 LLM 推理初创公司的工程师分享，他们做的就是不断到处找 GPU，”K8s 提供的标准 API 让接入新供应商只要几分钟，所有东西就能 Just Work”。这正是”面向标准 API 编程”的完美用例。但反对者指出，对于”只跑几个容器的 Web 应用”上 K8s 就是杀鸡用牛刀。

• 企业现实主义视角：一位评论者道破天机——平台团队往往只能负担支持 1-2 种部署方式，K8s 通用性强，所以即使你只有一个小服务也得走 K8s。否则你要自己搞定 service account、密钥、防火墙、流水线、注册表，没人会给你这些权限，PM 也不接受这种开销。

• 更替代品的讨论：评论中提到了 Dokploy、Coolify、Dokku 等轻量替代方案，对家用服务器或小型部署而言比 K8s 更适合。

• 对云厂商销售逻辑的批判：有人尖锐指出”管理层往往比信任自己员工更信任大厂的销售和市场部门”。还有评论延伸：”科技行业靠技术债维系自身，就像实体经济靠真实债务维系——大家都在互相 gaslight 对方，让对方背上尽可能多的技术债，这样债务服务就能被卖出去。”

• 对 exe.dev 路线的好奇：有人提问 exe.dev 究竟会在底座之上构建什么，还是把容器、日志这些都留给用户自己定制？这是讨论中悬而未决的有趣问题。