企业应如何解决云成本优化悖论？

最近一篇题为“云的成本，万亿美元悖论”的分析备受关注。这篇文章挑战了围绕云转型和云迁移狂热的传统思维，它要求我们思考云基础设施成本的影响(以及这反过来对公司估值的影响)。

也有观点指出，对于 SaaS 公司来说，云计算的成本会拖累他们的市值。

这个悖论表明，在公司发展的早期，云计算成本更低，随着公司规模的扩大，它变得更加昂贵。他们说得很简单：“如果你不从云开始，你就疯了，如果你坚持下去，你同样疯了。”

矛盾的是，云基础设施使企业的业务模型在更小的规模上成为可能，但它会转化为大规模价值破坏的来源，只有在企业深深致力于云计算之后才会显现出来。

遣返——将工作负载从纯云模型带回私有或混合基础架构——可以作为优化基础架构成本的主要策略。例如，一家价值 10 亿美元的私有软件公司，其公共云支出消耗了公司 81% 的收入成本 (COR)。在最大的 50 家上市软件公司中，云计算总费用超过 80 亿美元(其中包括显示云支出的费用)。

奇怪的是，云遣返并没有比现在更受欢迎。遣返可以大大减少云支出，一个经常被引用的数字是节省 50%。为说明这一点而采用这一方法，在部分例子中，遣返将节省 40 亿美元的回收利润。考虑使用公共云基础设施的大规模软件公司的广阔领域，我们很快就会发现这 40 亿美元的未实现利润可能要高得多。

企业需要如何克服万亿美元的悖论的有用的建议，包括将云支出作为 KPI、激励工程师优化资源消耗、选择资源密集型工作负载的一个子集作为起点，以及在惯性和锁定之前考虑遣返会剥夺您遣返的选择。

基础设施成本的增长并不总是与收入增长成正比。随着公司规模的扩大，这可能导致盈利能力下降。

根据更深入的研究，云支出可以对市值产生 25 倍的影响。通过这一点，人们很快就会发现，我们可以估计额外 40 亿美元的毛利润会增加1000亿美元的市值。

监控服务提供商Datadog是一家上市公司，最近其交易价格接近 2021 年估计毛利润的 40 倍，并在其 S-1 中披露了对Amazon Web Services的三年承诺总额为 2.25 亿美元。

让我们将承诺的支出按年度 AWS 成本计算为 7500 万美元，并进一步假设其中 50% 或 3750 万美元可以通过云遣返来收回。这意味着，仅是削减支出这一项，该公司的市值就增加了大约 15 亿美元。

如果我们扩展到更广泛的企业软件和消费者互联网公司，假设总云支出的 50% 由规模庞大的技术公司消费的，这些公司将从云计算遣返中受益。

考虑一下这个效率可能对公司估值产生影响的例子。MongoDB和 Elastic 报告的2021财年年收入几乎相同(分别为 5.9 亿美元和 6.08 亿美元)。为什么 MongoDB 的市值几乎是 Elastic 的两倍(分别为 234 亿美元和 136 亿美元)?其中一个原因可能是 Mongo 在基础设施使用效率方面的差异，Mongo 为其 SaaS 产品使用细粒度多租户，而 Elastic 则为每个租户使用单独的集群，资源消耗的差异是巨大的。

通过将服务与基础架构分离，我们可以创建预定义的基础架构区域，这些区域经过高度优化，可以服务于每个工作负载。

这里可能的不同之处在于 SaaS 模型的强大功能。“市场对云收入的估值大约是本地开源的三倍，其原因主要在于净收入留存率，”他观察到。本地开源基础设施的流失率往往很高(通常为 18%)。

还有一个示例是Atlassian，该示例将其服务转移到 AWS 中的多租户云模型中，从而将成本降低了三倍。然而，这并不是因为 AWS 更便宜。而是因为重新架构的多租户模型使服务更加轻量级。

1. 专注于服务，而不是基础设施

