企業的效益與挑戰 — 多雲端平台Part 1

使用雲端解決方案的效益與挑戰

企業現今已越來越依賴使用雲端運算來部署和管理應用程式。 事實上，大多數的企業都支援許多cloud-based的應用程式。 根據 IDG 在2022年的一項研究，企業將在未來18個月內將IT基礎建放在雲端的比例會從41%上升到63%。 過去完全在地端機房管理的應用程式及服務，例如CRM、ERP和HR系統，現在完全都放置在雲端中。 與此同時，企業正在將他們自己的自行開發的應用程式遷移到雲端中。 在雲端中託管IT基礎設施可以節省相關資料中心的建置/維護/維運等成本。 但是，這些會涉及到使用與適應多雲架構相關的挑戰和複雜性。

企業為何使用多雲端架構

企業在選擇雲端平台商(以下簡稱 CSP)時需要權衡許多因素。 企業在遷移到雲端時面臨的最大挑戰之一是選擇合適的平台。 有時，選擇是為我們做出的。 例如，某些服務只與某些CSP合作。 在其他情況下，當應用程式首次遷移到雲端中時，組織已經被鎖定在使用特定的CSP。

運行多雲架構相關的另一個挑戰集中在資安面。 企業需要在所有CSP平台上套用與地端機房系統一樣的資安策略。 最後，系統是否在我們的核心網路中並不重要。 放在AWS、Azure或GCP的資料中心； 或放在其他的CSP。 資安團隊要對系統的完整性負責，無論它位於何處。

這些挑戰當然令人望而生畏，但並非不可克服。 本文的目標是幫助管理人員和領導者了解遷移到多雲端基礎架構並確保其資安的挑戰。 在本文中，我們將了解管理和協調多雲端環境的方法，包括一些主要在保護我們的IT環境的“邊緣(edge)”技術。

什麼是多雲架構

現今的企業通常會使用兩種不同的雲端架構部署：多雲(multicloud)與混合雲(hybrid cloud)，當然可能有少數的企業兩種模式也會同時使用．多雲的部署通常是相依性沒有很強的應用程式分別部署在不同的CSP上．例如，外部的 DNS服務與網站在 CSP A，內部的ERP與 HR系統放在 CSP B上．

儘管多雲部署看起來很簡單，但緊跟每個CSP的不同功能與服務並確保在所有CSP之間正確進行相關雲端政策可能是非常具有挑戰性的。 在多雲架構中，複雜性源於在各種共享責任模型(shared responsibility model)和地理位置考慮的背景下管理環境的過程。 這種類型的架構還意味著每個CSP都是我們的單點故障(single point of failure)。

混合雲通常被認為是公有雲和私有雲的組合，但在某些情況下，此定義已擴展到地端機房和雲端。 根據 NIST 800–145文件，“混合雲基礎設施是兩個或多個不同的雲端基礎設施（公有、私有或社群雲）的組合，它們仍然是獨特的實體，但通過標準化或特定技術綁在一起，這些技術支援資料和 應用程式的可移植性(portability)（例如，因為cloud bursting 會在CSP之間用到的Load balancing）。”

混合雲涉及將單一系統部署到多個雲端。 例如，企業不是將 Web service部署到單一個CSP，而是將其部署到多個CSP。 一個企業可能決定使用 AWS 作為主要提供商，而 GCP作為備用提供商。 或者，我們可能希望 AWS 和 GCP都處於運行狀態，並在兩個CSP之間交替income requests。

我們可以以下多種方式進行混合雲部署：

Public-private
部分的Application運行在公有雲，但backend system放在我們的地端機房或私有雲。不過這樣的做法可能會產生兩個問題，一個是網路的延遲性與網路流量費用的升高．

Active-passive
一套系統分別部署在兩個不同的 CSP，一個是Active，另一個就是passive(standby)．這樣的問題在於，兩邊application update/configuration與資料的同步的問題．這也會涉及費用的升高．

Active-active
Service或Application部署到兩個或多個 CSP，所有這些CSP都是即時運作的，並根據地理位置資訊、負載平衡演算法或簡單的round-robin request同時提供內容。這種方式可能因服務的型態的不同會有技術與費用上的挑戰．

