高达 320 万美元一年的云计算费用，这家公司选择“下云”后，CTO 粗略算了一下，每年至少能节省一百五十万美元。即使预留 50 万美元用于意外开支，5 年也能节省 700 万美元的费用。

整理 | 梦依丹 出品 | CSDN（ID：CSDNnews） 近日，37Signals 联合创始人&CTO David Heinemeier Hansson (下文简称 David，其还是 Ruby on Rails 框架创始人) 兴奋地表示：本以为“下云”会像进入云端那样，需要花费多年时间，没想到在经历六个月的努力后，最后一个应用已成功迁回到本地硬件之上。

对此，也有不少人咨询 David 是如何做到的？有人直言，除了钱之外，在发生自然灾害时，如何保证可用性？并且是否意味着数据中心需要遍布世界各地，或者依然在云上维护关键备份。

为什么要“下云”

2022 年 10 月 19 日，David 宣布 37Signals 旗下两个主要产品 Basecamp 和 HEY 正式“下云”。Basecamp 是非常火的一款 Web 端项目管理和团队协作平台，用户群来自五大洲 166 个国家的大大小小的企业，超 75,000 个组织在使用，已在云上运行十多年。而全功能电子邮件服务 HEY 自 3 年前推出，就一直跑在云端。

在决定“下云”之前，他们广泛地使用了 Amazon 和 Google 的云服务，并且在裸机虚拟机，Kubernetes 容器上做过尝试，也体验了云计算所提供的一些服务。但在诸多尝试之后，他们得出结论，对于像他们这样具有稳定增长的中型企业来说，租用计算机在大多数情况下是一个不划算的选择。运营商所承诺的通过降低复杂性，减少运营支出之类的费用节省也从未实现。

37Signals 已经经营了 20 多年，这是一家中型企业，拥有约 80 多名员工和 10 人左右的运营团队，以及超过十万的客户。很多情况下，他们都会有一个可预测的基础负载，并不会有剧烈的波动。与此同时，公司内部在运行服务器方面具备相当多的能力和经验。他们用户量最大的应用程序 Basecamp 只有搜索 (OpenSearch)、文件存储 (S3) 和 CDN 服务 (CloudFront) 是放在云端，其它绝大部分包括 Basecamp 2 几乎完全跑在自己的服务器上，包括应用程序、数据库和缓存服务器。

因此，团队成员对本地部署和云上都比较熟悉，能够客观地看待在哪些场景下，使用何种部署。所以他们才着手制定了离开计划。

6 个月迁移成功

本次迁移最大的挑战是 HEY 应用程序，这是完全基于云端并从未在自己硬件上运行过的全功能电子邮件服务。HEY 使用的 AWS 云服务包括通过 EKS 在 Kubernetes 集群上运行完整的 Rails 应用程序、使用 Aurora RDS 在 MySQL 数据库服务器上运行、通过 Elasticache 在 Redis 上运行以及通过 OpenSearch 进行搜索。此外，还有一些其它的旧版应用程序也在 EKS 上运行，并使用 RDS 作为数据库。

为此，团队采用分阶段迁移法，在几周内独立地移动不同数据库、缓存服务器、邮件服务和应用实例，最终成功地完成了此次迁移。

在过去的六个月中，他们还将六项遗产服务带回了本地。这些服务已不再对外销售，但只对现有客户和用户提供支持，直至互联网终结的六项产品，它们分别是：Basecamp Classic、Highrise、Writeboard、Campfire、Backpack 和 Ta-da 列表都已经超过十年历史了，但仍然为数以万计的人提供服务，并创造了数百万美元的收入。

接下来，Basecamp 团队将花费更少的资金来运营它们。因为设备的更新换代，还给客户带来更快更好的用户体验。

后边，David 团队成员会使用一些开源技术堆栈来管理这些应用程序：

• KVM 将新型 192 线程 Dell R7625s 切片成隔离虚拟机；

• Docker 运行容器化应用程序；

• MRSK 使用 Manage Remote Server Kontainers 进行零停机时间应用部署和回滚操作，这些设置避免了 Kubernetes 的复杂性，并避免了企业服务上的合同纠葛。

在整个迁移过程中，运营团队规模并没发生改变，在云端运行的应用程序并没有提供承诺中所述的生产力增益来缩小团队规模。

主要区别在于需要新服务器和看到它们在线上之间存在的延迟时间。虽然在云端可以几分钟就启动 100 台强大的计算机，但也必须付出高昂的成本来享受此特权。而他们并没有哪些业务需要享受这种云上高级服务，因此他们所节省下来的费用完全可以承受极度超额配置的服务器需求，即使需要更多的时候，也只需要几周即可搞定。

