企業的多雲策略

策略的秘訣就是玩你能贏的賽局

15 min readJun 21, 2023

越來越多的企業從Cloud-First開始轉向MultiCloud。但是，原來在一個雲端平台上使用"精實(Lean)方式的運作"與一個雲端平台上的"Infra一致性"是否能夠在多雲策略上保持下去，並且還能提供"企業業務的敏捷性呢"?這其實是一個挑戰。它需要一個堅實的策略。

本文將討論的重點如下:

規劃多雲的評估
執行技術上的對映與治理
規劃多雲的過渡與轉型
探討系統可以轉型的選項

規劃多雲的評估

我們在規劃使用雲端時一定知道有甚麼系統要上雲，或是要在雲端上開發甚麼樣的系統，藉以在雲端上設計與建立其Landing Zone。這一段時間需要評估企業使用多雲的能力，這個跟我們在本部落格CAF系列文章都有提到過。

哪麼，首先要問的是: 為什麼企業要選擇多雲策略?這個策略相關的利害關係人有哪些?又有哪些人會參與這些活動?甚麼因素驅動企業開始過渡與轉型到多雲?在還沒有回答這一些問題之前，我們無法開始規劃實際的作業。在企業中的任何策略都必須對企業有實際的效益，多雲也是一樣。因為企業需要投注資源(人力、時間、資金)來進行。

所以評估一定有其必要，因為評估只會花企業相當小的資源。總比所有的系統All In到雲端中(或使用多雲)才知道不適合，哪麼所花的代價一定遠大於評估作業所需要的資源。我們在CAF系列文章也一直強調評估的重要性。

哪麼，企業如何知道其雲端成熟度如何呢?這時我們可以使用COBIT中提及的CMM(Capability Maturity Model來自CMMI)，如下圖。

更多CMM的說明可參閱本部落格雲端運算的績效管理一文。

但其實在傳統IT領域有堅強與良好控制的組織架構也不一定能夠駕馭好雲端。因為雲端運算是另一個不同的領域，它跟我們能Full control的傳統資料中心不同，它不需跟雲端供應商(以下簡稱CSP)在同一套平台內各有需要負責分工的部分，從IaaS，PaaS到SaaS都不一樣(就是CSP經常提到的Shared Responsibility)。

以下是通常多雲策略的評估步驟，評估的任務就是企業是否做好準備。

設定範圍 —
從業務的角度而非技術角度，哪些業務功能使用多雲會有其效益
辨識所有的Infrastructure組件
辨識所有的應用程式與其相關組件
辨識資安需求，包括現有的政策與保護範圍
辨識所有會參與到雲端遷移專案相關的利害關係人，包含業務與技術單位
辨識企業現有的資源(人力、時間、資金)是否可以支撐相關的作業

上述的所有結果統合之後，我們就可以製作相關的商業案例(可能是正面也可能是負面的)。有關於商業案例的範例可參閱本部落格雲端運算的商業案例一文。

執行技術上的對映與治理

數位轉型是現今每家企業喊的口號，哪麼"技術"無可質疑的就是重要的基礎。不過，從企業治理面來說，哪種技術的選擇與管理就需要正確的規劃。重要的是該技術是否能符合企業的目標，這一部分我們在雲端運算的治理與管理一文中已經說得很清楚了。

通常會阻礙企業使用新技術的原因大概有以下兩種:

它對企業的業務沒有價值效果
企業人力不足，甚至是雲端技能不足。如果要操控多個雲端平台，這可能更是瓶頸

技術對映在這裡可以提供協助。它通常從定義use case開始：該技術將用於什麼？接下來，根據現有產品組合進行評估，以確定如何在企業的流程和技術基礎中實施和整合該技術。最後一步是實際規劃，其中運用變革和培訓是關鍵要素。

追蹤雲端上的創新

相信大家都知道，雲端上的技術創新經常在變化，上面的雲端服務也是一大堆。哪企業如何追蹤這些技術創新呢?

第一件事要知了解的是，這個新技術是否對企業是有效益的?通常是讓公司的產品與流程能夠又快又好又便宜。例如今年(2023)都在瘋AI技術，哪這是否對公司是有效益的呢?是nince-to-have 還是 need-to-have?至於新技術的了解與學習，各大CSP經常會辦一堆演討會或大拜拜。可以從這一去了解。

