什麼是多雲(Multi-Cloud)

本文中我們會介紹什麼是多雲(Multi-cloud)概念以及企業應該為什麼要使用這樣的策略。我們會聚焦在目前世界前三大公有雲服務(AWS, Azure, GCP)，之後我們會介紹地端的私有雲平台，像是Azure Stack, AWS Outposts, GCP Anthos與Vmware的公有雲整合方案．我們還將尋找使用多雲的效益是什麼，如何籌劃一個或多個使用這些雲端平台(以下簡稱CSP-Cloud Service Provider)的策略，以及多雲的第一起點應該是什麼。

我們將會有以下幾個重點：

• 理解多雲概念
• 多雲不只只有公有雲與私有雲
• 主要雲端運算技術的業者(雲端運算平台業者)
• 設立企業的多雲策略
• 收集多雲的需求
• 了解多雲在企業中的挑戰

多雲(Multi-Cloud)概念的理解

本文嘗試回答，在使用多雲的狀況下的幾個主要問題：

1. 企業各種不同的CSP上部署各種IT系統，怎麼進行控制？
2. 如何避免運作多雲環境的成本超出預算
3. 如何清楚地了解誰在管理系統
4. 以及最重要的是，IT系統在雲端上蔓延會帶來嚴重的資安風險

但在我們開始深入探討之前，我們需要就什麼事多雲和多雲概念有一樣的認知。

網路上有許多關於多雲的定義，但我們就只針對這一篇文章所下的定義來闡述：

多雲是指同時使用兩個或多個雲端運算平台。 可能使用公有雲、私有雲或兩者的某種組合。 多雲部署主要在硬體/軟體件故障的情況下提供冗餘(redundancy)並避免被vendor lock-in。

讓我們聚焦這個定義中的一些議題。 首先，我們需要了解大多數企業的IT系統來源：具有實體和虛擬系統的傳統資料中心，裡面託管各種功能和業務應用程式。 今天，雲端運算的使用者會把傳統資料中心會稱之為legacy。 但今天的cutting edge就是明天的lagacy。 因此，在本文中，當我們討論通常託管在地端機房的系統時，我們將會使用“傳統”IT。 有了這個，我們已經在我們剛剛為多雲給出的定義中引出了第一個問題。

許多企業將他們的虛擬化環境稱為私有雲，無論是co-locate還是放自己的公司內。但是許多企業只是把自己的虛擬化平台稱之為私有雲，大多數的他們無法達到ISO或NIST所定義的雲端平台條件。這些環境託管了企業的多個業務系統，這些業務系統在集中管理的平台上進行資源消耗。

當然，在談到雲端時，我們大多數人都會想到我們今天擁有的主要公有雲CSP：AWS、Azure 和 GCP。根據另一個定義，多雲是來自這些不同CSP的最佳解決方案，結合此解決方案和服務為業務創造附加值。因此，使用雲端可以意味著公有雲中的解決方案和服務的組合，或者與私有雲解決方案的組合。

但是，結合來自不同CSP和私有雲的解決方案和服務的簡單功能並不能單獨構成多雲概念。因為多雲遠不止於此。

也許解釋這一點的最好方法是使用智慧手機的比喻。假設我們要購買一部新手機。我們把它從盒子裡拿出來並打開它。現在，我們能用那部手機做什麼？首先，如果手機上沒有放上 ＳＩＭ卡，我們會發現設備的功能可能非常有限。手機與外界沒有連接，至少在電信商的移動網路。如果 Wi-Fi 可用，一個選項是通過 Wi-Fi 設備連接它。簡而言之，為了實際使用手機，首先要做的就是確保它具有連接性(connectivity)。

現在，我們將全新的智慧手機設置為出廠預設值，並將其連接到互聯網上。準備好使用了？可能不是。我們可能希望將各種app安裝到手機上，通過Apple store 或 Google Play。這些app本身來自不同的服務商和公司，包括銀行和零售商，甚至可能用不同的開發語言開發的。然而，通過compile app — — 以一種可以被不同設備閱讀和理解的方式轉換代碼 — — 它們將在具有不同版本的手機系統（如 iOS 或 Android）的不同手機上運行。

