总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 51CTO技术栈 「千山」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

Ruby on Rails 之父David Heinemeier Hansson（以下简称“DHH”）向来立场鲜明，言辞激进，其发言屡屡引起争议。

日前，DHH发布的一篇题为《我们的云退出已经节省了100万美元/年》的文章，再次点燃了技术论坛上的一把火。

当“上云”变成坑，不如果断“下云”

今年6月，DHH就高调宣布“我们已经离开云了”。

这里的“我们”指的是Basecamp团队。

Basecamp是37signals公司旗下的一款基于云服务的项目管理软件，上云已有十多年之久。而Basecamp在2020年推出的电子邮箱服务HEY也一直在云端运行。作为Basecamp & HEY 的联合创始人，DHH在去年十月发布了“下云”宣言。

作为资深云用户，Basecamp尝试过亚马逊云、谷歌云，使用过裸虚拟机、Kubernetes，称得上体验过云的大部分功能。但他们最终得出的结论是：

“对于像我们这样增长稳定的中型公司来说，租用IT基础设施大致上是一笔糟糕的交易。在降低复杂性等方面的承诺从未实现。所以我们计划离开。”

不过DHH并未全盘否定云的作用。在他看来，有两种情况，云是更适宜的选择。

其一，当你的应用程序非常简单且流量很低时，可以使用完全托管的服务来减少复杂性。其二，当你的负载波动非常不规律时，谁都无法预判到底是需要10台服务器还是100台服务器的情况下，上云就是更好的选择。

但对Basecamp来说，这两种情况都不适用。在DHH看来，如果继续坚持在云端运行，不但不能发挥云服务的优势，而且还要为某些微小的可能性付出近乎荒谬的溢价。

“就像你明明没有住在地震带的附近，但你花了近四分之一的房价去买了抗震保险。”正如DHH的描述，为某些可能性去花费大的代价，固然不能全盘否定，但总体上还是得不偿失、浪费资源。

以电子邮件服务HEY为例。DHH提到，他们每年为此向亚马逊的数据库(RDS)和搜索(ES）服务支付50多万美元。“你知道在每年50万美元的预算下，可以买多少台超级强大的服务器吗？”

此外，对于某些认为“云能简化运维，更节省人力”的说法，DHH也直接否定了。

“任何认为在云端运行像HEY或Basecamp这样的大型服务很‘简单’的人，都是纸上谈兵。总的来说，我还没有听说过像我们这样规模的组织，仅仅因为迁移到云端，就能实质性地大幅缩减运维团队。”

每月的云支出：从18万美元下降到8万美元

具体到执行云退出策略时，总有人说：上云容易下云难。

但在DHH的表述中，这句话对于Basecamp似乎也不适用。

“因为我们花了好几年才进入云端，所以我原本以为，我们也要花好几年才能出来。但是，所有将我们的应用程序容器化并为云做准备的工作实际上使退出变得相对容易。经过六个月的努力，它完成了。”

从云中退出只是策略，能看到实际支出的下降才能证明策略的有效性。在今年6月官宣正式回归本地后，云退出后的效果也逐渐展露。

“我们的云支出(sans-S3)已经下降了60%。从每月18万美元下降至不到8万美元。按年计算，这是整整100万美元的结余。另外，剩余的支出在今年余下的时间里逐渐减少之前，我们在9月份还会迎来另一个大幅下降。”

当然，为了回到本地，Basecamp不得不另外花费50万美元采购了新的服务器来取代云租赁。

DHH认为：“虽然额外的服务器会带来一些额外的成本，但在整体计划中，这些成本都是微不足道的(例如，运维团队保持不变)。通过节余和支出的基本对比，还可以看到，我们在不到6个月的时间里，就可以用每个月省下来的钱来买大宗设备了。”

更重要的是，DHH并不认为Basecamp的案例是个例。如今，云退出后实际产生的效果似乎也印证了他早前的警告——

首先，在企业生命周期的早期，云计算对企业来说是有一席之地的，这样的花费要么微不足道，要么24个月后它们将不复存在的风险很高。

然后，要小心，不要把那些奢侈的云积分当成礼物。这往往是一个钩子，如果你过多地将自己与他们的专有托管服务或无服务器产品捆绑在一起，一旦账单开始飙升，你将很难逃脱。

再者，有些公司的负载波动很大，这种情况下云租赁是有意义的。但如果一年中，你只有三天要用到犁，那么把它放在谷仓的363天就是没有意义的。

最后，大多数老牌公司应该考虑一下所谓上云热潮。哪些是实际起效的，哪些是营销夸大的。因为实践中，云计算可能并不如你预期的那样可以削减复杂性，而且溢价有时也很严重。

当我们考虑云时，我们到底在考虑什么？

关于DHH主张的云退出策略，有人支持，也有人反感。

Reddit论坛上，有技术人员认为，云的最大优势是其实不在于节省成本，而在于以下四点：

1、灵活性。如果采用云服务，就不可能出现“我们刚刚订购了大量昂贵的服务器，然后才意识到我们的应用程序无法在它们上面运行”。

2、责任下放。如果备份不起作用，那么你可以起诉云提供商。“在我的公司，托管数据库占所有云成本的一半以上，但没有人质疑这一点，因为我们意识到自托管的风险。”

3、易于使用。每个云提供商都为不同的用例提供了许多解决方案，并且所有这些系统都相互集成。这样可以节省大量时间。

4、安全和保障。许多公司陷入了困境，因为他们的机房被毁、被淹或遭到其他什么意外。使用云服务时，这种可能性要小得多。

也有人认为，上云还是下云，有时并不是单纯的技术架构的问题。

“我还没看到有人提过使用云架构的明显问题，但它与使用其他服务的问题相同。服务提供商可以在‘锁定’足够多的人之后提高价格。这意味着从非云过渡到云，可能会带来短期成本的下降，以季度或年度为单位看收益的人也许会觉得不错，但长期来看，一切都可能搞砸。”

还有人觉得，如果公司对于自身定位，还有长远发展没有明晰的认知，那么对于云的选择也将暧昧不清。

“我想大多数人都知道，这通常是一种成本效益分析，你需要更少的人来构建云基础设施，有能力在很少的交付时间内大规模扩展，并获得许多可以以低成本试用的功能。对于使用特定技术的可预测的工作负载来说，使用本地是更好的，而且更便宜。但关键在于，许多公司不知道他们想要什么，也不知道X年后他们会是什么样子。”

放眼当下，云计算发展至今，关于上云益处的声音被广泛传播，但事实上，云环境并不一定是运行所有应用程序的最佳场所。当云托管不符合预期时，考虑云退出也是一种选择。但是否真的要实施云退出，对于下云的复杂性是否有准备，以及什么样的云策略才是真正符合企业长期发展利益的，都需要审慎考量。

文章目录