適應創新

上面說到新技術的創新必需對企業的業務起到加值作用。在雲端運算的治理與管理中的企業策略一節已經提到雲端運算(也能套用在多雲策略)能夠協助企業完成其目標。

例如，使用使用無伺服器這種event-driven技術。可以強化客戶體驗與減少IT單位的人力對其IT Infra進行設置與管理與減少相關IT費用。但是，企業的IT人員是否有足夠的能力可以駕馭這一個新技術呢?另外企業的系統架構是否可以更改成使用這一類的新技術呢?花費的人力物力與時間是否有達到企業想要的ROI呢?

定義技術路線圖與業務是一致的

您很有可能聽說過北極星架構(North Star architecture)。它通常用於定義企業未來的雄心壯志，尤其是在數位轉型。幾乎每個企業都定義了一顆北極星，並讓團隊迭代實現這一雄心壯志：這是敏捷工作的基本理念。該架構在每一個迭代步驟中不斷發展，並在必要時進行調整和重構以向北極星移動。

但是，技術團隊需要"指導和範圍"。迭代工作和僅在北極星中定義雄心壯志的風險在於，技術團隊在沒有關於整個系統的"互操作性和整合"指導的情況下開發應用程序。或者，團隊花費大量時間開發另一個團隊已經完成的事情。他們可能會開發一種在雲端平台中作為服務隨時可用的功能。

技術路線圖將提供指導，但前提是技術路線圖有與業務層面整合。這是個意思是，業務目標必須與企業的能力保持一致，其次是與企業的技術堆棧保持一致。結合起來，這些應該匯聚成一個可行的策略，告訴團隊使用什麼來構建特定的業務功能。因此，在構建技術路線圖時，我們從業務模型和業務功能開始。業務模型提供了對企業如何運作的洞察力，並轉化為業務功能。

這對映到應用程式功能和功能中資料的使用。應用程式服務於什麼業務功能以及該功能需要什麼資料、何時以及為什麼？最後，完成技術對映。什麼樣的資料庫最適合處理資料？企業需要哪種技術來交付應用程式以及業務功能？在技術路線圖中，這可以與CSP和其他供應商發布的提議相匹配。但是，技術路線圖中必須清楚新功能、版本、產品或服務將如何強化功能。

簡而言之，技術路線圖定義了策略規劃，以使用技術實現特定的業務目標和抱負。技術路線圖不僅包括技術本身，還包括將這些對映到業務功能。我們鼓勵雲端架構師使用template來構建路線圖。下圖提供了一個範例。使用Miro 等工具在構建路線圖時非常有用。

技術路線圖將幫助雲端架構師定義遷移或更新軟體系統的策略，以及規劃新技術或其他專案的開發。但架構師必須記住，起點只有一個，那就是從業務層面開始。

規劃多雲的過渡與轉型

我們在CAF系列文章中一直提到，雲端旅程必定是從商業案例開始。雲端架構師通常會用business->data->application->technology開始設計以符合系統能夠在雲端上運行。至於如何從Business到technology，可以參閱本部落格運用TOGAF ADM的資訊系統架構一文及其相關TOGAF的系列文章。

假設我們的事前評估夠完整，知道現況也知道未來的目標。哪麼中間的差距就是我們要補足的。哪麼其多雲的過渡與轉型計畫就會產生(這一類詳細的步驟可參閱本部落格COBIT的實行一文)。基本上我們可以由上到下分為三個層級:

戰略 — 企業的目標與目的
戰術 — 如合約，SLA等
運作 — Build/Test/Deploy/Operate/Monitor等等

一個過渡與轉型計畫應包括以下項目:

資產清查

我們應該根據整個業務流程來檢視整個環境中所有相關的IT資產。我們根據業務流程來區分重要與不重要的應用程式，通常較不重要的系統會是比較簡單、獨立的，也是較容易先遷移到雲端的。而重要的系統則主導整個計畫，另一個重要主題是我們需要在環境中檢查所有系統交互。什麼系統連接到其他系統？這涉及環境中的網路路由、資料庫使用、存儲、備份和安全設置。最後但同樣重要的是，我們需要確定資產的負責人與操作者。