我們也很可能希望根據我們的個人需求和希望安裝這些app。最後，我們需要能夠訪問手機上的資料。總而言之，手機已經變成了各種個性化服務和資料的登陸平台。

最好的部分是原則上，手機用戶不必擔心更新。操作系統會不時自動更新，大多數已安裝的app仍然可以正常運行。某些app可能需要一兩天才能適應新設置，但最終它們會起作用。並且存儲在手機上或通過某些雲端服務訪問的資料也將仍然可用。圍繞智慧手機的整個生態系統的設計方式使得從終端用戶的角度來看，這個技術是完全通透的：

這就是雲端的概念，在我們的比喻中，智慧手機是實際的所有app的整合平台，幾乎所有東西都聚集在一起，提供無縫的用戶體驗。

多雲不是只有公有雲與私有雲

混合IT環境和多雲之間存在差異。一是混合IT環境是同質的(homogenous)，多雲平台是異質的(heterogenous)。這裡的同質意味著雲端解決方案屬於一個Stack，例如，Azure和Azure Stack或 AWS與 OutPosts。而異質類似Azure 加AWS。

目前，我們將保持非常簡單認知：混合環境是將地端Stack（私有雲）與公有雲相結合。這是企業內部非常常見的部署模型。幾年前有大量報導稱，大多數企業將在 未來幾年將其 IT 遷移到公有雲。許多企業也真的訂定了他們的雲端戰略。但這些企業很快發現將所有系統(All-In)遷移到公有雲並不容易。由於各種原因，一些系統必須保留在地端機房。

兩個顯而易見要留在地端機房的原因是“法規(安全性)與網路延遲”．從法規開始：這都是關於敏感資料和個人隱私的，特別是關於可能不在某個國家/地區或某些區域邊界（例如歐盟）之外託管的資料。例如，位在美國的公司可能無法以任何方式訪問位於歐盟的資料，這本身在雲端領域已經是一個相當大的挑戰。法規和合規性規則通常會阻擋公司將其資料移出本身的地端機房，即使公有雲提供了框架和技術來保護最高等級的資料。我們將在以後的文章討論這一點，因為安全和資料隱私在雲端中至關重要。

網路延遲是將系統保留在地端的第二個原因。可能每個人都可以涉及的一個例子是辦公室內的印表機。把Printer Server放在公有雲可能不是一個好主意。Printer Server的問題是spooling process。Spooling software接收print job並控制必須向其發送的印表機。然後它安排pront job實際發送到該印表機的順序。儘管Spooling process在過去幾年中得到了極大的改進，但執行該過程仍然需要一些時間。公有雲中的Printer server可能會導致該過程的延遲(並且流量也會被收錢)。如果硬要這樣幹也行，如果以正確的方式配置，它將在最靠近我們辦公室的機房中作業，並通過正確的連接進行通訊。

無論如何，我們都會了解：有些功能和應用程式對網路延遲非常敏感。再舉一個例子：零售公司有倉庫來存放他們的貨物。購買商品後，開始揀貨流程。商品在供應系統中被標記，以便企業可以追蹤有多少特定物品仍在庫存中，物品來自哪里以及它們必須運送到哪裡。對於此功能，商品具有可以使用 RFID 等掃描的條碼或QR code。這些系統必須靠近倉庫，或者 — — 如果我們將它們託管在雲端中 — — 可以通過用拉專線到雲端運算的機房中來完成。

這些都是非常簡單且易懂的案例，但如果我們開始考慮手術室中使用的醫療系統或控制發電廠的系統，問題就會真正顯現出來。 對於相當多的公司和機構而言，使用all-public cloud、cloud first或cloud-only的策略並沒有多大用處。 這適用於醫院、公用事業公司以及環境不太重要(無關乎企業重要的業務流程)的公司。