混合雲解決方案的部署要複雜得多，甚至比後端管理的多雲解決方案還要複雜。 但是，Uptime的效益和沒有單點故障足以抵消複雜性方面產生的成本(如果我們提供的服務SLA要求很高的話)。 這些混合雲解決方案需要還在一開始部署之前進行了更多的前期規劃，以便團隊可以了解每個CSP將如何提供資料，以及為跨所有平台向我們的客戶提供同質體驗所需的投資。

多雲端架構的效益

多雲架構有很多效益。 其中一個效益與成本有關。 在地端機房維護server和基礎設施需要大量持續的資本投資，而在雲端中部署可顯著降低成本(前提是要懂得如何使用雲端)。 除了資本支出之外，多雲端戰略使企業能夠根據每個專案明智地投資於最適合特定服務的CSP。 AWS 可能最適合 IaaS，而 GCP可能最適合部署自行開發的Application。 維護多個CSP意味著我們將能夠為每個目的選擇最好的一個。

除了節省成本之外，多雲平台還有其他好處，包括：

• 不會給其中的一個CSP鎖住(vendor lock-in)
• IT基礎設施的資安與韌性(resilience)

撇過一眼，CSP之間在功能和定價方面似乎有很多相似之處，但仔細觀察可以發現許多差異。 如果我們的公司被鎖在單一 CSP，我們將沒有機會了解這些差異。 例如，兩家CSP可以提供類似的服務，但其中一家將其作為基本定價的一部分； 另一家將其作為額外的資源提供，可能會導致無法預測的帳單費用。 一些CSP僅在某些區域提供特定的功能或服務，或者甚至可能不在對我們的公司很重要的地區提供服務。 防止Vendor lock-in意味著可以自由地以最佳方式在我們需要的地方部署應用程序，無論是技術、效能還是價格優化。

多雲解決方案還提供了更好的基礎架構彈性。 現代企業要求對其客戶和員工所提供的Application和service具有高可用性 (HA)。 可用性的最輕微中斷都可能導致cascading failure(海嘯等級的中斷)和相關的營業損失(這個是CSP不會賠償我們的)。 SAL 99% 的想法 — — 甚至是廣為人知的五個九 (99.999%) 的Uptime — 是一個過時的概念。 客戶和員工需要知道他們可以 100% 的連結我們的 Web application，無論 Internet 上發生了什麼(但這是需要付出很大的代價)。 多雲架構可以提供企業所需的彈性和正常運行時間。

跨多個 CSP 分配工作負載的模式

每種類型的架構部署都有其優點和缺點。 通常，所使用的架構類型取決於正在部署的應用程式的類型，但它也可能取決於預算問題和進行部署的組織成熟度。

以下每一部分中討論的所有模式都沒有比其他模式更好。 最佳選擇在很大程度上取決於組織的特定業務需求、內部流程和標準。

Active-Active與 Active-Passive
Active-Active和Active-Passive架構都是為了確保 HA。 它們主要在確保在世界任何地方的客戶或員工都可以快速連結到我們的 Web service，並且網路延遲非常低。 這些架構還確保如果一個CSP遇到故障，我們的客戶不感覺到這件事，因為failover將是無縫的。

下圖提供了active-active架構的簡單範例。 一個 Web service部署在多個CSP上，每個CSP都在Application前面啟用了負載平衡服務。 負載平衡器確保其背後的服務啟動並運行，並且不會因流量過載。 然後負載平衡器選擇最佳服務器並將income request導向到它。 如果一個CSP掛掉，另一個CSP能夠承擔流量負載。

還有其他方法可以啟用這種負載平衡。 一些企業使用先進的 DNS 服務來複製這種架構。

下圖顯示了類似的Active-Passive多雲架構。 該解決方案具有相同的high-level架構。 不同之處在於，第二個CSP的資料中心中的系統保持休眠狀態，除非第一個CSP出現某種故障。 這種故障本質上大都屬於CSP的整個region資料中心或 網路服務中斷。 但這也可能是threshold failure，例如，由於廣告促銷，該網站的流量大幅飆升，或者它開始在一些社交媒體上熱門起來。