这里要做的工作是优化云支出。因此，我们需要思考云优化的务实术语。优化很难，为了取得成功，我们需要停止考虑功能开发速度与效率之间的关系。相反，我们应该将效率视为另一个一等公民特性，需要在我们的积压工作中优先考虑，并像其他功能一样获得管理关注。

2. 用自动化解决问题会使事情变得更糟

虽然正确完成自动化可以显著降低成本，但是，自动化的副作用常常是，它使开发人员可以轻松启动云资源并让它们运行，即使在不需要它们时也是如此。这也有可能导致公司云成本的上升。

• 自动化没有魔法：许多公司试图通过自动化人工流程来提高利润。这在技术上可能具有挑战性，并且增长的驱动力使得优先排序变得困难。
• 未优化的云：私有市场推动增长，因此云实施的效率可能会低几个数量级。

有许多将他们的单体应用程序迁移到 Kubernetes 的公司，并且在那个阶段他们体验到了效率的提高。然而，很快，他们的云基础设施成本开始飙升。开发人员开始启动实例不一定是出于正确的原因：他们这样做只是因为它更容易。

3. 掌控自身工作负载

在自动化方面，往往过于强调基础设施自动化，而几乎不关注服务本身的自动化。而服务层比基础设施层有更多的优化空间。

4. 将工作负载与基础架构选择分离

为了在服务层实现优化，我们需要能够将服务与基础设施的选择分离。通过这种方式，我们可以为工作选择合适的基础架构或云计算提供更大的灵活性，并且随着我们的成长，我们还为未来的增量优化留出了足够的空间。

5. Kubernetes、Terraform 和 Ansible 还不够

Kubernetes、Terraform 和 Ansible 都是很棒的工具。它们有助于抽象和简化基础架构管理。但这还不够：

• 管理基础设施和基础设施之上的服务是两件不同的事情。当您考虑第二天的操作(例如连续更新)时尤其如此。
• 管理分布式服务、多 Kubernetes 集群、多数据中心或多云仍然相当复杂，这些工具提供的帮助有限。
• 当企业有大量模板和脚本来管理其基础架构而没有任何东西将所有这些映射回服务时，很容易迷失方向。
• 重新控制我们的服务：在 IaC 和 Kubernetes 之外向上移动堆栈。

克服这些问题并重新控制我们自己的应用程序的最大潜力是向上移动，思考我们如何管理我们的服务，而不仅仅是运行这些服务的基础设施。

通过将服务与基础设施分离，我们可以创建预定义的基础设施区域，这些区域经过高度优化，可以服务于每个工作负载(测试、生产、ML、网络等)。

这些优化区域不必位于云之外，因为即使在同一个云中也有足够的优化空间——显然在云之间也是如此。在这种情况下，离开云成为那些优化基础设施区域的另一个案例。可以将其称为环境即服务(EaaS)。

以下示例说明了如何将这些想法映射到实际示例中。在这种情况下，我们将看到如何在两个不同的基础架构堆栈上运行相同的工作负载：一个针对生产进行了优化，另一个针对开发进行了优化。这个想法同样可以应用于其他领域。

6. 完成云成本优化仍有希望

对于成功的软件公司来说，“万亿美元的悖论”不一定是破坏价值的陷阱。通过进一步关注堆栈并将服务匹配到正确的基础架构选择、激励优化行为、深思熟虑地自动化(而不是反射性地)以及在达到规模之前制定遣返策略 ，可以更好地控制成本并保留价值。

云迁移、自动化和成本优化的周期是持续的过程，需要不断迭代、克服失败并从失败中学习，最重要的是团队合作。

有许多工具可以帮助企业实现这一目标，但归根结底，如果没有正确的纪律和合作伙伴，他们可能会反对企业决策。正如历史学家Yuval Noah Harari所说：“刀可以用来切蔬菜和制作美味的食物，但也可以用来杀人：这完全取决于你如何使用它。”

首先，我们需要重新设定期望以解决悖论。我们必须开始进一步思考堆栈，进一步提升价值链，关注服务本身而不是基础设施，看看我们如何将正确的基础设施与服务相匹配，而不是反过来。