最近一篇題為“云的成本，萬億美元悖論”的分析備受關注。這篇文章挑戰了圍繞云轉型和云遷移狂熱的傳統思維，它要求我們思考云基礎設施成本的影響(以及這反過來對公司估值的影響)。

也有觀點指出，對于 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所說：“刀可以用來切蔬菜和制作美味的食物，但也可以用來殺人：這完全取決于你如何使用它。”

首先，我們需要重新設定期望以解決悖論。我們必須開始進一步思考堆棧，進一步提升價值鏈，關注服務本身而不是基礎設施，看看我們如何將正確的基礎設施與服務相匹配，而不是反過來。