在我去年 12 月聊天的 47 家企業(yè)中，猜猜有多少不是混合云的用戶。零。 

猜猜有多少人曾經(jīng)使用過另一種云模型。零。 

猜猜有多少人相信他們會“將一切都轉(zhuǎn)移到云端”。零。 

好吧，我知道你可能沒有經(jīng)常或根本沒有讀過這類東西，但我認為它證明了混合云的重要性以及我們對它的了解是多么的少。這很糟糕，因為當一些關(guān)鍵問題很難被理解時，這總是一件壞事，但對于希望再次參與其公司 IT 規(guī)劃流程的網(wǎng)絡專業(yè)人員來說，這可能是一件好事。

我們關(guān)于網(wǎng)絡專業(yè)參與應用程序規(guī)劃的論文很簡單。開發(fā)人員了解功能和托管要求。IT 運營人員了解托管和成本管理。網(wǎng)絡專業(yè)人士所了解的是將所有這些綁定到體驗中的工作流程。通過將規(guī)劃討論的重點放在工作流上，網(wǎng)絡專業(yè)人員為企業(yè)創(chuàng)造了深遠的價值，這在混合云中表現(xiàn)得最為明顯。

如果你畫出混合云應用程序的結(jié)構(gòu)，將用戶放在左邊，你首先畫一個雙向箭頭指向一個標有“云”的圓圈，然后從那個圓圈到另一個標有“云”的圓圈（在右邊） “數(shù)據(jù)中心”。這是混合云應用程序的總體布局。用戶（可能是員工、合作伙伴或客戶/潛在客戶）通過精心設計的 GUI 與云進行交互。應用程序的云部分將這種交互轉(zhuǎn)化為交易，然后進入數(shù)據(jù)中心。那里的某些東西（應用程序、數(shù)據(jù)庫）會生成結(jié)果，然后通過云 GUI 將結(jié)果返回給用戶。

不要沉迷于網(wǎng)絡——在這里思考；請記住，目標是考慮交互創(chuàng)建的工作流程。應用程序設計和組件化是工作流和交互的奴隸。您要在設計會議上提出的第一點是，最好、最具成本效益的設計將是限制從用戶到云或從云到數(shù)據(jù)中心的來回交互的設計。這是圖中需要首先解決的兩點。

第 1 步：最小化用戶到云的流量。

用戶到云的交互會成倍增加成本、使網(wǎng)絡連接復雜化并降低體驗質(zhì)量 (QoE)。在不影響 QoE 的情況下保持盡可能低的交互次數(shù)是一個起點，但真正的挑戰(zhàn)是在不冒大量成本超支風險的情況下最大化云優(yōu)勢。

云的價值在于它能夠在負載下擴展并快速更換故障組件，這通常是可擴展性的一個屬性。對于連接用戶并處理這些工作流的應用程序組件，可擴展性通常最為重要。如果你想要可擴展性，你可能需要某種形式的負載平衡來分工，但你也需要考慮狀態(tài)的問題。

狀態(tài)是開發(fā)人員所說的“您在多步對話中的位置”。用戶幾乎總是會與云進行多步交互，因此了解正確處理消息所處的步驟至關(guān)重要。許多開發(fā)人員會自動想到通過在專用于該步驟的單獨的小型組件（微服務）中處理每個對話步驟來實現(xiàn)這一點。這將成倍增加組件的數(shù)量，并隨之增加云網(wǎng)絡的成本和復雜性。另一種方法是狀態(tài)控制，其中用戶的應用程序或云數(shù)據(jù)庫維護對話狀態(tài)。這意味著單個微服務可以處理多個步驟，也許是整個對話，并且多個用戶可以共享每個微服務的實例。所有這些都將減少微服務和連接的數(shù)量，從而降低成本和延遲。

就此問題展開討論的最佳方式是要求開發(fā)人員繪制工作流在云中的連接方式。此過程將快速發(fā)現(xiàn)微服務和連接數(shù)量的問題，并提出如何優(yōu)化應用程序設計以解決這兩個問題的問題。開發(fā)人員通常會很快看到問題并了解如何修復它。他們會記得是誰首先指出的！

第 2 步：優(yōu)化 MPLS 和 SD-WAN 的使用。

現(xiàn)在看看數(shù)據(jù)中心方面。云和數(shù)據(jù)中心的關(guān)系有很多選擇，其中大部分都是不好的。例如，讓云組件“讀取”托管在數(shù)據(jù)中心的數(shù)據(jù)庫會產(chǎn)生大量流量，您需要為此付費，大量的每次訪問延遲會使您的 QoE 大打折扣. 相反，您希望向數(shù)據(jù)中心發(fā)送一條消息，要求進行所有需要的數(shù)據(jù)庫工作和處理，并讓它只發(fā)回結(jié)果。

大多數(shù)混合應用程序首先使用數(shù)據(jù)中心進行“查詢”以查找特定記錄或一組記錄（如符合用戶興趣的產(chǎn)品），然后進行“更新”以更改其中一條記錄的狀態(tài)（如一項采購）。云數(shù)據(jù)庫的一個重要用途是在用戶瀏覽選項時保留查詢結(jié)果，這樣就無需繼續(xù)返回數(shù)據(jù)中心獲取另一條記錄。這樣做會招致云提供商的流量費用，將網(wǎng)絡連接加載到云，并增加累積延遲。進行更新時，會將更改發(fā)送到數(shù)據(jù)中心。

數(shù)據(jù)中心工作流程中出現(xiàn)的一個問題是公司VPN的作用。企業(yè)都依賴MPLS VPN，有時由SD-WAN VPN 增強甚至取代?？梢酝ㄟ^ VPN 或直接從 Internet 連接到數(shù)據(jù)中心。在前一種情況下，可以將 VPN 擴展到云（產(chǎn)生額外成本），或者將云流量丟棄在一個或多個遠程站點位置，然后再拖回數(shù)據(jù)中心。這通常是有多個云托管地理區(qū)域的選項。始終可以通過規(guī)劃工作流程并探索每個選項的成本及其對延遲的貢獻來確定最佳答案。

第 3 步：磨練可擴展性和組件化。

最后一步是定義將連接用戶交互和數(shù)據(jù)中心交互的云工作流，這是注意“過度可擴展性”和“過度組件化”的重要地方。數(shù)據(jù)中心中的數(shù)據(jù)庫通常具有特定的最大事務率和特定的可擴展性限制。大多數(shù)設計良好的混合云應用程序在用戶端具有高度可擴展性，而在向數(shù)據(jù)中心連接移動時可擴展性較差。您可以通過查看連接用戶的云組件和連接數(shù)據(jù)中心的云組件之間的工作流來識別過度的可擴展性。

工作流鞏固了網(wǎng)絡專業(yè)人員在應用程序規(guī)劃中的作用，因為工作流鞏固了每個應用程序的各個方面。每個工作流程都是企業(yè)預算到云提供商、軟硬件供應商和網(wǎng)絡提供商的現(xiàn)金流。每個工作流都會增加延遲、增加復雜性、增加開發(fā)和維護時間和成本。在互聯(lián)網(wǎng)和云中，連接是隱性的，這導致 IT 專業(yè)人員忽略工作流及其后果，因為它們“只是工作”。由于網(wǎng)絡連接承載工作流，因此它們將網(wǎng)絡和網(wǎng)絡專業(yè)人員與應用程序、云、信息技術(shù)以及最重要的正式 IT 規(guī)劃聯(lián)系起來。抓住一堆工作流程，準備就座。