然而，所有這些公司都發現應用程式的開發在公有雲中會更加靈活。 通常，這就是雲端採用的開始：開發人員在公有雲中建立環境和應用程式。 這就是混合 IT 產生的地方：在地端機房使用自行開發的系統，用於運作具有敏感資料的應用程式的重要生產系統，這些應用程式由於延遲原因需要在本地機房進行，而公有雲用於實現快速、敏捷的開發 新的應用程式。

多雲環境是一個真正的混合區域

從智慧手機的比喻來看，應該清楚的是，對於多雲，我們也在談論服務，而不僅僅是在地端機房和公有雲中託管系統。 這主要是 IaaS，企業在私有云中運行虛擬化和非虛擬化實體機，在公有雲中運行VM。

在多雲環境設定中，我們也在討論 PaaS 和 SaaS。 在多雲設定中，它可能變得更像是一種混合模式，就像在我們的智慧手機上，它在設備上保存資料並從其他來源存儲和檢索資料，遠端連接到應用程式或在手機上運作的app，利用 通過該app中的 API 提供的服務。

在多雲中，我們可以做同樣的事情，利用運行在地端機房中的ＶＭ上的功能和應用程式，以及通過互聯網從第三方服務商連接的 SaaS 功能，例如，執行特定的資料分析。資料可能放在我們的地端機房中，而運算資料是從公有雲執行的，或者在針對資料湖(data lake)運行模型的情況下相反，這些資料湖提供來自不同來源的資料流，而根據資料後的模型則交付給地端機房。

這就是多雲的全部意義所在。利用來自不同雲端平台的應用程式、資料和服務，並使用不同的交付模型，例如 PaaS 和 SaaS。它可能包括混合 IT，但它更多的是一種混合模式(mixed mode)，以便通過組合和優化雲端解決方案為我們的業務創造更多附加價值。下一個問題是：企業如何建立最佳的雲端服務組合，並通過這樣做為他們的業務創造附加價值？讓我們深入了解真正的雲端策略的定義。

對我們的多雲目標設立真正的策略

企業採用多雲策略的最常見原因是一個典型原因：避免被鎖在同一個 CSP中或單一服務中。 然而，這並不是一個真正的策略。 這將更多是策略的結果。

策略源於企業的業務和業務目標。 例如，業務目標可能包括以下內容：

• 建立多個品牌
• 加快產品/服務的上市速度
• 增加利潤

業務策略通常以開始於增加營收作為業務目標。老實說：這確實應該是一個目標(Goal)，否則企業會在不知不覺中倒閉。業務策略應側重於如何產生和增加營收。我們將在之後的文章對此進行更多探討。

我們如何將業務目標轉化成定義 IT 策略？這就是企業架構發揮作用的地方。企業架構最常用的框架是 TOGAF(The Open Group Architecture Framework)。 TOGAF 的核心是 ADM ( Architecture Development Method )循環。此外，在構建多雲環境時，ADM 也適用。 ADM 的基本原則是 B-D-A-T：Business、Data、Applications、technology的循環。這完全符合多雲的原則，技術應該是通透的。企業必須檢視他們的需求，定義哪些資料與這些需求相關，以及如何在應用程式中處理這些資料。這被轉化為技術需求並最終選擇用哪些技術，並整合到架構願景中，如下所示：

使用多雲策略為企業提供了靈活性和選擇自由，但這也帶來了風險：注意力會不集中(要同時照顧兩朵以上的雲)。因此，我們需要一個策略。大多數公司採用雲端和多雲戰略，因為它們正在經歷從或多或少的傳統環境向數位轉型的轉變過程。這適用於所有企業嗎？答案是肯定的。事實上，越來越多的企業認為 IT 是一項核心活動。

在這方面，過去幾年時代發生了變化。在九十年代末甚至千禧年之初，許多公司將其 IT 外包，因為它不被認為是一項核心活動。在過去 10 年左右的時間裡，這種情況發生了巨大變化。因為每家公司都變成了是軟體公司 — — 微軟CEO 薩蒂亞納德拉正確地引用了這一訊息，此前軟體品質之父沃茨·漢弗萊 (Watts S. Humphrey) 曾在本世紀初聲稱每家企業都是軟體業務(software business)。

