如今企業上雲已經成為不可逆的潮流，但是對於雲運營，特別是如何更經濟高效地使用雲和遷移到雲等方面仍有疑慮，以下將會對相關內容進行討論。
雲與內部部署
之前經常看到公共雲計算比內部部署貴很多的言論。如果不加約束，並且只考慮計算和儲存的裝置和基本費用，則確實會得出這個結論。
注意事項
在進行公平的雲與內部部署比較時，需要考慮許多因素，例如：
- 眾多服務/維護合同談判等
- 所有支援基礎設施的成本（交換機、路由器、佈線、支援軟體等）
- 業務時間成本——例如需要等待多長時間將該LUN 新增到伺服器中？
- 資料中心開銷（包括電力、網路冗餘等）
- 業務連續性/彈性開銷（備用資料中心等）
- 企業對 IT 資源的實際利用率 — 企業為擁有備用可用性的計算支付了多少費用？
- 能夠快速響應不斷變化的業務和 IT 需求
當以上因素綜合起來，你可能會得出不同的結論。從本質上講，這意味著企業必須在裝置的使用壽命內分攤計算的全部成本（包括上述因素）。即使內部部署的成本略低，但這也許並不值得，因為執行資料中心並非核心業務。
在進行比較評估時，還應與財務團隊合作，檢視實際的內部部署相關支出。
單體工作負載
一個巨大的挑戰是較舊的單體工作負載，它們的構建通常很少考慮計算成本與利用率。此類工作負載旨在 24x7 全天候執行，並且在需要時閒置。
一些應用程式將利用負載平衡器在可用伺服器之間分配工作負載，並確保整體可用性。這樣做主要是為了確保即使單個或兩個伺服器出現故障或離線進行維護，適用的服務仍然可用。
在應用程式空閒期間，很少會出於其他目的重新部署計算核心。這當然可以完成，但需要付出大量努力來管理計算的重新分配。而且在非工作時間不需要進行大量計算，硬體將會處於閒置狀態。
混合雲
有些情況下，確實應該使用內部部署。麥當勞西班牙的 CIO 指出，他們的每家商店都需要有自己的本地計算，以便商店即使在網際網路中斷的情況下也能運營。
本地 IT 基礎設施將用於自動化管理、物聯網資料的捕獲等。在這些情況下，擁有（適當大小的）本地足跡通常是有意義的。然而，聚合資料並執行其他功能的後端服務可以基於雲。
S&P Global 和 Dow Jones 等指數公司需要執行計算密集型的模擬，通常需要數千個核心——但僅限於短時間爆發。如果他們執行輪換模擬計劃，他們可能能夠在每 24 小時內保持其內部部署計算基礎設施的大量使用，因此證明在內部執行是合理的。
但大多數企業的計算需求都有高峰和低谷，在空閒期間幾乎沒有什麼可做的，因此支付空閒的計算時間並不是一個明智的選擇。
遷移到雲
企業如何在合理管理成本的同時遷移到雲？在資料中心遷移過程中，企業通常會同時為兩種服務付費。這也適用於雲。
退出資料中心業務
執行資料中心若非公司的核心業務，則企業需將管理和運營開銷都由雲服務提供商負責。另一個好處在於，企業可以輕鬆部署和管理相關服務。
自助服務支援
在管理內部部署的 IT 基礎設施中，配置佔了顯著成本。提供虛擬機器和連線儲存通常需要專業知識。
到目前為止，雲的最大優勢是即時配置。只需點選幾下，不到幾分鐘，企業就可以部署新的計算和其他服務，無需等待提供裝置。並且，如果該部署不是企業所需要的，可以快速地將其刪除，企業只需在部署該資源時為其付費。
提升和轉移
遷移到雲的第一種方法是“提升和轉移”，即現有的應用程式簡單地按原樣遷移到雲中。如果盲目執行，額外的成本可能比較巨大。但是，如果透過技術來節省成本，同樣可以將成本控制在合理範圍內。
雲支援企業的應用程式
理想情況下，企業可以重新編寫應用程式工作負載以巧妙地利用雲，新應用程式應該從一開始就啟用雲，只使用所需的雲功能。當然，開發需要一些時間，所以這應該是企業長期計劃的一部分。
雲成本節約技術
有許多技術可以降低雲成本。雲的一般經驗法則是計算昂貴而儲存便宜。因此，理想情況下，企業應該只使用所需的最少量的計算和儲存。下面有一些最常見的策略可供操作。
標記企業資源
理想情況下，企業的所有云部署都應進行標記，以識別相關的成本中心、專案或類似內容，以便進行適當的交叉收費。它還可以幫助企業確定誰“擁有”某些資源。
例如AWS 帳戶和 Azure 訂閱可以應該用於隔離不同的業務領域並提高安全性。Azure 提供了“資源組”，用於對共享相同生命週期的專案（即與特定應用程式部署相關聯的所有資源）進行分組。
整理儲存空間
企業應確保自身有一個良好的資料保留計劃，它會丟棄不再需要的資料。這不僅是一種良好的做法，會降低儲存成本，而且在越來越多的情況下，這也是一項法規遵從性要求。
可以做一些簡單的事情，例如識別和刪除重複資料；整合資料來源；清除舊的日誌檔案；歸檔未使用的資料（但可能仍需要保留一段時間）等等。
企業還應確定工作負載在一週或一個月內的計算、記憶體和儲存利用率。通常，企業的平均計算利用率為 2% 到 4%，中間會有一些突發。這些爆發很可能發生在工作（或購物）時間。
企業可能正在內部部署的24 核記憶體豐富的伺服器上執行應用程式。但利用率不足，也許 8 個核心和一半的記憶體就足夠使用。即使對於本地系統，這也是一個很好的做法。
如果企業的工作負載可以使用負載均衡器在多個計算例項上執行，則只需編寫少量指令碼，無需重寫現有應用程式，即可監控應用程式的利用率並動態啟動和停止其他例項，甚至根據需要調整例項大小。如果出現意外爆發的高峰時間，指令碼可以解決這個問題。如果應用程式有計數器和 API 來監控其執行狀況和使用情況，效果更佳。
如果企業移動了諸如 MS-SQL 之類的資料庫工作負載，也可以動態地動態調整它的大小，以便在非工作時間的計量費率低於高峰時間。
另一種技術是讓不再使用的 VM 自行關閉。在這樣做時，使用雲 API 非常重要，這樣 VM 才能正確釋放，而不是簡單地處於“關閉”狀態，仍然在充電。這種方法可能需要一個補充指令碼來在需求增加時啟動額外的 VM。
這些是不需要重新編寫應用程式的直接遷移工作負載的最佳技術。
預留例項
預留例項允許以顯著降低的成本留出專用計算，但這與承諾特定時期（1 到 3 年）相關。它不是特定的 VM 例項，但通常是特定的 VM 大小或系列。使用該大小內的 VM 將首先按降低的預留例項費率收費，直至承諾，屆時費用將恢復為標準 VM 合同費率。
Microsoft Azure 傾向於更靈活地保留例項承諾，允許企業定期移動和調整它們的大小，甚至將成本應用於同一系列中的其他 VM。Amazon AWS 在這方面更嚴格，但企業可以支付更多費用以獲得更大的靈活性。
這裡的一個關鍵點：不要一次預訂所有預留的例項！如果決定為某些工作負載遷移到預留例項，請按滾動方式進行……每季度甚至每月一次。
原因是企業所有續訂不會同時發生。企業的需求處在不斷變化過程中。如果有滾動的預留例項續訂，則可以更輕鬆地管理和調整大小。
Spot 例項
Spot 例項提供了另一種低成本的計算選項。但同時需要做出權衡。Spot 例項可以透過雲提供商的通知終止。如果企業的工作負載可以處理這個問題（並且在 2 分鐘內關閉或休眠），這可能是一個很好的成本節約策略。
定價模型有點像拍賣，企業對 VM 大小“出價”，企業可能會也可能不會得到它，如果其他企業在計算資源有限時出價高於您，則可能會失去它。
如果需要，可以將 Spot 例項置於負載均衡器之後以管理工作負載可訪問性。指令碼可用於管理關閉，其中涉及單體應用程式。另一種策略是使用 Spot 例項進行橫向擴充套件，同時仍保持核心提交的例項。
有一些第三方工具可以非常有效地使用 Spot 例項管理工作負載。
計劃的虛擬機器
另一種簡單的技術是預定服務，其中某些服務在下班時間自動關閉。雖然吸引力有限，但它是一種可用的措施。
這可以與按需訪問相結合，如果有人需要它就可以啟動服務。
無伺服器
如果使用得當，可以使用無伺服器事件驅動計算，例如 Azure 函式和 AWS lambda。在大多數情況下，這些需要重寫應用程式，但可用於增強現有的單體應用程式。
孤立資源
雲計算中最常見的錯誤之一是未能完全刪除資源。例如，當建立虛擬機器時，將為其附加儲存和網路介面。但是，人們經常會刪除不再需要的 VM 時刪除關聯的儲存和網路介面。因此，企業往往會繼續為不需要的儲存和網路介面付費。
因此建議企業編寫指令碼來識別此類資源，以節省費用。
護欄
可以部署護欄，這可以限制個人部署資源的型別和大小的許可權，並強加某些安全配置要求。這為自助服務啟用提供了很好的平衡。
運營支出與資本支出
一個常見的會計挑戰是從資本支出過渡到運營支出模型。資本支出允許資源資本化和折舊，技術的期限通常為 3 年，而運營支出則在發生時承擔費用。各有各的會計優勢，轉型需要與財務進行密切配合。
但是，對於公共雲，可以透過適當的承諾對其進行資本化。預留例項是一種方法。如果企業需要保留部分資本支出模型，則需與相應的雲提供商討論。
多雲
許多公司正在採用多雲戰略。例如公司內部工作負載放在 Azure 上，面向客戶的工作負載放在 AWS 上，資料科學工作負載放在 GCP 上。MongoDB Atlas、Oracle 雲和 Snowflake 也正在成為流行的雲到雲和雲到本地服務。
在零售即付即用中，所有提供商的價格都在幾美分以內，因此需要根據工作量需求和其他標準進行選擇。
當然，公司還可以透過第三方平臺進行多雲平臺管理，以提高效率，節省成本，雲聯壹雲即是最佳選擇之一。