在Active-Passive架構中，備用站點是“hot site”，這個hot site是會監控primary site，但除非發生故障，否則不會有流量流向該CSP。 Active-Passive架構比Active-Active多雲環境更具成本效益，但需要考慮許多技術複雜性。 首先，必須定期測試備用站點，以確保在主站點發生故障時實現無縫故障轉移。 備用站點的基礎設施必須被視為活的(live)。 我們可以通過在備用站點上測試新的patches和configurations，然後再將它們push到primary site。

Public-Private多雲架構

到目前為止，我們一直在討論公有雲基礎設施，但雲端基礎設施也可以是private的。這可以是在一般的CSP（如 AWS或 GCP）中設置的非對外(Internet)instance，也可以是在我們自己的地端機房中的instance。

私有雲基礎架構通常設計用在放置高度敏感的企業資料。私有雲instance可能保存客戶、員工資料或其他敏感的公司商業資料。對此類基礎設施的訪問通常受到限制，並且需要使用VPN，或者至少需要防火牆和proxy rule，以防止外部人員訪問私有雲instance中包含的資料。

但是，對於私有雲架構，還有第三種選項。這就是hybrid public-private cloud。下圖顯示了這種設計，其中來自私有雲的一些資訊需要可供更多的客戶或員工來結連，甚至可以public access。在這些情況下，架構分為公有雲中的server和私有雲中的server，防火牆(或其他資安設備或服務)來限制對需要access公有雲服務。

這可能是一個麻煩的配置，因為有可能暴露敏感資料。 例如，AWS 中有多個 S3 bucket 資料暴露。 這並不意味著我們不應該部署這樣的混合架構。 事實上，隨著越來越多的資料可供公眾使用，它們變得越來越普遍。 它的意思是，從規劃之初就需要將安全性視為這些部署的一部分，我們將在下面的章節中進一步討論這一點。

權衡

儘管多雲架構的效益很多，並且在本文中都進行了詳細討論，但重要的是謹慎的進入多雲戰略。 遷移到這種類型的架構涉及許多權衡，一些企業可能沒有為多雲世界做好準備。 企業在考慮多雲戰略時需要注意三個潛在的陷阱：

• 增加網路的複雜性
• 緊跟不斷變化的公有雲服務
• 發展敏捷性

以下讓我們逐一討論這些潛在的陷阱以便我們可以做出最佳決策．

增加網路的複雜性
就其本質而言，多雲部署很複雜。 這種複雜性不僅適用於我們使用的網路基礎設施或我們管理server和資料庫的方式。 在規劃策略時，我們需要考慮每個CSP的變化莫測的特性（例如platform的interface、control和limitations）。

但主要困難在於network stacking。 任何從事網路或資安工程師職涯的人都曾有過“哦，SxxT”的時刻，網路的一部分不小心掉線了。 回想一下，一個錯誤會導致跨多個資料中心的全球基礎架構部署中斷。 例如，2018 年 11 月，尼日利亞 ISP 的BGP配置錯誤導致 Google 的許多服務在一個多小時內無法在全球大部分地區使用。

在多雲環境中正確設計網路的基礎設施至關重要。 正確的多雲設計會涉及 到DNS 管理、負載平衡器配置、server redundancy、DB replication和Firewall rules，這些規則允許網路流量在多個CSP之間自由流動，同時不允許未經授權的訪問者訪問敏感資料。 當然，這種設計不是一成不變的； 它是一個動態文件，每次進行變動時都必須不斷更新並且是所有利害關係人（包括我們的CSP）共享的。 如果我們不使更新文件保持最新並定期共享，則一個團隊所做的變更可能會干擾另一個團隊的變更並導致整個系統崩潰。

同樣，正確執行此操作的好處是前所未有的系統韌性和正常運作時間，使用我們自己的地端機房幾乎不可能有這樣的程度，不然就是所費不貲。

緊跟不斷變化的公有雲服務
許多企業希望在多雲架構中部署應用程式，因為這些企業正在雲端環境中逐漸成熟並渴望採用新的技術。 隨著企業的雲端使用度的成熟，他們能夠進行更複雜的專案，他們的系統也變得更加複雜。