漢弗萊和納德拉都是對的。 以銀行為例：他們一直在轉型，變得越來越像 IT 公司。 他們處理大量資料流，進行資料分析，並為客戶開發應用程式。 單一個CSP可能無法提供所有必需的服務，因此這些公司尋找多雲方案中最佳的解決方案來滿足這些要求。

這些最佳的解決方案可能包含具有典型的server-application topology的傳統工作負載，但將越來越多地轉向在更專注於微服務和雲原生的架構中使用 PaaS、SaaS、容器和server-less解決方案 . 在定義多雲策略時必須考慮這一點：好的策略不是“cloud first”，而是“cloud fit”。

當然，企業在演化，技術也在演化。這被轉化為road map，由業務驅動，但包括一段時期內的技術可能性和機會。這樣的raod map通常會有多個階段，從當前的環境狀態開始，移轉到立即可用的產業標準解決方案，再到採用尖端技術的未來狀態。在下一篇文章中，我們將仔細研究這樣一個road map的定義以及它如何幫助加速業務。

在制定多雲策略時，我們必須發表最後一個評論 — 它涉及資安：這應該始終是每個策略和每個衍生出來road map中的關鍵主題。所有的公有雲和領先的CSP都採用了安全設計原則，並為資安提供了各種非常好的解決方案。坦白說，Azure、AWS 和 GCP 可能是世界上最安全的平台。但這並不會免除我們運作企業的業務時會用到的安全標準、框架、原則和規則的責任。使用多雲託管業務可能會降低攻擊破壞整個環境的風險，但也會增加複雜性。我們將會在其他文章介紹使用 SecOps(Security Operation)在多雲中進行安全控制( Security Control)。

雲端運算的主要玩家(CSP)介紹

我們一直在討論公有雲和私有雲。 儘管我們通常對這些術語的理解可能很清楚，但對兩者有一個非常清晰的定義可能是個好主意。 Microsoft 網站上提供的定義：公有雲被定義為第三方服務商通過互聯網提供的運算服務，讓任何想要使用或購買它們的人都可以使用它們。 私有雲被定義為通過互聯網或私有內部網絡提供的運算服務，並且只提供給特定的人員而不是公眾。 還有更多雲端運算定義，但這些定義非常適合我們的目的。

公有雲

在公有雲中，最知名的CSP是 AWS、Azure、GCP，還有急起直追的OCI(Oracle Cloud Infrastructure)、阿里雲以及用 OpenStack 作為其技術基礎的公有雲業者(例如Rackspace)。 這些都是符合我們剛剛給出的定義的公有雲，但也存在一些重大差異。

然而，AWS 和 Azure 有一個共同的起點 — — 這兩個平台都是從通過 Internet 存儲服務而演變而來的。 AWS是從 S3 的存儲服務開始。 Azure 也是從存儲開始的。

AWS、Azure 和 GCP 都提供了各種各樣的託管服務來構建環境，但它們在應用技術的方式上都有很大的不同。簡而言之：這些概念或多或少相似，但其底層技術，它們是完全不同的。正是這一點使管理多雲解決方案變得複雜。

還有更多的公有雲產品，但這些產品通常並不適合所有用途。包括Oracle和 SAP 在內的主要軟體公司也提供公有雲產品，Oracle與SAP都提供了自家ERP的SaaS產品。

私有雲

大多數公司都計劃或實際上正在將其工作負載遷移到雲端。一般來說，他們選擇了一些主要平台來託管工作負載：Azure、AWS、GCP。但老實說，其實還有更多雲端平台。

正如我們在前面所說的那樣，在規劃工作負載並將其遷移到這些平台時，企業發現它確實變得複雜。更重要的是，在合規性、安全性和隱私方面的法規越來越多，迫使企業在將資料放到雲端平台之前要三思而後行。最後，這一切都與資料有關。它是任何企業中最有價值的資產 — —可能僅次於員工。