DHH 列举了他们采购硬件的花费及相关配置：花费约 50 万美元从 Dell 购买了两批服务器，并将其组合为 4,000 个虚拟 CPU、7,680 GB 的 RAM 和 384TB 的 NVMe 存储容量。

上面的服务器配置完全可以运行他们的遗产服务和 HEY 应用程序，并刷新其他 Basecamp 操作所需的硬件。而且，这还不到每年节省成本的三分之一，还是他们在五年内所摊销的硬件。

年费高达 320 万美元的云成本

在 David 宣布“下云”操作后，不少公司来咨询 David 当前的账单情况以及节省的成本是否可以支撑“下云”这个决定。

为此，David 在博客上公布了他们在云上的具体支出。

2022 年，他们在所有云服务上总共花费了 3,201,564 美元。相当于每月 266,797 美元。

对于 HEY 应用来说，生产工作负载的年度费用为 1,066,150 美元（88,846 美元/月）。该服务分为以下几个大部分：

就单服务而言，他们在 2022 年为所有应用程序数据库的 RDS 花费了 473,196 美元（每月 39,433 美元）。这些费用里面不包括 Basecamp 和 Basecamp 2。因此，其中大部分是花在 HEY 应用上的，该服务占据了全年总额的 355,950 美元（或每月 29,662 美元），其余则用于其他旧版服务。

用来托管应用程序搜索集群和索引存储日志管道的 OpenSearch，在 2022 年花费了 519,959 美元（每月 43,330 美元）。这是 Basecamp 和 Basecamp 2 使用的云服务之一，大笔开支分别分布在 HEY 和 Basecamp Classic 上。

2022 年在亚马逊 Kubernetes 服务 EC2 和 EKS 总共花费了 759,983 美元（每月 63,331 美元）。其中绝大部分用于 HEY 的生产和暂存环境，总计 272,359 美元（每月 22,696 美元），其余用于其他遗留应用程序。值得注意的是，这些支出都与当前的 Basecamp 或 Basecamp 2 无关。

对于 Elasticache 部分，2022 年花费了 123,852 美元（每月 10,321 美元）。其中最大部分再次由 HEY 所占据，通过使用该服务来获取基于 Redis 的缓存。

最后，在 S3 存储的 8 PB 文件上花费了 907,838 美元（每月 75,653 美元）的费用。值得一提的是，这个设置采用了双区域复制策略，目的是可以抵御整个 AWS 区域消失的风险，包括所有可用区。为了服务这些文件和其他静态资源，他们在 2022 年还花费了 66,742 美元（每月 5,562 美元）购买 CloudFront CDN 服务。

这就是他们 2022 年在云上所花费的巨额支出。David 表示，等到一年结束时，他还会继续对比云上和建立本地物理数据中心的费用对比，从而看看“下云”方案所节省下的成本。

那么，“云”还能上吗？

David 还表示，云计算只在两种情况下会比较出色，一是当您的应用程序非常简单且流量较低时，通过使用完全托管的服务确实可以降低复杂性。Heroku 就是这样起步的，并且 Render 等公司验证了可行性。当你还没有客户时，或者开始有一些客户时，云服务托管可以算是一个绝佳的选择。

第二种情况是当负载非常不规则或者较大时。当您的使用量出现剧烈波动或高峰时，基线只占最大需求的一小部分，或者您不知道需要十台服务器还是一百台服务器时。在这种情况下，没有什么比上云更好的选择了。提到这里，David 以 HEY 为例，团队起初计划是 6 个月内有 3 万名用户，而实际却在 3 周内涌进了 30 万名体验用户。HEY 从一出生就运行在云端，所以才避免了流量剧烈波动所带来的的不良体验。

David 认为，云对于那些处于生命周期早期、支出微不足道或者存在 24 个月内可能无法继续经营的公司来说是有用的。但要当心，不要把那些慷慨的云服务赠品看成礼物，这是一个陷阱。如果你过多地依赖他们专有的托管服务或无服务器方案，一旦账单开始飙升，你会发现很难逃脱。

对于一个企业来说，每笔费用的支出都很重要。David 提醒大家：“可以考虑一下你是否拥有一个真正受益于不断扩大和缩小容量的服务，然后认真评估自己的云计算退出可能会是什么样子。我们在六个月内从云上取出了七个应用程序，你也可以做到这一点。工具都在那里，而且是免费的。所以不要只因为炒作而留在云端。”

参考链接：

https://basecamp.com/

https://world.hey.com/dhh/we-have-left-the-cloud-251760fb

https://37signals.com/podcast/leaving-the-cloud/

https://dev.37signals.com/our-cloud-spend-in-2022/

转自 CSDN