根據業務計劃評估資產

雲端架構師需要定義目標架構與目標運作模式，這兩個都需要原則才能建立實際的事物出來。而多雲策略與架構也必須必須確保目標平台之間的一致性。這不只關於能避免被鎖定在某一個雲端平台，更重要的是減少在多雲中管理系統的複雜度。以下是在規劃時需要注意的質量屬性:

Reliability
Maintainability
Usability
Portability
Correctness
Efficiency
Security
Testability
Flexibility
Reusability

假若以上的屬性架構師都是考量到的話，哪麼企業就可以從多雲策略得到效益:

最佳解決方案(能對業務有加值效果的)
系統的韌性強化
業務敏捷性

安全

這是必要的配備了，無論是不是多雲。企業都必需注意到這一事項。

成本控制

雖然很多CSP都說用雲端能省錢，但是前提是要能夠駕馭雲端運算並能隨時注意新的技術創新是否能幫企業進行節費。

開始建立多雲環境

在選擇適合企業的CSP之後，接下來我們就應該在各個雲端平台上建立Landing Zone。這包含一些基本項目，包含通訊、政策、資安、監控、BCP與DR、流程與相關人員的培訓等等。企業的系統才可以開始運作在這些特定於相對應系統中的多雲環境。

哪甚麼是Landing zone呢?通常，Landing zone被定義為在公有雲中提供的預配置基本環境，以便它可以開始託管應用程式。 Landing zone是一個通用術語，不過不同的CSP都有不同的名稱和服務來創建Landing zone。第一件事就是要建立網路通訊，以便我們能夠連接到雲端環境中。

第一步建立網路

連結到雲端環境，從最便宜可能也是最不安全的Internet或安全一點的VPN，到最貴但可能也是安全性最高的網路專線都是企業連結到雲端環境中的方式。從傳統的IT來看，我們可以把它視為是從我們的地端機房連到另一個機房(雲端)。從網路的架構來看，其網路分段其實跟傳統的地端機房規劃大概差異不會太大，通常也需要有DMZ。以下是一個使用VPN連結地端與雲端的網路示意圖。

設立Landing Zone

上述我們提及到建立Landing Zone有一些基本工作要做，另外也會啟動一些所需的雲端服務。但是該是應該啟用那些雲端服務呢?我們有一些框架是可以參考的，例如各家CSP的Well-Architected 與 CAF(Cloud Adoption Framework)，這一些都在本部落格都有系列文章介紹。

以下為設立Landing zone的各階段:

Design —
針對 security control, IAM與網路定義基本參數
Deploy —
通常有手動或自動，自動化就是使用各雲端平台的IaC。
Operate —
由於使用多雲環境，企業最好使用一個工具或解決方案來統一設定與管理多雲環境。
Update —
維運之後的Lesson learned的文件應該要去更新Design的文件，以便架構不斷改進並保持一致、記錄和可轉移。

遵循CSP的標準化方法，Landing zone將使企業能夠一致性地管理：

雲端中的資源
存取
監控
成本
治理與安全

當Landing zone完成之後，企業就可以開始進行遷移或佈署系統。

探討系統可以轉型的選項

不論事遷移或開發系統到雲端中，企業有好幾種選擇可以考量。

從單體式(monolith)到微服務

絕大部分的公司為了快速跟上業務的變化其實欠了不少技術債。這些單體式系統通常是耦合(tightly coupled)與佈署於一套環境中。這些單體式環境遇到更新或升級都會遭遇重大的停機事件，並且其可擴充性很差(通常只能scale up 不能scale out)。所以很多企業通常會選擇微服務作為解方，因為它是去耦合(loosely coupled)。

將單體系統轉換為微服務是一個非常繁瑣的過程。首先，必須回答的問題是：值得嗎？付出的人力、時間和成本是否與轉型的效益相稱？最好讓應用程式保持原樣，也許將其直接遷移到雲端，然後使用微服務架構並行設計、構建和部署替代應用程式。系統轉型的策略，多家CSP都有提出來:

Rehost
Replatform
Repurchase
Refactor
Rearchitecte
Rebuild
Retire
Retain