解決方案：我們不是將資料帶到雲端，而是再次將雲端帶到資料中。在過去的幾年裡，我們看到了一個新的趨勢，主要的CSP已經開始涉足其他公司傳統上仍占主導地位的領域。存儲廠商和SI等公司。新的現實是，公共雲CSP正越來越多地轉向地端機房。

在私有雲中，VMware 似乎是占主導地位的平台，僅次於以 Microsoft Hyper-V 。然而，微軟正越來越多地推動客戶使用 Azure ，而在需要將系統保留在地端機房的地方，他們可以用Azure Stack 的方式，我們將在本文後面更詳細地討論。

特別是在歐盟的政府環境，OpenStack 似乎仍然做得很好，以避免美國公司有控制權甚至查看資料。然而，OpenStack 的使用似乎正在下降。

在本文中，我們將簡要介紹 VMware 和 OpenStack 作為private stack foundations。之後，我們將深入了解 AWS Outposts 和 Google Anthos。基本上，這兩個服務都將 AWS 和 GCP 的公有雲擴展到地端機房。 Outposts 是一整組的機櫃，裏面有已經整套設定好的運算、存儲和網路設備。 Anthos by Google 更像是一組組件，基本上是將Google Kubernetes Engine (GKE) 的control plane 延伸到地端機房的容器控制。最後，我們會提到 Azure Stack 產品組合。

到目前為止，我們已經了解了私有云和公有雲之間的差異以及公有雲的主要玩家。在本文中，我們將主要關注多雲產品組合中的“主要”業者，如下圖所示：

VMware

從本質上講，VMware 仍然是一種虛擬化技術。它從基於 x86 的實體服務器的虛擬化開始，在一台實體主機上啟用多個VM。後來，VMware 將相同的概念引入到存儲中，通過 vSAN（ virtualized SAN）和 NSX（network virtualization and security）對網路進行虛擬化，使得在私有雲中進行micro-segmentation成為可能。

該公司一直能夠不斷尋找方法來隨著向雲端的轉變而前進 — — 例如，通過與 AWS 一起開發一個可以將 VMware 私有雲無縫擴展到公有雲。隨後此項服務也同樣地在GCP上出現．

如今，VMware 在容器化領域的 Pivotal Kubernetes service(PKS) 和 Tanzu Mission Control 的container orchestration方面也是一個強大的玩家。在過去幾年中，該公司加強了其在資安領域的地位，再次瞄準了multi-cloud stack。基本上，VMware 正試圖通過利用native public cloud players(也就是三大公有雲)之上的解決方案來成為多雲網路中的蜘蛛。

OpenStack

OpenStack 絕對有好處。它是一個免費和開源的雲端運算軟體平台，主要用作 IaaS。 OpenStack 使用 KVM 作為其主要的hypervisor，儘管 OpenStack 有更多的hypervisor可用。它曾經而且現在仍然受到許多公司和機構的愛用 — — 因為它提供了一個穩定的、可擴展的解決方案，同時避免了vendor lock-in在主要的CSP和技術提供商上。 IBM 和富士通等主要SI和系統提供商在各自的雲端平台 Bluemix 和 K5（2018 年在市場上退役）中採用了 OpenStack。

然而，儘管 OpenStack 是開源的，並且可以完全根據特定的業務需求進行調整，但它也很複雜，企業發現管理起來很麻煩。這些平台中的大多數都沒有 Azure、AWS 和 GCP 等為其客戶提供的豐富解決方案。在過去的幾年裡，OpenStack 似乎在企業界失去了立足點，但它仍然具有一定的相關地位，因此我們把它納入考慮。

AWS Outposts

我們在 AWS 運行的一切，現在都可以搬到自己的地端機房上運作，包括EC2)、EBS、RDS，甚至是EKS。這一切都與我們在AWS中部署的VPC無縫整成，使用相同的 API 和控制元件。也就是說，AWS Outposts：就是地端機房的 AWS 服務。