隨著我們的組織日趨成熟，我們的CSP也日趨成熟。 這意味著所有的CSP三天兩頭就會提供新的服務、定價結構和功能。 了解哪些新功能可以適合我們使用是很重要的，尤其是這些新功能是否可以降低成本。 畢竟，降低成本是將服務和應用程式遷移到雲端的主要驅動力。

哪我們如何了解不屬於我們當前部署的 CSP提供的新服務？ 大多數CSP都讓我們可以選擇在他們的網站上查看服務，當然，CSP的銷售團隊總是很樂意拜訪我們。 但是這些選項都要花時間，並且仍然有可能錯過可能非常適合我們公司的新服務。

另一種選項是依靠我們自己的技術團隊的自行研究。 CSP通常會為我們的技術團隊提供認證計劃。 這使我們的團隊成員可以更深入地了解 CSP所提供的服務，並幫助我們了解最新的產品。

很多企業都使用 Bluewolf、Jamcracker 或 Cloud Foundry 等CSB(Cloud Setvice Brokers)來協助客戶選擇合適的價格提供合適服務的CSP。 CSB 擁有與廣泛的CSP合作的經驗，並與其他客戶合作過，他們的需求通常與我們的需求相似。 這種廣泛的經驗使他們能夠幫助我們找到我們以前可能沒有考慮過的雲端服務。 CSB 可以顯著減輕這個選擇 CSP過程的痛苦，並且可以幫助企業在多雲環境中快速啟動和運作。

發展敏捷性
考慮遷移到多雲架構的最後一個權衡是發展敏捷性。 多雲架構需要能夠建立可在多個CSP的平台上運行的code，理想情況下無需更改從一個CSP到下一個CSP的code。 我們組織內的開發標準有助於解決這個問題，因此即使code repo很亂，每個CSP也可以在沒有不同code repo的情況下運作這種混亂。

將應用程式遷移到多雲架構可能需要我們的技術團隊檢視我們的code。 Code需要在我們的CSP中進行清理和測試，以確保變更時不會產生導致其中一個instance不可用的問題。 但這不僅僅是編輯code； 還需要完成其他任務，例如確保我們的CSP在其code repo中為我們運行的任何libraries, language compilers/ runtime與 server versions。 JDK就是一個很好的範例 — — 我們可能正處於只能安裝open JDK 版本的程度。 另一個範例是，我們可能擁有一個運作一個更新版的 servlet 規範的 Apache Tomcat 。

另一個問題可能是我們被一個舊系統卡住了，它是你tech stack的一部分，它是一個CSP無法提供的服務，比如一個舊的、已經不支援的關聯式資料庫。這可能會導致與開發人員計劃升級和資料遷移所需的時間相關的費用，以及意外的軟體授權費用。這些都不是進行code clean可以解決的，但有必要在進行遷移時考慮時間和成本。

發展敏捷性不僅僅是可以跨多個雲環境運行的clean code。這也意味著適應code repo更頻繁變更的現實。這意味著每月或每週甚至是幾天就變更一次我們的code，而不是一年幾次。開發團隊還需要能夠快速編寫和測試新的security patch並在應用程式不是離線的情況下快速部署它們。說實話，這已經是一個開發現實，在雲端中做這件事並不是這種開發過程的要求。敏捷開發是許多企業的運作方式，無​​論應用程式位於何處。

鑑於敏捷開發過程是新規範，大多數企業在遷移到多雲端基礎架構時發生的變化既不是code也不是開發週期。 運行 DevOps 的是 DevOps 流程和CI工具。 我們現在必須在多個CSP上打包、部署和運行自動化測試。 也許一個應用程式只在一個CSP上，但另一個需要redundancy的應用程式在多個CSP上。 我們將希望開發週期能夠自動配置和部署到適當的位置。 而且您的本地開發環境可能不是在CSP中（儘管它可能是）。

評估

看到這裡，我們可能會問，我如何確定我的專案和企業是否已為多雲架構做好準備？ 從這一點上來說大多數的IT 專案的未來都將在雲端中，這並不是誇大，或是有什麼爭議。 組織通過遷移到雲端而實現的節省成本、系統韌性和新功能強化的效益是我們無法忽視的。 遷移到雲端使企業可以專注於其核心競爭力，而不是花心力去管理地端機房。