要將單體式系統轉換為微服務，通常都需要rearchitect與refactor。這通常需要花費大量的人力、時間與成本。尤其愈複雜的系統越消耗企業的資源。

從VM到無伺服器(Serverless)

在雲端上運作VM是大部分企業一開始會用到的選項，但是狀況在於運作在VM的應用程式不是全年365都把該VM的資源用滿，有浪費錢的嫌疑。甚至有些服務只是短暫存在的：一旦服務不再運行，就會迅速scale up and down。特別是在微服務中，這正在成為普遍做法。在event-based的架構中，服務由終端使用者的操作觸發，並在操作執行後立即停止。 VM對於這些event-nased來說太大了。

但使用無伺服器的最大優勢在於它可以幫助企業成為event-driven。對於微服務，有一些軟體組件專注於一項特定任務，例如支付或訂單。這些是遵循流程的交易。無伺服器函數在流程中各自執行自己的步驟，僅消耗函數在流程中執行特定任務所需的資源。

容器與多雲容器編排(orchestration)

無伺服器也不是適用所有的應用程式，有些就是要用容器或是VM。但是大部分上雲的企業還是努力擺脫在雲端上使用VM，因為VM的費用在雲端上是最貴的。

而容器是一種以更有效的方式使用基礎架構來託管系統的方法。容器與Container engine一起作業，而這個Engine需要OS。容器共享VM的 OS Kernel以及binaries與libraries。這使得容器本身非常輕量，並且比 VM 快得多(理論上)。當圍繞微服務構建架構時，容器是一個很好的解決方案。

因為容器是去耦合的，所以整個系統在升級時的衝擊可以非常小，大都不需要停機(也理論上的)。下圖為區別容器與VM的不同之處。

這時我們可以看到在架構容器時會有一個很重要的東西可以輔助整個維服務運作：Sidecar。 Sidecar 容器與主要容器一起運作，其中包含應用程式的特定功能。如果我們只想更改該功能(例如加減乘除)而不想更改其他非功能性的功能，我們可以使用 sidecar 容器。 sidecar 容器包含不應更改的功能，而主要容器中的功能已更新。下圖顯示了Sidecar架構的一個簡單範例：

哪麼這一類的容器管理平台就數最歡迎的Kubernetes(K8S)了。更多的K8S介紹可以參閱本部落格K8S的系列文章。但如同我們在K8S的系列文章提到過的，從底層自建整個K8S平台並且對其進行管理可能需要耗費大量的人力，甚至我們的人員也可能誤解其原理做出不正確的管理。

幸運的是，各家CSP都有託管的K8S平台可供企業使用，如AWS的EKS、GCP的GKE與Azure的AKS。但除了公有雲，建立地端機房的託管式K8S好幾家供應商也有(但還是需要管理其硬體)，如VMware的Tanzu、NetApp Astra。

Infrastructure的持續一致性

在雲端中運作微服務、無賜服器、容器以及VM，最大的挑戰是保持基礎設施的一致性。哪我們要如何實現這一目標的呢?。

保持基礎設施一致性的最佳方法是使用模板(template)。這樣的模板包含基礎設施組件應遵守的所有配置。我們可以以VM為例。可以直接從CSP的marketplace部署VM。通常，公司對服務器有特定的要求：必須使用特定的設置來配置它們，這些設置定義了伺服器的OS配置、存取等級和安全參數。首先，我們不想每次註冊服務器時都手動執行此操作，其次，如果我們手動執行，很可能會出現偏差。因此，我們使用模板來自動註冊所需的服務器狀態，並使所有服務器與策略保持一致。

這一個方法就是IaC(Infrastructure as a Code)。如Terraform、Bicep或是AWS的CloudFormation。

總結

本文的目的是提供對不同雲端概念的一些共同理解，以及企業如何利用這些概念來獲得最佳解決方案進而改善業務或創造新的業務。開始多雲之旅需要適當的準備，以充分利用雲端技術，包括微服務、容器和無伺服器等技術。這些雲端技術如果設計或管理不當可能變得非常複雜。我們必須通過降低複雜性並實現運作在雲端上系統的有效管理來確保保持平台的一致性。