一個問題可能是這對於 VMware 和 AWS 在其產品組合中的 VMC（VMware on Cloud）on AWS 服務意味著什麼。

VMConAWS 實際上將私有雲擴展到公共雲，基於 VMware 的 HCX。 VMware 在 AWS 中使用bare metal instances，將 vSphere、vSAN storage和 NSX 部署到這些實體機以實現software-defined networking。

我們還可以通過與 AWS 整合在 VMConAWS 配置之上使用 AWS 服務。 Outposts 的作業方式正好相反：將 AWS 引入私有雲。

Azure Stack

帶有 Stack HCI、Hub 和 Edge 的 Azure Stack 產品組合。嚴格說起來Azure Stack與AWS Outposts的模式其實大同小異．

Azure Stack HCI(Hyperconverged Infrastructure) 最重要的特性是它可以在與 “Azure 的“disconnected”的情況下運作”。簡單地說：HCI 的工作方式類似於企業的分公司辦公司的資訊機櫃。基本上，HCI 是一個包含運算、存儲和網路的機櫃，跟 AWS Outposts差不多。這個機櫃包簡單來說就是 Azure幫我們做好的整套Hyper-V 的虛擬化工作負載。那麼，我們為什麼要以 Azure Stack 的形式運作它呢？嗯，因為Azure Stack HCI 還可以選擇連接到 Azure 服務，例如 Azure Site Recovery、Azure Backup 和 Azure Monitoring，也就是說Azure Stack可以整合Azure 雲端運算的一些服務。

這是一個非常簡單的解決方案，只需要經過 Microsoft 驗證的硬體、安裝 Windows Server 2019 Datacenter Edition、Windows Admin Center 和 Azure 帳號來連接到特定的 Azure 雲端服務。

不過現在可能會變得有點複雜：Azure Stack HCI 也是 Azure Stack Hub 的基礎（PS：所有 Azure 產品都基於 Windows Server 2019）。然而，Hub 是一個不同的解決方案。雖然我們可以獨立運作 Stack HCI，但 Hub 作為解決方案與 Azure 公有雲整合 — 這確實是一個不同的玩法。這就是我們無法將 HCI 升級到 Hub 的原因。

Azure Stack Hub 實際上是 Azure 公有雲延伸到地端機房。我們可以在 Azure中進行所有操作，也可以部署在 Hub 上：從 VM 到apps，這些作業都 Azure portal甚至 PowerShell 進行管理。而這一切都像 我們在Azure cloud一樣，包括更新configuration和fault domains等。 Hub 還支援具有最多三個fault domain的availability set以。這樣，我們就可以像在 Azure 中一樣在 Hub 上建立高可用性。

如果因為合規性需要在地端機房運作應用程式或 VM，則 Hub 和 Azure public cloud的完美案例是在公有雲上進行開發並將生產環境轉移到 Hub，我們可以配置pipeline，使開發和測試可以在公有雲上進行，並在 Hub 上運行經過驗證的生產系統的部署，包括所需的配置。這將會是可以運作的，因為 Azure 平台的兩個entities(雲端與地端)都以一致的方式使用 Azure resource provider。

不過，有幾件事需要注意。computer resource provider將在 Hub 上建立自己的 VM。換句話說：它不會將 VM 從公有雲複製到 Hub。這同樣適用於網路資源。 Hub 將建立自己的網絡功能，例如load banancers、vNet 和NSG。至於storage，Hub 允許我們部署在 Azure public cloud上可用的所有存儲形式，例如 blob、queue和tables。也就是說Hub以類似IaC(Infrastructure as Code)的方式在 Hub中重建一切．

最後一個 Stack 產品是 Stack Edge。此前，微軟將 Azure Stack Edge 作為 Data Box 出售：它仍然是 Data Box 系列的一部分。 Edge 可以簡單地將資料傳送到 Azure。正如微軟在其網站上所說：Azure Stack Edge 充當network storage gateway( AWS也有一樣的產品)並執行到 Azure 的高速傳輸。

