本文要點
· 公有云領域正在蓬勃發展。首先，云解決方案迎來更多的競爭和機遇。其次，數據監管和安全控制正成為新的挑戰。
· 你需要清晰的數據監管策略來驅動工程實踐，以免阻礙業務的發展。
· 利益相關者的參與對你的成功至關重要，需要讓他們接受你的策略，并了解風險和義務。
· 你無法預測未來的需求，所以要提供足夠的靈活性便于后續的擴展。
· 使用自動化，包括硬件部署的自動化。給供應商施加壓力，讓他們參與進來。
在2017年云基礎設施即服務Gartner魔力象限中，Amazon Web Services無疑是當之無愧的領跑者。盡管如此，AWS仍然不足以成為事實上的云服務解決方案。最近，AWS的部分用戶因為與Amazon零售業務存在競爭關系，宣布要停止使用AWS.Walmart構建了自己的私有云，并要求它的技術供應商撤出AWS，轉而尋求與Google和Microsoft合作。主流的云供應商紛紛加入Cloud Native Computing Foundation（CNCF），推動行業朝著基于容器的跨云微服務架構發展。VMware停止與四個主要的公有云供應商合作（Amazon、Microsoft、IBM、Google），Microsoft啟動了Azure Stack——輕量版的Azure.業界出現了另一個非常重要的趨勢，數據隱私和安全的區域合規性（中國、俄羅斯、歐洲）正嶄露頭角，比如即將于2018年5月開始實行的歐洲通用數據保護條例（GDPR）。業務部門需要重新定義他們的云策略，擁抱混合云解決方案，并加入更嚴格的數據監管，這意味著需要向私有云邁出一大步。
云基礎設施即服務Gartner魔力象限圖：
下列是在構建私有云解決方案時需要考慮的五個方面。
1.愿景和戰略規劃
很多私有云因無法發揮應有的作用而以失敗告終。與工程項目一樣，錯誤的期望值和不現實的目標會導致糟糕的結果，但實際上本不該如此。在了解了所要解決的問題之后，必須定義出清晰的目標和需求。比如，了解開發者的痛點，看看私有云將如何解決或緩解他們的問題。改進開發者體驗，確保方案能夠得到快速的實施，并取得長久的成功。
構建私有云需要專注，需要堅持不懈的毅力，需要強烈的動機，需要責任心和有效的溝通，需要進行所有權總成本分析，以便了解當前的服務成本。私有基礎設施的日常運維是怎樣的？需要為利益相關者定義拒付模型嗎？如果有必要，那么有成功的先例嗎？計劃運行哪些類型的工作負載？如何簡化容量規劃？最小的預算和最大的預算分別是多少？你的解決方案能夠與現有的CI/CD管道和開發者工作流順暢地集成在一起嗎？你為你的工程團隊準備好容器化的環境了嗎？又或者你需要計劃在混合云環境中使用容器嗎？如果需要重新設計組件，那么就需要考慮這么做的成本。你的部署流程需要作出變更，為你的工程團隊提供順暢、積極正向的體驗。你要定義好上層的SLA，并以KPI的方式監控它們。在定義好策略之后，下一步就是制定戰術和計劃。
要記住一句話，計劃得太多，反而不利于事情的進展。不過如果沒有急切的目標，也就沒有了動力。所以，需要在功能目標和現實技術之間做出權衡。
案例
#1 Adobe的云廣告平臺通過TubeMogul構建了自己的混合云解決方案。那么他們的愿景是什么？通過完全自動化的自有基礎設施賦予利益相關者處理核心負載的能力，解決低延遲和大規模存儲問題。他們的策略又是什么？通過簡單的CI/CD工作流在裸機和虛擬實例上實現性能和配置的靈活性。戰術呢？使用開源的OpenStack進行基礎設施的編排和自動化。組建一支精益的團隊開發和維護私有云，為開發者提供統一的CI/CD工作流。
#2 在考慮使用私有云方案時，我們直接向我們的公有云提供商AWS提出了質疑。我們對所使用的技術進行總體成本分析，疑問重重。在頭三年的時間里，我們時刻準備著我們的私有云計劃。在相當長一段時間內，我們的私有云計劃成為與公有云提供商商談價格的籌碼（BATNA「1」）。
2.設計的靈活性
在確定了你要交付的服務類型和運營模型之后，要在設計中保持足夠的靈活性。研發階段的投入是不可或缺的，你將需要進行多次迭代，并留有余地以便應對不可預測的情況。在進行技術選型時總會引發激烈的爭論，然后是確定網絡和服務器的規格。有句話叫“如果你要為大牲畜構建農場，就不要把它建成寵物的小窩”。在私有云架構里，你所選擇的技術需要用上好多年，你要成為它們的擁護者，為此打造一個社區，支持它們，并讓脾氣暴虐的架構師們知道它的好處。做好升級計劃，比如如何從v1升級到v2.保持技術更新是支持新需求、跟隨新趨勢、留住人才的關鍵因素。
先交付一個可以帶來關鍵商業價值的最小價值產品（MVP），后續再進行改進。盡可能利用裸機基礎設施，而不僅僅是把私有云當成一個“IT項目”。不要試圖在內部構建另一個公有云，那是不可能成功的。你的方案要具備足夠的靈活性，為開發人員提供有價值的支持。你要提供新的方案、API、服務，為工程利益相關者帶來順暢的體驗。確保你的私有云服務遵循現有的標準，加快開發人員采用私有云的速度，并可以在多個云環境上重用功能。你可能還需要設計SDN并開發出一些服務層，當然，這些要視你的實際情況而定。
保持學習曲線的平滑和敏捷是非常重要的。從簡單的開始，標準化開發者的工作流，用好VLAN，部署核心服務（身份識別管理、網絡、計算能力、存儲），定義好清晰的升級路徑。
案例
#1 在TubeMogul，我們通過反復試錯來進行技術選型或選擇供應商。這當中有些技術可能已經不存在（CloudStack、Eucalyptus等）了，最后我們選擇了OpenStack，并結合使用了裸機。我們最初的設計傾向于使用便宜但強大的日常硬件，結合簡單的網絡，并設計好故障應對措施。我們只用了OpenStack的核心服務，以及Jenkins的基本CI/CD工作流和用于配置裸機的PXE.開發人員也使用了相同的CI/CD管道來管理跨云的canary和生產應用程序部署。多個環境之間需要具有標準的命名約定，我們才能重用現有的工具和服務。
3. 基礎設施自動化
私有云部署很關鍵的一點是如何處理數據中心、網絡和采購問題。這里涉及到資產管理和售后，它們很容易成為痛點，并給部署造成麻煩。所以，要想清楚你擅長做什么以及不擅長做什么。根據你的投資目標和團隊結構的不同，你可能會承擔很多壓力，所以不要讓那些供應商閑著。我時常提醒我的團隊，VAR指的是“Value Added Reseller”，所以不要忘了增值部分。根據參與度模型的不同，你可能需要定義好機架排布、線纜布局、端口映射、電力拉線等等。在極端情況下，你可能要使用以機架為單位的模型（rack-at-a-time）代替以服務器為單位的模型（server-at-a-time），直接將裝備好的機架搬進數據中心。你只需要將機架接近核心網絡就可以了，不需要自己組裝和拉線。
在進行硬件自動化時，要確保你的設計適用于你的數據中心。你希望你的設計是Top-Of-Rack「2」式的嗎？或許你對TIA 942-A不甚了解，那么就讓供應商提供想法并進行設計評審。這有可能會影響到硬件的選擇和冷卻通道的位置。這里有許多細節需要考慮。確保你考慮到了數據中心的空間位置和電力供應，知道如何利用現場人員處理售后問題。這些都是成功構建一個私有云的關鍵因素。
案例
#1 Adobe廣告云平臺數據中心的最小化部署單位為兩個機架。所有機架都由供應商搭建，然后進行自動化的鏡像和組件部署。我們使用了Puppet進行配置管理，如果有一個資源處于空閑狀態，或者經過售后之后需要進行重新部署，只需要標記一下狀態，然后重新觸發構建即可。
4. 自己搞定
你需要對自己構建的東西進行反復的測試，需要一個真實的實驗室承擔測試工作。你要感受到痛點，并把它們解決掉。
在跨過一系列坑之后，你要為利益相關者提供可見的數據，讓他們了解整個流程。要敢于把整個私有云的狀態和風險點展示出來。你是否做好了計算資源的容量規劃？利益相關者是否了解網絡的局限以及這將給他們的使用帶來的影響？如何提供網絡的可見性以便建立良好的信任和信心？是否存在過載的計算資源和超額認購？在進行迭代和增長時，這些問題都是需要解決的。
案例
#1 TubeMogul的第一個OpenStack開發環境在一開始很成功，直到一個禮拜之后Ceph出現了問題，導致整個環境都崩潰了。這個環境是一個共享的環境，既是私有云的測試環境，也是開發環境。所以，我們得到了教訓，就是不要將開發環境和利益相關者的環境混在一起。如果有人依賴你的服務，你就要承擔起交付高質量服務的責任。
#2 做好容量規劃是很難的，你希望了解你的業務，但又不希望業務的增長僅依賴你。知道什么時候提前增加容量至關重要。我們以兩個機架作為部署單位，如果一個地方的資源不夠用了，我們就增加兩個機架。這個時候，設計的靈活性就發揮了它的作用，我們因此可以快速地擴展私有云。
結論
這是一個旅程。構建私有云不是件小事，而大部分公司未必需要私有云。如果有可能，就使用公有云吧。但如果要構建私有云，你需要搞清楚目標是什么。數據監管和業務決策將把你帶向不同的方向。私有云并不是一個簡單的工程項目，而是一個戰略決策。了解大方向，取得利益相關者的支持，做好敏捷計劃，以便進行迭代。Adobe廣告云平臺經歷了多個階段，這些階段都要求堅實的軟件和運營工程來自動化基礎設施?，F在，我們交付了一個核心的基礎設施，可以降低資源占用和延遲，處理更多的流量，甚至提供三倍于AWS原生網絡的性能。
京公網安備 11010502049343號