但是遷移到雲端和遷移到多雲端或混合雲環境是有區別的。 讓我們仔細看看如何評估哪種策略適合我們的組織。

權衡利弊

與任何商業決策一樣，重要的是要著眼大局，不要短視，權衡遷移到多雲環境的利弊。

我們可以從檢查應用程式現行的狀況開始。它是放在我們自家的機房、還是放在在CSP的資料中心？從地端機房的應用程式跳轉到託管在世界各地的多個資料中心的應用程式可能過於激進（不是永遠都這樣，但對於許多企業來說確實如此）。大多數企業首先將其應用程式遷移到單一個CSP。這使企業能夠更好地了解與雲端遷移相關的經驗和挑戰。例如，這個企業可能會發現其應用程式的代碼不像它曾經想像的那樣可移植。在我們有雲端環境中作業的經驗之後，跳轉到多雲架構會更容易。 （PS:並沒有說它會”很容易”，只是”更容易”。）

確定我們的公司願意將多少控制權交給CSP也很重要。 CSP提供一系列服務，從最基本的服務（CSP只提供虛擬機和 IP 地址）一直到完全託管的服務。 我們選擇的服務也是預算問題。 我們利用的CSP的服務越多，成本就越高。

當然，所有這些都必須在多個CSP之間同步。 例如，在完全託管的雲端環境中，了解CSP上patch的速度很重要。 我們不希望有一半的server在patch安裝幾週後容易受到攻擊，或者因為code一個CSP有update的特定的library而另一個 CSP沒有update到而導致系統停止作業。

在遷移到多雲環境之前，預先完整記錄code和dependencies非常重要，而且我們必須向ＣＳＰ提出同樣的要求。 我們需要充分了解企業正在使用的服務、CSP的patch週期以及出現問題時如何獲得支援。 我們還需要與我們的團隊共享這一類的資訊，以便每個人都知道每個CSP的限制並有權開工單給 ＣＳＰ。

多雲基礎架構設計

遷移到多雲架構通常意味著需要重新設計我們的應用程式以適應更複雜的網路和基礎架構環境。與其他文件一樣，這需要CSP自己在可能的情況下進行仔細的規劃和幫助。許多 ＣＳＰ都有架構師，他們可以幫助回答團隊提出的任何問題。他們還可以提供使遷移過程更順暢的提示。請記住，CSB 的員工中通常有架構師，他們可以就各種雲端平台的不同面向提供建議給我們。

雲端架構師是一種寶貴的資源，對於許多組織來說，有一個雲端架構師是值得的。架構師可以是外部廠商，也可以是受過訓練有相關經驗的員工。有雲端架構師的優勢在於，我們將擁有一個了解和理解您的應用程式的人，而外部顧問則不會。雲架構師有權對需要變更的內容進行更準確的評估，以最大限度地提高多雲端遷移的成功率。

結論

從長遠來看，將應用程式遷移到多雲架構將提高系統韌性，同時為我們的企業節省費用。 但是多雲遷移會帶來挑戰和短期成本。 在進入多雲基礎架構之前，重要的是向後退後一步，了解我們的應用程式和團隊的成熟度，並確保組織已準備好應對多雲部署的複雜性。

完成內部評估後，下一步是了解哪些CSP將滿足我們的需求以及他們的產品是什麼。 然後，就是進行設計架構了，盡可能與雲端架構師合作。 這也是為我們的應用程式記錄新設計並進行支援新架構所需的任何變動。

最後，要明白這不是一個“一勞永逸”的過程。 CSP在不斷變化，與最新的CSP產品保持同步很重要。 如有必要，我們讓 CSB 來幫助我們找到與我們需求最佳匹配的雲端服務。

多雲是大多數企業的未來 — — 其效益超過了與遷移相關的任何一開始的痛苦。 但與任何商業決策一樣，正確規劃遷移並運用切合實際的時間表非常重要。

第下一章我們討論多雲架構中的Orchestration management。 我們將重新檢視本文中討論的一些挑戰，並回顧了有效管理遷移過程和持續維護多雲架構的方法。