另外。 Edge 運行容器以在edge location啟用資料分析、執行查詢和過濾資料。 因此，Edge 支援可以在其上運行容器的 Azure VM 和 Azure AKS。 就此而言，Edge 是一個相當複雜的解決方案，因為它還與 Azure 機器學習 (AML) 整合。 我們可以在 Azure 中建立和訓練機器學習模型，在 Azure Stack Edge 中運作它們，然後將data set送回 Azure。 為此，Edge 解決方案配備了加速構建和（重新）訓練模型所需的 FPGA（Field Programmable Gate Arrays）和 GPU。 話雖如此，明顯的案例是資料分析和機器學習的實施，因為我們不希望將原始資料立即上傳到公有雲。

Azure Arc

這裡還有一個功能需要討論，那就是在 Ignite 2019 上推出的 Azure Arc。Arc 允許我們將不是 Azure VM連接到 Azure 並管理這些非 Azure 工作負載，就好像它們完全部署在 Azure 上一樣。

如果要將VM連接到 Arc，則需要在該機器上安裝agent。然後它將會有一個 resource ID 並成為 Azure tenant中resource group的一部分。但前提是，我們需要在網路端配置一些設置並註冊適當的resource providers（Microsoft.HybridCompute 和 Microsoft.GuestConfiguration）。這確實需要熟練的 PowerShell 技能。如果這些都完成，則可以通過 Azure 管理非 Azure VM。實際上，這意味著您可以向這些工作負載加上tag和policies。這樣的使用案例：按照與 Azure VM相同的政策來管理非 Azure VM。這些不一定必須在地端機房內。這可能是 Arc 最好的部分：它也適用於部署在 AWS/GCP 中的VM。

有了關於 Arc 重要部分，我們來到了多雲討論的核心，那就是“整合(Integration)”。我們在本文中看到的所有平台都有優點、缺點、依賴關係，甚至是特定的使用場景。因此，我們看到企業在不止一個雲端中試驗和部署工作負載。這不僅僅是為了避免CSP 的vendor lock-in：主要是因為這個世界上沒有“一刀切(one size fit all)”的解決方案。

簡而言之，應該清楚的是，這真的不是cloud first。這是關於讓cloud fit，即從不斷增加的各種雲端解決方案中獲得最佳效益。

GCP Anthos

Anthos 將GCP — — 或者更準確地說，GCP K8S Engine — — 帶到地端機房，就像 Azure Stack 和 AWS Outposts 所做的那樣，但它專注於使用 Kubernetes 作為landing platform，使用 GKE 將工作負載進行移動和轉換並直接放入容器中。 它不是一個獨立的機櫃（像 Azure Stack 或 Outposts）。 該解決方案在使用 vSphere 的虛擬機或實體機之上運行，更像是一種 PaaS 解決方案。 Anthos 使用開源技術（包括用於微服務的 Istio 和用於在 Kubernetes 上擴展和部署雲原生應用程式的 Knative）真正加速了應用程式向更多雲原生環境的轉變。更多Anthos運行在Vmware vSphere上的資訊，請參閱GCP的文件庫．

總結

在本文中，我們了解了真正的多雲概念是什麼。 它不僅僅是一個混合平台，在一個平台中包含不同的雲端解決方案，例如 IaaS、PaaS、SaaS、容器和serverless，我們可以將其視為單項優勢(best-of-breed)的混合區域。 我們可以將解決方案與特定的業務策略相匹配。 在這裡，企業架構開始發揮作用：業務需求始終是最優先的，並通過使用資料、應用程式，最後通過技術實現。 諸如 TOGAF 之類的企業架構方法是將業務策略轉化為 IT 策略（包括roadmap）的良好框架。

我們還檢視了私有雲和公有雲領域的各個玩家。 在之後的文章，我們將進一步探索這些雲端運算廠商的產品組合，並討論我們如何整合解決方案，真正掌握多雲領域。