# 半年下云省千万，DHH下云FAQ LLMS 索引： [llms.txt](/llms.txt) --- 一年前我们宣布了[下云的计划](https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0)，随后披露了[2022年320万美元的云账单细节](https://dev.37signals.com/our-cloud-spend-in-2022/)，并决定不依赖[昂贵的企业级服务](https://world.hey.com/dhh/the-only-thing-worse-than-cloud-pricing-is-the-enterprisey-alternatives-854e98f3)而是自行构建工具来下云，使命已定！ 一个月后，我们下单购买了 **60万美元** 的戴尔服务器来实现这个目标，并保守估计[未来五年将给我们省下700万美元](https://world.hey.com/dhh/we-stand-to-save-7m-over-five-years-from-our-cloud-exit-53996caa)。我们还详细描述了[推动我们下云的五大核心价值观](https://world.hey.com/dhh/five-values-guiding-our-cloud-exit-638add47) —— 不仅仅是成本，还有独立性、以及忠于互联网初心等等。 在二月份，我们引入了 [Kamal](https://world.hey.com/dhh/introducing-kamal-9330a267)，这是我们花了几周自力更生打造的下云工具，它能在帮助我们从云上下来的同时，又不失去云计算中那些关于容器与运维原则上的创新点。 紧接着，我们所需的所有硬件[已经运抵](https://world.hey.com/dhh/the-hardware-we-need-for-our-cloud-exit-has-arrived-99d66966)两个不同地理区域的数据中心，总共是 4000个vCPU、7680GB 的内存和 384TB 的 NVMe 存储！ 到了6月，全部搞定。[我们成功地下云了！](https://world.hey.com/dhh/we-have-left-the-cloud-251760fb) 如果说这段下云旅途是“充满争议”的，那算是比较温和的说法 —— 有数百万人通过 LinkedIn、X/Twitter 以及此邮件列表阅读了更新。我收到了数千条评论，要求澄清、提供反馈，并对我们选择不同道路的“胆大妄为”感到难以置信 —— **在别人忙着上云还八字没有一撇时，就把下云的一捺给画完了**。 ------------- 但我们还是用结果来说话：我们不仅迅速完成了下云，而且客户[几乎没有任何感知](https://37status.com/uptime)。很快，省下的开销就开始滚雪球，到了九月，我们的云账单已经[省下了一百万美元](https://world.hey.com/dhh/our-cloud-exit-has-already-yielded-1m-year-in-savings-db358dea)。随着预付费实例逐渐到期（那种要提前整租一年以换取折扣的实例），账单开始进一步坍缩： ![](cloud-exit-faq.png) 时至今日，下云已经告一段落，但是各种问题开始纷至沓来：为了避免一次又一次地回答重复的问题，我想编制一份经典的“常见问题”请单（FAQ），以下是FAQ的内容： ------------- ***在硬件上省下的成本，会不会被更大规模的团队薪资抵消掉？*** 不会，因为我们在下云后，团队组成并没有发生变化。曾经在云上运维 [HEY](https://hey.com/)、[Basecamp](https://basecamp.com/) 的人，和现在在我们自己的硬件上运维这些应用的都是同一拨人。 这是云上营销的核心欺诈：所有的事情都非常简单，你几乎不需要任何人手来运维。我从来没见过这种事成真，无论是在 [37signals](https://37signals.com/)，还是其他运维大型互联网应用的公司。云有一些优势，但通常不在减少运维人员上。 ------------- ***为什么你选择下云，而不是优化云账单呢？*** 我们在2022年的云账单是320万美元，而之前的账单是现在的两倍还要多。现在的云账单已经经过仔细审查、讨价还价、深度优化了 —— 通过长时间的重复榨取工作，我们已经把这里的油水给彻底挤干了。 这件事部分回答了：为什么我非常看好中型及以上软件公司下云这件事。许多和我们有着相同客户规模的业务，每月的云开销很容易达到我们优化前账单的 2～4 倍。因此降本增效的潜力只高不低。 ------------- ***你的有没有试过用“云原生”应用的方式上云？*** 云原生，通常与 “Lift and Shift” 对照，被吹捧为充分利用云上优点的正道坦途，但这不过是又一坨云营销废话。云原生基本以一个错误的信念作为核心 —— 即 Serverless函数以及各种按需使用的工具能让用户节约成本。但如果你需要一斤糖，独立包装的单块小方糖并不会更省钱。我在《[不要被Serverless耍了](https://world.hey.com/dhh/don-t-be-fooled-by-serverless-776cd730)》以及《[即使是亚马逊也整不明白微服务Serverless](https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580)》这两篇文章中写过这一点。 ------------- ***那么安全性呢？你不担心被黑客攻击吗？*** 在互联网上运营软件时面临的大多数安全问题，都源自应用及其直接的依赖组件。无论你是从云供应商那里租电脑来跑应用，还是自己拥有这些服务器，确保安全所需的工作并没有本质区别。 如果说有的话，那么在云上运维服务可能会给人们一种错误的安全感 —— 以为安全并不是他们应该操心的问题 —— 而事实绝非如此！ 现代容器化应用交付的一个显著优势是，你不再需要花费大量时间手动给机器打补丁了。大部分工作都包含在 Dockerfile 中，你可以在最新的 Ubuntu 或其他操作系统上部署运行最新的应用程序版本 —— 无论你是在云上租用机器还是管理自己的机器，这个过程都是一样的。 ------------- ***不需要一支世界级超级工程师团队来干这些吗？*** 我从来都是毫不避讳地炫耀夸赞我们在 37signals 的优秀团队，我衷心地为我们组建的团队感到骄傲。但声称自己运维硬件是因为他们拥有一些特殊的魔法洞察力，那是在是太过于傲慢了。 互联网发展始于 1995 年，而云成为默认选项最早不会超过2015年。所以在超过二十年的时间里，公司们都在自己运维硬件来跑应用。这并不是什么已经失传的古代知识 —— 我们确实不知道金字塔到底是如何建造的，但对于如何将一台 Linux 机器连接到互联网，我们还是门儿清的。 此外，在自有硬件上运营所需的专业知识，和在云上靠租赁运营所需的专业知识，有90%是相同的。至少在我们这种数百万用户，每月几十万美元账单的规模时是这样的。 ------------- ***这是否意味着你们在建造自己的数据中心？*** 除了谷歌、微软和Meta等少数几家巨无霸公司，没人会自建数据中心。其他人都只是在专业数据中心（例如Equinix）那里租用几个机柜、一个机房或者一整层楼。 所以，拥有你自己的硬件，并不意味着你要去操心安全、电力供应、灭火系统，以及其他各种设施与细节 —— 这些设施的建设投入可能要耗资数亿美元。 ------------- ***谁来做码放服务器、拔插网络电缆这些活呢？*** 我们使用一家名为 [Deft](https://deft.com/) 的白手套数据中心代维服务商。还有无数类似的公司。你付费给他们，让他们把戴尔或其他公司的服务器拆箱，直接放入数据中心，然后将服务器上架，你就能看到新的 IP 地址蹦出来，就像云一样，只不过它不是即时的。 我们的运维团队基本上从未踏足这些数据中心。他们在全球各地远程工作。与互联网早期每个人都自己拉线缆的时候相比，现在这种运营体验才更称得上是“云”。 ------------- ***那么可靠性呢？难道云不是为你做到了这些吗？*** 当我们在云上运营时，使用了两个地理分隔的区域，也在每个区域内实现了大量的冗余。当我们下云后，也干了一模一样的事情。我们在两个地理分隔的数据中心托管自己的硬件，每个数据中心都能承载我们所需的全部负载，而且每个关键基础设施都有副本。 可靠性在很大程度上取决于冗余，你应该能随时失去任何一台计算机、任何一个组件，而不会造成问题。我们在云上拥有这种能力，而现在使用自己的硬件时也一样。 ------------- ***那国际化业务的性能呢？云不是更快吗？*** 我们先前的云部署使用了两个不同区域，都在美国国内，也用了一个在全球各地都拥有本地边缘节点的CDN网络。与可靠性上的问题一样：我们在下云后也是使用两个美国区数据中心，并使用国际CDN来加速内容交付。 从根本上说，云上云下的挑战是一样的。国际足迹的难点通常不在于配置硬件与确保数据中心安全上，而是你的应用程序需要处理多个主数据库写入，应对复制延迟，以及其他各种让应用在全球网络上高速运行所需的有趣工作。 我们目前正在欧洲为 HEY 规划一个数据中心前哨站，我们把这些配置的活儿留给了 Deft 的朋友们。正如所有硬件采购一样，它的交付速度确实要比云慢。对于 “我想在日本上线10台服务器，并在30秒后看到它” 这种事来说，没有谁能比得上云，这确实很了不起。 但对我们这类业务来说，为这种即时拉起的弹性能力支付疯狂的巨额溢价根本不值得。等几周才能看到服务器上线，对我们来说是一个完全可以接受的利弊权衡。 ------------- ***你有考虑到以后更换服务器的成本吗？*** 是的，我们的数学计算是基于服务器可以正常使用五年的工作假设。这是相当保守的，我们有服务器跑了七八年仍然表现很好。但大多数人还是会用五年作为时间范围，因为财务摊销计算上会更方便。 这里的关键点是：我们花了60万美元购买了大量新服务器。而下云节省的费用已经让这项投资已经回本了！所以如果明年出现了一些惊人的技术突破，我们又想再买一堆新东西，我们也毫无压力，在成本优势上依旧遥遥领先。 ------------- ***那么隐私法规和GDPR呢？*** 云在隐私合规和GDPR上并没有提供任何真正优势。如果说有，反而是有负面影响，因为所有主要的超大规模云服务商都是美国的。所以，如果你在欧洲，并且从微软、亚马逊或谷歌等公司购买云服务，你必须面对这个现实：美国政府可以合法强迫这些供应商交出数据和记录。我在《[美国数据间谍永远不会关心服务器到底在哪里](https://world.hey.com/dhh/american-data-spies-will-never-care-where-the-servers-are-371d4016)》一文中详细说明过这一点。 作为一家在欧洲运营的公司，如果严格遵守GDPR对你很重要，那么你最好还是拥有自己的硬件，并放在欧洲的数据中心供应商那里运行。 ------------- ***那么需求激增时怎么办？自动伸缩呢？*** 在自己采购硬件时最令我们震惊的是，我们终于意识到了现代硬件到底有多么强大与便宜。仅仅过去四五年中的进步就已经非常巨大了，这也是云变成一门糟糕生意，一年不如一年的一个重要原因。在摩尔定律的指数规律下，用户能从戴尔和其他厂商买到的产品价格不断下降，能力不断增强。但摩尔定律对对亚马逊和其他公司的云托管服务价格几乎没有任何影响。 这也就是说，你可以买得起极为夸张的超配硬件，让你有在面对尖峰时游刃有余，却几乎不会对长期预算有任何影响。 不过，如果你确实经常面临超出基线需求 5～10倍或更高的峰值，那你也许是潜在的云客户。毕竟，这也是 AWS 最初诞生的动机。亚马逊在“黑色星期五”或“双十一”所需的性能远远远远超过他们一年中其他时间，所以灵活弹性的硬件对他们是有意义的。 但你也可以用混合搭配的方式来做这件事。俗话说，“买基线，租尖峰”。绝大多数公司根本不需要操心这种事，只需要关注使用情况，根据增长曲线提前采购一些强力服务器就够了。如果确实需要计划外的扩容，一周时间就足够拉起一整个新的服务器舰队了。 ------------- ***你在服务合同和授权许可费上花费了多少？*** 啥也没有。在互联网上运行应用所需的一切，通常都以开源的形式提供。我们所有的东西都是之前云服务的开源版本。我们的 RDS 数据库变成了 MySQL 8。我们的 OpenSearch 变成了开源的 ElasticSearch。 有些公司确实可能喜欢服务合同带来的舒适感，市场上有很多供应商可以提供这类服务。我们会不定期使用来自Percona 的 MySQL 专家的优秀服务。而这不会对底层逻辑有什么根本性改变。 你确实应当尽可能远离那些高度“企业化”的服务机构，通常来说，如果他们的客户名单上有银行或者政府，你就应该去别处看看，除非你确实喜欢烧钱。 ------------- ***如果云这么贵，你们为什么会选择它？*** 因为我们相信了云营销画的大饼：更便宜、更简单、更快。对我们来说，只有最后一个承诺真正实现了。在云上，你确实可以很快地拉起一大堆服务器，但这并不是我们会经常做的事，所以不值得为此付出巨大的溢价。 我们花了几年的时间试图解锁“规模经济”与“简单易用”这两个云技能点，但从没实现过。托管服务仍然需要管理，而摩尔定律带来的硬件进步很少能透过云厂商这一层来节约“我们”的成本。 事后看来，在云上跑一把其实还是挺不错的：我们学到了很多东西，也改进了自己的工作流程。但我确实希望能够提早几年就把这个账给算清楚。 ------------- ***我还有其他问题想问你！*** 请给我发邮件： [dhh@hey.com](mailto:dhh@hey.com)，对于大家普遍感兴趣的问题，我会在这里更新。 > 本文翻译自DHH原文：[The Big Cloud Exit FAQ](https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010)