原文連接：https://www.zdnet.com/article/the-myths-and-truths-about-multi-cloud/數據庫
多雲戰略應該包括什麼？鑑於跨多雲運行的運維複雜性，不少組織的多雲戰略主要內容是如何自由地選擇雲。安全
勿庸置疑，不少組織已經實施了多雲戰略。根據Flexera最新發布的2020年雲報告，93%的企業受訪者都表示，他們已經制定了多雲戰略。報告中有詳細說明。ZDNet的Dion Hinchcliffe在上週剛剛發佈了對Google Cloud戰略的評估，他指出，上雲戰略的核心就是多雲。在2020年對混合雲基礎架構平臺的評估中，咱們也指出，Google等雲廠商都在試圖在國外擴大雲足跡。微信
爲何有那麼多組織都正式或非正式地擁抱了多雲戰略呢？答案可能有不少種，但最多見的答案就是懼怕雲廠商的鎖定，這一點咱們稍後討論。由於據咱們觀察，最多見的緣由仍是懶惰。不少企業但願他們的科技產品系列一應俱全。常見的狀況是公司IT部門設定了標準，可是公司內幾乎沒人遵循這些標準。影子IT（Shadow IT）已經出現了不少年，最初是從部門下單購買我的電腦開始的——究其緣由是他們不想因IT部門的積壓工做和集中式採購而被耽誤太長時間。固然，有些組織是在併購以後成立的，而那些被收購進來的部門可能要等不少年才能擺脫老舊系統。網絡
所以，上雲也就不奇怪了，這是對組織擁有各類科技產品系列的最新展現。爲何上雲還會各不相同呢？很多企業的上雲之旅啓始於部門化的AppDev團隊，一般運行DevTest工做負載，比起購置專屬硬件，這種方式是較臨時性的。在iPhone AppStore推出以後，手機應用出現了Cambrian爆發式增加，iPhone AppStore通常是由產品市場團隊實施的，而不是公司級的團隊，自此，只可從雲中得到的SaaS和AutoML服務的採用率不斷提升，運行雲端數據的運維應用和分析工具也愈來愈受歡迎。架構
有時候，不一樣的應用偏好會影響到對雲的選擇，例如，Azure聯盟，其中包括具備新一代S/4HANA業務應用的SAP; 有Viya分析的SAS; 或者經過一個OEM協議的Databricks。還有就是已被Google認定爲開源數據庫項目中一級公民的開源數據庫。其它狀況下，可能出於性能或數據主權的緣由，若是某個雲廠商的某個區域離某國很近，或者就在該國內，數據也在該國內。不過，區別存在的時間會較短，由於全部的大型雲廠商都在擴大它們的全球雲足跡，但願覆蓋世界各地。app
在一些監管嚴格的領域，例如金融服務領域，可能會要求避免依靠某一個雲廠商，例如要求有第二家雲廠商來負責災難恢復。當前的經濟形勢並不穩定，但經歷了目前的疫情已清晰地代表，上雲已經呈加速之勢。在經濟動盪之時，大多數的企業會從新評估他們的核心產品及服務，並轉向數字化業務。這說明，對業務更多的關注減小了因維護正常運轉而被牽扯的精力，這時，雲順勢而來。這意味着要從新審視後臺系統是否會拒絕雲遷移，也意味着將發揮機器學習、客戶參與和分析等雲服務的優點，組織能夠利用它們建立新的業務線。框架
大多數時候，企業可能會在特定的雲中運行特定的系統。例如，在AWS中運行某些手機應用，並試圖從Google Cloud中尋求某些AI能力。也多是由業務單元驅動雲的定位。在另外一個場景中會如何呢？企業會跨多雲廠商運行一個應用或數據庫嗎？大多數時候，咱們是懷疑的。若是出現輸出成本（從雲中提取數據的成本）、網絡延遲、某雲廠商API，以及安全和管理的孤島等狀況，即便雲展示出簡化的統一控制平面這樣強大的力量也無濟於事。即便在刨除了輸出成本以後（咱們能夠想像多雲服務的廠商在這方面會發揮創造性），您仍要面對跨多雲運行所產生的安全性、管理和集成所產生的費用。運維
重要的是，跨多雲廠商運行一個數據庫的邏輯實例，就像跨多個數據庫運行一個事務應用程序的單一邏輯實例同樣。也不是不可能，可是否值得推薦呢？對於大多數堅持在一個雲中運行多個系統的企業來講，控制平面仍會出現這樣的變化，但至少，能夠逐個處理不一樣的雲，就如同您在企業中處理不一樣的數據庫平臺同樣。您沒必要同時運行它們，所以也避免了管理的複雜性。機器學習
但以後，就要面對Kubernetes (K8s)。它可否跨不一樣的雲廠商，使琢磨不定的控制平面得到統一性，從而不受廠商的影響，讓在雲端運行的一切都從視覺上和操做上變得同樣？Kubernetes (K8s)的魅力顯然是在於應用的移動性，而非數據庫。不過，數據庫能夠被裝進容器中，並/或者給運維人員提供驗證或聚集指標等輔助流程，這種流程是容器化的，以微服務的形式運行，能夠在Kubernetes (K8s)環境中編列。K8s還能夠協調API。分佈式
Kubernetes能夠賦能數據庫跨雲進行互操做，但它不能解決分離環境的管理和安全的複雜性問題。每個環境都有本身的受權和驗證，日誌、監控和指標，以及加密體制。是的，經過Kubernetes，安全性能夠是聲明式的，並且Kubernetes也跨雲提供互操做，可是它不必定可以協調基礎的控制平面，除非您混合並匹配運維人員。若是您但願跨多雲得到簡化的雲管理，那恐怕就必須選擇在第三方的工具或框架上分層。
爲何Google的多雲是友好的？Google將Anthos做爲戰略支柱正在大力推廣。除了Google Cloud以外，Anthos正在AWS中運行，以後還會在Azure中運行。Anthos從新打包了Google Kubernetes Engine (GKE)和某些構件，以支持集羣和多集羣管理、配置管理、服務網格、日誌及運行雲原生環境所必須的其它功能。這使您的應用和數據庫既可以在您本身的私有云中運行，也能做爲實例在對手的雲中運行。上週剛剛發佈了一些擴展功能，接受已有身份和訪問管理系統，使之更獨立於Google雲，它也是裸機的一個測試版，使Anthos的客戶可以離開VMware。
除了Google，市場中還有其它的廠商在競爭。IBM也在積極發展Red Hat OpenShift（Cloud Paks創建在此之上）的移動性，雖然尚未什麼發佈，但咱們能夠預測Microsoft將發佈Azure Arc，若是經過Kubernetes控制平面實施，將有相似的移動性。Confluent 6.0平臺引入了集羣鏈接，您能夠跨多數據中心、跨地理位置鏈接Kafka集羣，Confluent雲服務賦能您運維遍佈多雲的虛擬Kafka雲。
Google加大力度發展多雲，並於近期發佈了BigQuery Omni，今後，只要有Anthos運行的地方就能夠運行Google的數據倉庫，不管是在您本身的私有云和混合雲、在數據中心或者在邊緣、或者是在另外一個公有云上均可以。BigQuery Omni的核心理念就是數據在哪裏，就在哪裏運行，無需將數據再送回Google雲。但它也可能會讓您跨全部Anthos支持的雲來運行一個數據倉庫的聯合實施。Google的方式就是利用一個可操做的推測，把分析下移到數據所在的地方，只有結果集纔會被送回Google雲。
近期有分析指出，因爲將有更多的邊緣分析設備在混合雲運行，並將結果返回至在GCP上運行的中央實施，所以，有一位想添加Omni的BigQuery 客戶正在瞭解它。對於咱們來講，多雲的祕密在於期待它能夠看上去、運行起來都像一個邏輯實體。但實際上雲是平臺，即便有標準，它們也是不一樣的——這一點很像SQL數據庫。多雲其實是企業分散風險的方法。
在大量的用例組中，多雲不是要跨兩個以上的雲運行聯合數據庫或應用。相反，多雲戰略的核心是爲了得到選擇雲的自由——運行什麼以及在哪裏運行？老是會有一些獨角獸公開宣佈他們選擇了單一的戰略雲廠商（一般都是得到名人待遇的參考客戶），但咱們持保留意見。除非您的IT組織採用脫離現代網絡的技術，全部內容都在操做系統層之上自行開發，不然您將不得不在某些技術堆棧層上選擇關鍵路徑的廠商。最終，它將包含一個或多個雲。
近十年來，終端用戶的混合雲和多雲戰略都沒有太大變化。但Kubernetes已變得無處不在——GKE、EKS、OKE、AKS、DIY、Konvoy（D2iQ發行版），企業須要在現有的Kubernetes集羣上部署發行版並進行生產運營的管理，以實現進一步擴展。
隨着Kubernetes API的普及，也爲一成不變的混合和多雲管理方面提供了新的創新方向。藉助這一特性，D2iQ Kommander進一步擴展了對第三方集羣的管理，涵蓋了EKS、GKE、OKE和AKS等第三方Kubeterntes發行版，並在這些集羣上部署了更多Konvoy集羣。用戶能夠在Kommander中進行單一操做：經過一個管理平面，對異構的多Kubernetes集羣進行統一的集中化治理和生命週期管理，實時查看多集羣的健康情況、進行分佈式運維管理，並獲取Kubernetes企業級應用洞察。
歡迎參加9月10日下午2點：D2iQ Kubernetes Workshop——後雲原生時代的多Kubernetes集羣運維管理探討。掃描下方二維碼或點擊【閱讀原文】便可報名。
W O R K S H O P
內容大綱
如何實現Kubernetes快速部署、擴容、升級、備份等底層運維操做；
如何進行統一的權限管理；
如何從實際的項目層面進行統一的運維管理，包括多集羣資源分配；
如何管理應用商店；
如何進行統一的中央監控。
掃二維碼｜馬上報名
往期精彩文章
關於D2iQ
點擊「閱讀原文」，當即報名D2iQ Kubernetes Workshop
本文分享自微信公衆號 - D2iQ（d2iq_apac）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。