使用TOGAF來建立與管理雲端架構
在多雲環境的雲端服務設計與多雲環境的網路連接設計文章中，我們認識到不同的雲端技術策略，討論了IAM模型，並開始起草多雲網路拓撲和服務模型，包括治理原則( 我們從哪裡開始？又要去到哪邊？)。此刻起，我們將要為企業在多雲架構中管理我們的 IT 環境。 成功管理這個新的數位資產意味著我們必須非常嚴格地維護企業架構。 因此，本文的內容都在講述關於維護和保護多雲架構。
我們將介紹使用 TOGAF(The Open Group Architecture)框架來建立企業的多雲架構方法(還不知道甚麼是TGGAF的人，可以參考本部落格TOGAF框架標準介紹 一文 )。我們將討論如何為資安、資料和應用程式等各個領域定義架構原則。 我們還將討論如何在不同階段進行平移和建立架構。 最後，我們將討論驗證架構的必要性以及我們如何管理它。
本文將討論以下主題：
- 定義多雲的架構原則
- 建立架構工件(artifacts) — 至於什麼是工件可參閱本部格TOGAF標準的詞彙表一文
- 在多雲架構下作業並避免掉入陷阱
- 將變更管理與驗證變為我們的基石
- 驗證架構
定義多雲的TOGAF架構原則
我們將從企業架構的角度開始。 正如我們所見，TOGAF 中的 ADM(Application Development Management) 週期是一個具指導性且被廣泛接受的框架，用於起始任何企業架構。 在運用多雲策略加速企業的業務文章中，我們了解到架構的生產週期始於企業的業務，但在我們真正定義ADM業務架構(Business Architecture)之前還有兩個步驟：準備階段(Preliminary phase)，選擇架構框架(Architecture Framework)與架構原則(Architecture Principle)。 然後將這些準備階段的產出投入到架構願景(Architecture Vision)，如下圖所示：
ADM的準備階段產出是架構原則；也就是說，我們完成架構的指導。原則可以有很多，所以我們要做的第一件事就是建立與我們的業務一致的一套原則。要記住的最重要的事情是原則應該使我們的業務目標能夠實現。只要在這方面非常清楚：上雲不是一個業務目標，像Cloud-first一樣不是業務策略。這些充其量只是的技術宣告，如此而已。但架構原則應該做得更多：它們必須支持正在做出的架構決策，為了做出正確的決策，我們架構原則需要有以下特點:
- 容易理解(Understandability)
- 穩健性(Robustness)
- 完整性(Completeness)
- 一致性(Consistency)
- 穩定性(Stability)
更多的TOGAF ADM架構原則請參考本部落格TOGAF — ADM的指南與技術一文。
當企業認為雲端可能是託管業務功能和應用程式的良好平台時，最常用的說法是靈活性、敏捷性和成本效益。成本效益已經非常模糊：成本效益是什麼意思？通常，這意味著企業希望將系統遷移到雲端平台比將它們保留在地端機房更便宜。不過要每個企業的每個系統而定，無法一概而論。但雲端的財務/成本管理卻是可控的，詳情可以參閱本部落格關於FinOps的系列裝。簡而言之，我們的架構原則都應該受到挑戰：
- 這個原則有支援企業的業務目標嗎?
- 原則是否明確，而不能有不同的解釋?
- 原則是否引領出一個有清楚定義的方案?
定義原則的一些建議如下：
- 企業的業務(ADM Phase A)
- 安全與合規(ADM Preliminary Phase)
- 資料原則(ADM Phase C)
- 應用程式原則(ADM Phase C)
- 基礎設施與技術原則(ADM Phase D)
- 企業流程(ADM Phase B)
業務原則
業務原則從業務單位開始，業務單位會制定他們的目標和戰略。 這些固定的業務任務宣告，會描述他們想要在短期和長期內實現的目標。 而這可能涉及各種各樣的主題，可能是：
- 對客戶的快速回應
- 新產品的快速部署(time to market)
- 產品/服務的品質改良
- 得到更多的訂單數
與幾乎所有事情一樣，這些目標應該是 SMART，即具體(specific)、可衡量(measurable)、可實現(attainable)、相關(relevant)和及時(timely)的縮寫。 例如，SMART 制定的目標可以是“在 七月一號 的台灣地區發布產品 Y的客服網站”。 它的範圍僅限於定義區域中的特定產品的特定日期。 這可以作為一個 SMART 目標來衡量。
回到 TOGAF，這是在 ADM Phase B: Business Architecture執行的活動； 即該階段是我們完成業務架構的架構開發方法。 這種效益是整個企業都使用一種語言來執行企業架構，不管是業務單位或技術單位都不會有雞同鴨講的情況。 在這種情況下，TOGAF 通常被視為標準。 業務原則驅動著企業制定的業務目標和戰略決策。 因此，這些架構原則是任何後續架構階段的先決條件。
安全與合規
儘管安全性和合規性是任何架構的重要的關注點，但這個領域的原則可能相當簡單。由於這些原則在架構中的每個方面都非常重要，因此重要性僅次於業務原則。
如今，我們經常談論設計上的零信任和安全性。這些可以是原則，但它們是什麼意思？零信任就是：遵守零信任的組織不會信任其網路和平台中的任何東西。每個設備、應用程式或用戶都是不被信任的。平台是被整個細部切分的，以避免設備、應用程式和使用者都放在平台上的任何同一個位置或網路中；它們被嚴格控制。這裡的陷阱是認為零信任就只跟技術有關。但它不是。零信任首先是一種業務原則，從不同的角度看待安全性：零信任是假設一個組織受到了攻擊，剩下的問題: 哪傷害是甚麼?。這也是 MITRE ATT&CK 等框架所採取的角度。
設計的安全性意味著環境中的每個組件都設計為不受該架構中其他組件的影響：安全性是內建的。這意味著 平台和系統（包括網路設備）本身是得到強化，並且通過加密或hash來保護代碼免受破壞。這也意味著架構本身已經是微分段(micro-segmented)的，並且已經應用了安全框架。一個常用框架的例子是 CIS(Center for Internet Security)。 CIS 包含 18個關鍵安全控制項，涵蓋對 IT stack中不同層面的各種攻擊。正如 CIS 自己正確陳述的那樣，它不是一個一刀切(one size fits all)的標準。一個企業需要分析應該實施什麼 控制項以及在什麼程度上實施。
例如，資料保護，即第三個控制項。這個控制項建議對傳輸中的資料(data in transit)和靜態資料(data at rest)進行加密。不過CIS 並不代表應該使用哪種類型的 HSM (Hardware Security Modules)，甚至是哪種等級的加密。CIS說到一個企業應該使用加密並使用安全保存的加密密鑰來保護它，應該由架構師有整體業務認知與技術判斷後決定應該使用什麼等級和什麼類型的加密。
在合規原則方面，必須明確企業必須遵守哪些國家甚至地區的法律和行業監管機構。這包括隱私方面的法律法規，這與資料的存儲和使用直接相關。
一個原則的例子是架構必須符合 GDPR。雖然就只有這一個詞，但在保護存儲資料的環境（the systems of record）以及如何訪問這些資料（system of engagement）方面意義重大。由這一原則產生的技術方式將不同於保護資料庫、加密資料以及通過authentication和authorization對該資料的訪問。在多雲中，這可能比地端機房更具挑戰性。使用不同的雲端運算和 PaaS 和 SaaS 解決方案，我們的資料可能散落在不同地方的不同機器設備。
資料原則
正如我們之前提到的，這就是在多雲環境中真正令人興奮和具有挑戰性的地方。 最常用的資料原則與資料的機密性有關，並由此保護資料。 我們在本文前面簡要介紹了兩個在雲端環境中非常普遍的重要技術術語:
- System of record
它是資料管理或資料存儲系統。 在雲端中，我們有一大堆的資料庫，但由於雲端平台的可擴展性，我們現在可以部署由連接數以千計的資料源的多個資料庫組成的巨大資料存儲。 公有雲非常適合託管所謂的資料湖(data lakes)。 - System of engagement
它是用於收集或存取資料的系統。 這可以包括各種系統：如電子郵件。 協作平台和 CMS(content management systems)，還有apps，甚至IoT。
下面為system of record和system of engagement拓撲圖的high-level overview，其中 ERP、CMS 和 CRM 系統被作為system of record的範例。
我們已經提到過資料湖，它是主要保存原始資料的大型資料存儲。 為了處理這些資料，資料科學家需要定義精確的資料集來執行分析。 AWS、Azure 和 GCP 都提供了支援這種功能的產品，例如 Azure 中的 Data Factory 和 Databricks，AWS 中的 EMR 和 Athena，以及 GCP的BigQuery。這些都是在TOGAF Solutions Continuum中的SBB(Solution Building Block)。
大數據和資料分析對於企業在成為資料驅動的過程中變得越來越重要：在任何活動或業務決策都是，就此而言，都是由實際資料驅動的。 由於雲端可以保存PB等級以上的資料，並且系統需要能夠快速分析這些資料以觸發這些作業，因此越來越多的雲端架構師認為模型中將會有一個新的層面。 這種驅動的解決方案，例如 Azure 中的 Azure ML、AWS 中的 Sagemaker 和 GCP 中的 Vertex AI。額外的層面 — — 智慧系統 (system of intelligence) — — 就會介於systems of engagement與systems of record之間(如下圖)：
這裡需要說明：record或engagement system並沒有說明底層資源的類型。 它可以是任何東西，從實體機器到虛擬機、容器，甚至是一個函數。 record或engagement system僅涉及特定資源的功能。而這裡沒有說明任何特定的產品則屬於TOGAF Architecture Continuum中的ABB(Architecture Building Block)
應用程式原則
資料不是獨立存在的。如果我們再看一下 TOGAF，我們會看到資料和應用程式被分組到Phase C: Information System Architecture。在現代應用程式中，應用程式的主要原則之一是這些應用程是具有資料驅動的方法，遵循 Steven Spewak 的企業架構規劃的建議。 這本書於1992年出版，但他的方法仍然適用，甚至可能更多的適用於在多雲環境中。
在 Spewak 的工作中也提到，企業的業務任務是任何架構中最重要的驅動力。該任務是資料驅動的：企業根據資料做出決策，因此，資料要相關，但也需要存取和使用。後面的這些原則與向企業披露資料的應用程式有關。換句話說，應用程式需要有保護資料的能力與質量，使資料是可存取，並確保資料可以使用。當然，可能並且存在關於例如資料的可存取性的爭論會有很多。應用程式架構的唯一相關原則是它使資料是可存取。對誰以及在什麼條件下是安全原則。
在多雲中，存儲資料的變化，也是格式應用的變化。 Spewak 在九十年代初編寫了他的方法論，甚至在網際網路真正變得龐大和生活化之前，我們還沒有看到我們今天稱之為雲端運算的東西。如今，現代應用程式通常不是單體式或client-server-based，儘管企業仍然可以擁有大量具有舊有架構的應用程式基礎。雲原生應用程式則定義了角色和功能，並建立在基於代碼的模塊化和使用微服務的原則之上。這些應用程式使用 API 與其他應用程式溝通，甚至使用呼叫其他應用程式中特定函數的觸發器。這些應用程式甚至不必運作在相同的平台；它們可以託管在任何地方。一些架構師傾向於認為運作在mainframe上的單體式的應用程式很複雜，因此將其作為一個guideline來確定多雲中的複雜應用程式的複雜程度。
然而，許多應用程式的架構原則同樣有效。技術可能會發生變化，但應用程式的功能仍然是在呈現資料、使其可存取並確保資料可用於支援企業的業務。
現代應用程式原則正在使用雲原生技術的具體特徵。現代應用程式應該支援可移植性，使用開放標準獨立於平台，支持互操作性(interoperability)和可擴展性。應用程式應該能讓使用者隨時隨地的操作應用。
一個關鍵問題是應用程式的需求幾乎每天都在變動：使用者對應用程式的需求越來越多，因此必須以極其敏捷的方式設計它們，以便我們可以在開發流程中以極快的速度適應變化。 雲端技術確實支援這一點：可以調整代碼。 但這確實要求應用程式經過精心設計和有文件記錄，包括在維運手冊。
基礎設施與技術原則
最後，我們了解真正的技術：機器、電線、螺絲和螺母。 在這裡，我們講的是虛擬螺絲和螺母。 由於資料存儲在我們的多雲環境中的許多地方，並且應用程式被構建成雲原生，因此底層基礎架構需要支援這一點。 這是 TOGAF Phase D: Technology Architecture，在架構開發中，我們建立目標技術架構，包括資料存儲和系統的相互依賴性。 在多雲環境中，這從起草landing zone開始：我們的應用程式和資料將要降落的平台。 正如我們在多雲環境的網路連接設計文章中看到的那樣。因此，網路架構是需要在基礎設施和技術架構中詳細說明的第一個組件。
其中一個陷阱是架構師建立了又臭又長的清單，其中包含基礎設施和技術應遵循的原則，一直到定義將用作技術標準的產品。但是，包含產品的目錄是產品組合的一部分。原則應該是通用的、指導性的，而不是約束性的。換句話說，技術標準和產品清單不是原則。一般原則可能是關於尖端技術的：一種新的、非專利的、實驗性的技術，當部署在環境中時會帶來風險，因為它仍然不穩定和不可靠。並且可能與起企業的現行甚至未來的業務無關。
基礎設施的其他重要原則可能是它應該是可擴展的（scale up/down, out/in），並且它必須允許微分段(micro-segmentation)。我們已經討論了 12因子應用程式，它對基礎設施提出了具體要求。這些可以作為原則。 12 因應用程式 的原則在 2005 年就已經制定，但正如我們在運用多雲策略加速企業的業務文中已經得出的結論，它們仍然非常準確和相關。
12因子應用程式 對基礎設施設定了以下三大要求：
- 此應用程式可在不同平台之間轉移，這意味著該應用程式與跑在什麼平台上無關，並且不依賴於系統設置的特定服務器。
- 應用程式的開發階段和生產階段之間幾乎沒有區別，因此可以實現持續的開發和部署。 部署應用程式的平台應該支援這一點（這意味著一切基本上都是code-based的）。
- 此應用程式支援在無需對應用程式架構進行重大變更的情況下進行scaling up。
流程原則
最後一組原則與流程有關，這是在ADM準備階段的Architecture Capability的其中一部份。這與 ITSM 流程無關，而是與多雲中的部署和自動化流程有關。多雲的原則之一是我們將盡可能多地自動化(但不會是全部)。這意味著我們必須將通常手動執行的所有任務定義為自動化工作流程。如果我們有一個純代碼原則，那麼我們可以隨後設置一個原則，說明我們必須從代碼庫或master branch 作業。如果我們分叉代碼並且我們必須對其進行更改，那麼原則是，只有在與驗收和生產完全分離的環境中進行測試時，才能將更改後的代碼提交回master branch。這與我們環境的生命週期過程有關。
因此，這裡的流程確實更關注我們的作業方式。今天，很多公司都致力於敏捷和 DevOps。如果這是已定義的作業方式，則應將其列為原則；例如，開發是通過 大規模敏捷開發(Scaled Agile Framework) 或 Spotify 模型完成的。遵循這一原則，公司還應該定義團隊、他們的工作量，以及如何計劃功能、產品待辦事項等。這些都與TOGAF的Architecture Capability有關。
與所有原則一樣，最大的陷阱是使原則過於複雜。特別是對於流程，真正堅持描述原則而不是實際流程非常重要。
架構的平移與轉型
我們已經做了很多工作。最終，這一切都應該構成一個架構願景(ADM Phase A的產出)：在這一階段我們會有現行架構與最終架構。架構還應該提供路線圖(roadmap)；也就是說，我們將如何達到最終狀態的指南。架構路線圖提供了企業如何從現行架構移動到最終架構，在這過程中可能會有好幾個過渡架構，而每一個過渡架構階段也需要展現出它的業務價值。架構路線圖組件在TOGAF ADM的Phase B/C/D逐步發展，並根據這些組件在Phase E/F中完成。
假設我們的最終狀態是完全適應雲端。這意味著企業在雲端中擁有所有的 IT 系統、資料和應用程式。一切都是code-based和自動化的，通過 CI/CD 流水線進行部署和管理。我們採用了雲原生技術，例如容器和serverless功能。在運用多雲策略加速企業的業務文章中，我們將其定義為動態階段，但這是一個技術階段。動態階段可以是我們架構最終狀態的一部分。但是，我們需要絕對確定這種動態技術確實符合業務需求，並且我們已準備好在最終狀態下運行此環境。我們將這個最終狀態稱為 FMO(Future Mode of Operation)。
我們如何到達這個 FMO？從當前情況、CMO(Current Mode of Operation) 或 PMO(Present mode of operation) 開始。對現有環境進行適當評估了解企業在其 IT 環境中擁有的基礎設施、網路、資料和應用程式至關重要。 從那裡，我們可以開始設計向 FMO 的過渡和轉型。 如果我們將本節開頭討論的 Spewak 方法與 CMO-FMO 規劃結合起來，模型就會如下所示：
如果我們不更改應用程式中的任何內容，而只是使用 IaaS 或bare-metal的方式遷移到公有雲，那麼我們可以討論平移。平移只是意味著我們移動工作負載，但在技術或服務方面我們根本沒有改變任何東西。但是，我們也沒有使用雲端技術來使我們的環境更加敏捷、靈活或更具成本效益。如果我們想實現這一點，我們需要進行架構轉型：我們需要改變資料和應用程式下的技術。這是一項需要通過架構來處理的工作。我們為什麼要改變？我們在改變什麼？我們如何改變應用程式？這些都必須在ADM Preliminary Phaseu有非常明確的定義。此外，如果事情沒有按計劃進行，我們如何退回上一步？也就是說，我們的fallback 解決方案是什麼？這也必須在TOGAF的風險管理(Risk Management)有明確的說明與定義。
在平移和轉型方面需要一場討論或辯論。如前所述，過渡意味著我們不會改變底層技術和服務。我們只是將環境從 A 移動到 B — — 就這樣。但是，當我們將環境轉移到公有雲時，情況是否如此？將應用程式遷移到 AWS、Azure 或 GCP 總是意味著我們正在改變一些東西：無論是底層平台還是服務。
通過將應用程式遷移到主要的公有雲，企業的服務幾乎肯定會發生變化。我們正在向我們的環境引入第三方：公有雲平台。因此，我們正在為我們IT的整體面貌引入一項協議。該協議包含關於我們的應用程式將如何託管在公共有中的條款和條件。這是在架構中應該在明確的變更管理流程(ADM Phase H)中處理的事情。
建立架構工件(artifacts)
基本上，涵蓋架構文件中的層次結構始於企業架構。 這是第一個所謂的架構工件。 企業架構會包含ABB與SBB，SBB涵蓋了 IT 環境中的各種組件。 我們將在以下部分更詳細地探討這一點。
建立業務願景
建立業務願景可能需要數年時間，但它仍然是架構中的一個主要工件。 它列出了企業想要實現的目標。 這應該是一個長期的展望，因為它將推動架構決策。 儘管雲端環境支援服務的敏捷部署，但它永遠不應該成為臨時的。
業務願景側重於財務、服務/產品質量、業務可持續性以及最重要的是其目標業務和市場層面的潛在增長方面的長期目標。 業務願景是企業架構的input。 它是唯一不會由架構師產成的文件，儘管企業架構可能是一個重要的利害關係人，它決定了他們對願景的看法。 畢竟，願景必須是現實的和可得的。 換句話說，架構必須能夠支持願景並幫助實現其目標．
企業架構
企業架構是企業架構師編寫的第一個文件。 通常，這是由企業或業務架構師的架構團隊建立的可交付成果。 企業架構師將與領域架構師一起作業。 後者也可以是雲端架構師，或專門從事雲原生開發的架構師。 企業架構描述了業務結構和流程，並將它們對應到資訊的最終和使用。 本質上，企業架構在業務和 IT 之間架起了一座橋樑。
原則目錄
這份文件列出了必須應用於將要開發的任何架構的所有架構原則。 我們在本文的第一部分(定義多雲的架構原則)詳細討論了這一點。 原則是按每個架構領域組合成的。
需求目錄
這份文件列出了企業為實現其目標而發布的所有需求，因為這些需求已在企業願景中列出。 從業務願景到需求目錄是一個漫長的過程，因此在建立企業架構和原則目錄方面有一些中間步驟。 從那裡開始，業務功能必須轉化為重新分級使用資料和應用程式功能的需求。 由於在此階段並非所有內容都已詳細了解，因此該目錄還需包含假設和限制。 最後，目錄包含代表業務需求解決方案的構建區塊清單。
ABB(Architecture Building Block)
ABB是描述功能性的說明來滿足需求的理由。 通常，每個架構領域都會 建立ABB：資料、應用程式和技術。 雲端概念是每個領域的一部分。 網路、運算和存儲是適合技術設計的概念。 資料邏輯和資料流是資料設計的一部分。 應用程式功能必須在應用設計中描述。
SBB(Solution Building Block)
這個包含每個構建區塊的詳細資訊。資料的底層設計包括資料安全和資料傳輸。應用程式設計包含必要的軟體工程圖和分佈模式。技術設計包含核心和邊界（網路和安全）的詳細資訊，包括使用的端口(port)清單； IP規劃與通訊協議；平台模式和分區段處理單元（VM、容器等）；存儲部門；interface等。
這裡需要注意的一點是，在多雲環境的雲端服務設計文章中，我們將一切都作為代碼來作業。那麼，將所有內容都寫在文件中並存放在某個櫃子或抽屜中，再也不用拿出來看是否有意義？儘管如此，記錄我們的架構是非常重要的(因為架構不是永遠不變的)，但我們也可以將我們的文件放在 wiki頁面中，這些文件可以很容易的搜索並直接連接到可以使用甚至開發的相關代碼。在當今多雲、DevOps 和 CI/CD 流水線的世界中，這將是首選的作業方式。
在 DevOps 流水線中作業並在 wiki頁面 中擁有文件強制執行建立與維護這些工件是永不停止的活動。代碼和 wiki頁面 可以輕鬆維護，並且比厚重的實體文件更靈活。請注意，工件將不斷更新。這是連續架構的基本原則。連續架構不專注於解決方案，是有充分理由的。
在多雲中，已經有數以千計的解決方案和解決方案組件可用，還有數以萬計的解決方案正在開發中。持續架構關注架構本身的質量，並描述如何設計、構建、測試和部署解決方案，就像在 DevOps流水線中一樣。除此之外，它非常關注架構的持續驗證，這是我們將在本文最後一節探討的內容。
在多雲架構下作業並避免掉入陷阱
到目前為止，我們已經了解了架構的不同組件以及它應該實現的目標。 我們一直在討論架構和服務設計的條件與先決要件，所有這些都源於業務需求。 接下來，我們探討了雲端環境架構的基本原理。 現在，下一階段是真正開始將架構組合在一起。 最大的問題是，我們從哪裡開始？ 最簡單的答案可能是，打開 Visio或 draw.io並為我們將使用的任一雲端平台載入模板。但這不是我們建立良好架構的方式 — — 我們需要多一些思考。
假設我們對需求有清晰的理解(通常很多人會做不到)並且我們已經同意了原則，我們將執行五個階段來建立我們的多雲架構。
階段一：安全架構
正如我們之前提到的，關於設計的安全性和設計的隱私存在很多爭論。 此類應用程式的設計應遵循設計安全和設計隱私的原則。 與往常一樣，最大的問題是我們應該保護什麼以及保護到什麼程度？ 或者，也許更準確的表述是，我們必須多深入？ 在架構設計中，應該始終在最低等級的解決方式。 首先要清楚地了解我們必須保護什麼（資料）以及我們如何保護它。
在安全架構中，我們專注於”資料保護”。 畢竟，資料是我們多雲環境中最重要的資產。 這個架構應該有一個目標：保護資料的完整性。 開始考量安全架構的最佳方式是從可能的威脅角度進行思考。 我們如何保護資料，我們如何防止應用程式被破壞，以及在安全策略、監控和隨之而來的告警的流程是什麼？ 後者是 SecOps(Security Operation) 的主題。
為安全設計架構並非易事。 我們將不得不探討許多不同的層面，並決定每一層面應該採取什麼樣的保護措施，以及必須如何實施這些措施。 這些層面如下：
- 陣地(perimeter):我們環境的外部邊界，這是第一個訪問層。 通常，這也是第一層防禦。 DDoS 攻擊在環境中充斥著requests以致最終服務崩潰，這些攻擊通常針對這一層。
- 網路： Switches、router、routing table、peering、vNet、project還有VLANs的micro-segmentation等等。 通常，這些都是作為雲端平台中的託管服務，但即便如此，我們也需要考慮強化它們。 這意味著在沒有監控和明確定義的使用情況下，沒有任何端口或路由處於打開狀態(也就是白名單管理)。 這通常適用於允許流量進出雲端網路的路由表、peering、security group和其他service gateway。 如果端口或路由無意中在我們的監視下保持開放狀態，它就會允許攻擊通過這些漏洞進入。 通常，這些是所謂的暴力攻擊：攻擊者會開始攻擊我們的大門 — — router、switches、firewall — — 掃描設備上的所有端口，直到他們找到一扇敞開的門。
- 運算：虛擬機與系統的強化。 必須保護虛擬機免受病毒和其他惡意軟體的侵害。
- 應用程式：保護應用程式和應用程式內的不同組件。 例如，考量一個 Web 部件和作業角色。 這些組件形成一個應用程式，但是當我們使用micro-segmentation和微服務時，安全原則是對每個組件都有保護措施。
- 資料：資料本身、資料存取、加密和加密金鑰的存儲。 這是我們最大的資產。 它是我們架構中最深的一層，但它始終是攻擊者瞄準的目標。 如果攻擊者成功地發現了其他防禦層的漏洞，他們最終將拿到資料 。 無論我們如何設置防禦層，我們都需要採取保護措施來保護資料的完整性。
這些無關乎工具，例如 Azure security center或我們可以用來在雲端中設置防禦層的任何其他工具。 工具可以滿足團隊需求。 用於滿足安全要求的工具可能因每家 CSP而異，但只要滿足要求就夠了。 此階段的架構可能會導致某個工具應遵守的一組要求，但首先要考慮保護層以及可以在這些不同層執行的可能攻擊。
階段二：架構的可擴充性
公有雲的殺手級應用是可擴展性。而這是地端機房做不到的，因為地端機房的機器是固定的不可能說加就馬上有，而現在公有雲中的量能是我們觸手可及。但可擴展性不止於此：它關乎公有雲中的整體的敏捷性和靈活性，以及在業務需求有需要時進行scale out/in、scale up/down。讓我們探討一下這些術語的含義。
Scale out也稱為horizontal scaling。當我們擴展一個環境時，我們通常會將諸如虛擬機之類的系統安裝到該環境中。在scale up（或稱vertical scaling）中，我們向系統添加資源，通常是 CPU、memory或disks。顯然，當我們可以scale out和scale up時，我們也可以朝相反的方向縮減系統。由於我們為在公有雲中是有使用才付費(on-demand resource)，成本會立即下降，如果我們投資於傳統的地端機房實體機，情況就不會如此。我們可以降低這些實體機的使用率，但這不會降低該機器的成本，因為它完全是資本支出(CapEX)。
公有雲提供各種部署模型。 Pay-as-you-go就是這樣一種部署模式。 AWS、Azure 和 GCP 也提供 RI，如果企業使用這些insatce的時間更長，例如 1 年或 3 年。 CSP 為 RI 提供折扣，但“缺點”是企業必須承諾在這段時間內使用這些 RI，就算沒用到錢也要照付。 除非企業支付終止費，或者是轉換其它的insatnce type，否則就算scale in or down也省不到錢。
可擴展架構的典型領域是虛擬機、資料庫和資料存儲，但也應考慮網路和資安設備。 例如，如果擴大或擴大環境的業務需求增加，通常吞吐量也會增加。 這對地端交換機和防火牆等網絡設備有影響(如果我們的環境是混合雲)：它們也應該擴展。 但是，我們應該首先使用雲端平台的native services來避免擴展問題。
為了可擴展性，我們應該在架構中包含以下內容：
定義擴展單元：
這涉及可擴展性模式。 我們必須意識到的一件事是擴展會產生的影響。 在 VM 上進行scale out會影響這些機器使用的擴展，從而影響存儲的使用。
但是架構必須考慮一些更重要的方面：“應用程式可以處理擴展嗎？” 或者我們是否必須重新架構應用程序，以便底層資源可以scale out、up或down，而不會影響應用程式的功能，尤其是效能？ 我們的備份解決方案是否適合擴展？
定義縮放單元很重要。 縮放單元可以是 VM，包括memory和disk、DB instance、storage account和storage units（例如 blob 或buckets）。 我們必須設計這些單元如何擴展以及啟動擴展活動的觸發器是什麼。
允許自動擴展：
雲端運算中的基本原則之一是我們盡可能地自動化。如果我們在定義縮放單元方面做得很好，那麼下一步就是決定我們是否允許對這些單元進行自動縮放，或者允許自動過程能動態地向我們的環境添加或撤銷資源。首先，應用程式架構首先必須能夠支援擴展。自動縮放增加了一個額外的維度。當涉及到自動縮放時，以下方面很重要：
— 執行自動縮放過程的觸發器。
— 自動縮放的閾值(thresholds)，意味著資源可以scale out/up or down到什麼等級。 我們需要記住，企業必須非常了解相關成本。
擴展的一項具體挑戰是監控。所有資產都存儲在 CMDB 中。除非有native API 可以近乎即時的將這些輸入 到CMDB，否則管理員不會立即看到自動縮放需要額外的資源。
分區(partitioning):
可擴展性架構的一部分是分區，尤其是在大型環境中。 通過將應用程式和資料分成多個分區，控制擴展和管理scale set變得更加容易，並防止大型環境出現資源爭用。 如果應用程式組件使用相同的擴展技術，則可能會出現資源爭用，但由於設置的閾值，資源會受到限制，但這通常是為了控制成本，因為公有雲的可用容量總是比我們很想得大多。
階段三：可用性(availability)的架構
AWS、Azure 和 GCP 等平台是隨時可以使用的。由於這些平台區域是覆蓋全球的，我們可以放心，該平台將始終可用。好吧，這些平台絕對有很高很高的可用性，但它們確實會出現中斷，這種情況很少見，但確實會發生，一但發生就可能海嘯等級的。企業必須問自己的一個問題是他們是否可以承受這種風險，或者減輕這種風險的成本是多少，以及企業是否願意投資於這種減輕風險。這確實是最高等級的業務決策。這一切都與企業的BCP有關。
讓我們假設雲端平台的可用性是特定的。在這裡，我們仍然需要考慮部署在該平台上的系統的可用性。可用性需求也從業務需求中逐漸萌芽。根據經驗，這需要時間來討論。如果你問一家公司的CFO，業務中最關鍵的系統是什麼，他們很可能會說是財務系統。但如果他或她是一家製造汽車的公司的CFO，那麼最關鍵的系統可能是需要將汽車組裝在一起的生產系統。如果這些系統停止，業務就會停止。如果財務系統掛掉，CFO可能無法獲得財務報表，但這不會立即停止生產組裝過程。儘管如此，CFO仍然是決定哪些關鍵系統需要特定架構的可用性的主要利害關係人。
Availability是關於accessibility、retention和recovery。 當我們為可用性進行架構設計時，我們必須在不同的層次上這樣做。 最常見的是compute layer、application layer和data layer。 但是只為這些層次的其中之一設計可用性是沒有意義的。 如果 VM 發生故障，應用程式和資料將無法訪問，這意味著它們將無法使用。
換句話說，我們需要從最高的stack設計可用性，從應用程式到基礎設施。 如果一個應用程式需要有 99.9% 的可用性，這意味著底層基礎設施。 需要有更高的可用性。 底層基礎設施包括整個tech stack：compute、storage和network。
一個好的可用性設計可以應對每個組件中的故障，同時確保應用程式(最上層的stack)可以在與業務及其最終使用者商定的可用性下運行。
但是，故障確實會發生，因此我們需要能夠回復系統。 回復有兩個參數：
RTO:這是企業業務能忍受的對大的服務停止時間．
RPO:這是企業業務能忍受的對大的資料損失時間．
在設計備份、資料保留和回復解決方案時，RTO 和 RPO 很重要。 如果企業需要RPO是30分鐘，這意味著我們必須每30分鐘備份一次。 可用於此的技術是快照或增量備份。 每30分鐘進行一次完整備份會在系統上產生過多的負載，而且這意味著企業需要大量可用的備份存儲。
企業確定哪些環境是關鍵系統並且需要一個有大量處理能力的系統備份解決方案是很重要的。 通常，此類環境中的資料也需要存儲更長的時間。 公有雲 的儲存是可以無限擴展的，但需要配置，我們需要意識到它會顯著增加成本(視狀況)。
還有一點需要注意的是，只有當我們確定可以回復資料時，備份的資料才有意義。 因此，請確保我們的備份和回復程序是經常被測試的 — — 即使在公有雲中也是如此。
階段四：可操作性(operability)的架構
這部分架構首先涵蓋了自動化，但也包括監控和日誌記錄。監控的一個關鍵決定不是我們將使用什麼監控工具，而是我們必須監控什麼以及監控到什麼程度。
在多雲環境中，監控必須是跨平台的，因為我們必須了解我們在多雲環境中部署的整個組件鏈中發生了什麼。這通常被稱為end-to-end的監控：從最終使用者的角度看待系統。這不僅與系統的健康狀況有關，還與系統是否按照它們應該做的事情以及是否沒有錯誤、掛掉或變更有關。它也可能與這些系統的效能更相關。從最終使用者的角度來看，沒有什麼比系統回應緩慢更令人沮喪的了。大辯論從這裡開始：“定義什麼是慢。”
雲端架構師可以決定在 1 秒內有回應的系統是快的，最終使用者可能對此有完全不同的想法。即使他們同意系統的效能和回應速度很慢，下一個問題是如何確定效能下降的原因是什麼。從最終使用者的角度監控環境，一直到基礎設施，通常稱為end-to-end。有真正end-to-end的監控環境，通常是通過整個資料流發送交易並通過確定交易處理速度來測量健康（hearbeat）和效能。請記住，這種類型的監控通常會在我們環境中的各種工件上部署agent。在這種情況下，我們將不得不考慮這些agent在系統上產生了多少overhead，從而佔用了額外的資源，例如 CPU 和memory。agent的佔用空間應盡可能小，同時考慮到我們的系統上無疑會運行更多agent這一事實。
監控系統收集日誌。我們還需要設計這些日誌的流向以及這些必須存儲多長時間。如果系統處於稽核制度之下，則稽核員可以觀看這些日誌。
在可操作性方面，我們需要討論的最後一個主題是自動化。如果我們要討論自動化，那麼我們還應該討論 CI/CD pipeline的架構步驟，這是我們在多雲環境的雲端服務設計中簡要探討的內容。自動化基本上是關於在環境中創造最大效率。不僅在資源的部署上，而且在對這些資源的操作上。
例如，如果不使用虛擬機，則自動關閉它們；像是只在上班時間使用並且可以在晚上暫停的虛擬機。但是，作為架構師，我們必須確保在這些系統上運行的應用程式和資料庫能夠支援這一點。並非所有應用程式，當然也不是在這些系統上運行的資料庫都可以支援這一點。並非所有應用程式，當然也不是所有的資料庫，都可以簡單地進入暫停模式。複雜的資料庫需要時間來構建和同步它們的tables。
階段五：整合的架構
多雲環境中最大的挑戰是整合。 不同平台上的系統還是要互相通訊。 為此，我們需要一個整合架構。 在應用程式架構中常用技術是 API。 顯然，底層基礎設施需要支援這些 API，通常是為了允許某些通信協議和啟用路由，例如允許訊息通過防火牆。
整合架構還需要考慮 API 本身。 他們在哪一層進行通訊以及它是什麼類型的 API — — 私有的、第三方的API 還是Internet來的？ 請注意，大多數 CSP 使用 RESTful API，其中對這些 API 的訪問只能通過 API token或certificate授予。 這些 API 中的大多數的資料格式是 XML 或 JSON 。
整合架構的第一步是定義什麼需要能夠與什麼通訊以及它包括什麼類型的通訊：使用特定規則和觸發器的單向、雙向或多向。在多雲中，以事件驅動的架構越來越普及：只有在滿足某些要求時才執行連接，觸發事件以啟動通訊。這變得越來越流行，因為連接不是一直處於開啟狀態。連接和通訊僅在事件需要時執行。
Apache Kafka是這類領域的領先產品。本質上，Kafka 處理的是即時資料流。它可以導入並導出連接到不同系統的資料饋送。它接收、存儲和發送由事件觸發的資料饋送。在一般狀況下Kafka 系統通常用作message broker和data streaming。 Azure 本身分別為data streaming和應用程式整合提供 Event Hub和 Logic Apps，而 AWS 有 Kinesis 和 GCP則是 Pub/Sub。
更多有關於Kafka/Even Hub/ Kinesis/ Pub and Sub 的深入了解與比較，可參閱此篇文章．
在多雲架構下作業並避免掉入陷阱
跳過架構中的步驟很容易也很誘人。這是在架構下工作的最大陷阱之一。
假設我們有問題，但我們已經知道解決方法是什麼。在先修復，後續討論，或使用臨時解方的旗幟下，實現了很多架構變動。但請記住：沒有什麼比臨時解方更永久的了，尤其是在沒有文件記錄的情況下。如果緊急修復真的是保持業務運轉的唯一方法，那就繼續吧。但是一定要記錄它，當它導致架構發生變化時，評估並決定這是否是我們想要在我們的環境中出現的東西 — — 如果它符合架構 — — 或者我們是否必須設計一個符合架構和架構原則。
另一個陷阱是最新技術。這通常被稱尖端技術：可能是一個很好的運用機會，但它也可能會在可靠性和穩定性方面造成影響。所有主要的 CSP 都有一個生命週期，在該生命週期中，他們宣布新技術，並在 GA 之前有內部測試與外部客戶的測試。客戶試用這些新技術後，向 AWS、Azure 和 GCP 提供有關調較和改進的反饋。這顯然不是我們從第一天開始就希望在生產環境中使用的技術類型，但組織確實想知道它是否會帶來優勢和業務效益。建議我們在我們的環境中建立sandbox，用於新技術的測試版和預覽版功能。它們不應該已經成為架構的一部分。
最後，最後一個問題是讓它變得太複雜了。我們始終要退後一步，始終將這一原則作為主要準則：保持盡可能簡單，但要準確和完整。
將變更管理與驗證變為我們的基石
從這裡，我們才在架構下工作。這意味著對我們環境中的系統所做的變更是由架構控制的。有時，這些變更會對架構本身產生影響，我們需要更改架構。在多雲環境中，這實際上會經常發生。
雲端平台在使用方面是靈活的，因此我們的架構不能一成不變：它需要允許對我們設計的環境進行改良，從而使這些改良被記錄並嵌入到架構中。改良可能是修復問題或將問題緩解到強度增加的結果。無論哪種方式，我們都必須確保可以驗證、追踪和追朔這些改良導致的變更。因此，變更管理對於維護架構至關重要。
由於我們已經從 TOGAF 中學到了很多，我們還將從這個角度探討變更管理：Phase H。階段 H 是關於變更：追踪變更並控制變更對架構的影響。但在我們深入到適當的變更管理階段之前，我們必須確定我們在 IT 中的變更類型。幸運的是，這相對容易解釋，因為 IT 組織通常有兩種類型：標準變更和非標準變更。同樣，目錄(catalog)在這裡非常重要。
標準變更會在目錄中產生。這個目錄會列出從架構中已預見的變更作為標準的操作、發布或生命週期管理的一部分。一個標準的變更可以是添加一個虛擬機。通常，這些都是非常簡單的任務，要嘛已經從repo和代碼流水線完全自動化，要嘛已經被腳本化。非標準變更要複雜得多。它們尚未在目錄或repo中定義，或者它們由需要規劃這些操作以及其後的多個後續操作組成。
在所有情況下，無論是標準變更還是非標準變更，變更請求都是執行變更管理的觸發器。這樣的請求有一個觸發因素：變革的動力。在架構的變更管理中，變革的驅動力總是有一個業務背景：我們必須在業務中解決什麼問題或增加甚麼效益？例如，發布新業務服務的上線時間太慢了。這個業務問題可能與無法足夠快地部署系統有關，因此我們需要提高部署速度。解決方案可能於自動化 — — 或設計不太複雜的系統。
這是下一步：定義我們的架構目標。這從業務目標（更快地將服務推向市場）和定義業務需求（我們需要更快地部署系統）開始，這導致了解決方案概念（自動部署）。在我們開始描繪之前，還有兩件事我們必須了解。
在這裡，我們需要確定變更的確切影響以及誰將受到影響：我們需要評估誰是利害關係人、需要參與變更的每個人以及這些人的利益(這必須在ADM Phase A中完成)。每個利害關係人都可以對想要進行的變更提出他們的疑慮。這些疑慮必須添加到變更的限制中。可以是預算限制，也可以是時間限制：例如企業無法吸納變更的特定時期。
總之，架構變更管理包括以下內容：
- 變更請求
- 通過業務脈絡中的變更驅動來分析變更請求
- 定義變更要實現的業務目標
- 架構目標的定義
- 識別利害關係人並收集他們的疑慮點
- 疑慮點和限制的評估
這些步驟必須記錄在案，以便對架構的每一次變改都可以得到驗證和稽核。 變改應始終可被檢索。 如果已經配置在環境中，通常可以通過服務追踪環境中的各個變改。 然而，一個變改可以包括雲端平台內的多個變改。 我們將需要更複雜的監控來對這些變改進行完整的稽核與追踪，以確定誰做了什麼。 但話雖如此，盡可能詳細地記錄變更仍然非常重要。
驗證架構
這通常發生在TOGAF Architecture Governance中的Architecture Compliance Review發生。在軟體開發中進行架構驗證是很常見的，但是任何架構都應該經過驗證。我們的方法是什麼？目標是什麼？第一個也是最重要的目標是品質管控(Quality control)。第二個目標是需要考慮需要對架構進行的改良。這樣做是為了保證我們的架構能夠滿足我們的業務目標，滿足所有原則和需求，並且可以得到持續改良。
驗證架構不是稽核。因此，進行peer review完成第一個驗證過程是完全可以的。同時還建議對我們的雲端架構進行external review。這可以通過來自不同 CSP 的雲端解決方案架構來完成，例如 AWS Well-Architected Framework、Azure AZRA(Azure Reference Architecture)。這些公司擁有專業與諮詢服務，可以幫助我們評估是否應用了最佳實踐或幫助我們為我們的架構找到更好的解決方案。當然，企業需要與各自的 CSP 簽訂支持協議，但這至少不是一個壞主意。
以下是至少應驗證的內容：
- 安全性(security):邀請資安專家與資安部門來參與驗證過程
- 互操作性(interoperability):繼安全性之後，互操作性可能是我們在構建多雲環境時要驗證的最重要的事情。 我們不想要無法相互通訊的獨立平台或系統：它們必須能夠通過良好開發的介面進行通訊。
- 可擴展性(scalability):歸根究底，這就是多雲的全部意義所在。 雲端環境在擴展性方面為組織提供了巨大的可能性。 但是正如我們在本文中所看到的，我們必須定義scale set，確定應用程式是否允許擴展，並定義觸發器和閾值，最好是通過自動擴展自動進行。
- 可用性(availability):最後，我們要驗證系統的可用性是否得到保證，備份過程和方案是否滿足需求，以及系統是否可以在特定的RTO和RPO圍內回復。
總之，驗證我們的架構是確保我們完成正確步驟並遵循最佳實踐的重要步驟。
總結
在雲端中，我們很容易立即開始使用，但這不是企業可持續的作業方式。在本文中，我們了解到，在多雲環境中，我們必須努力構建一個經過精心設計的架構。這首先要為不同領域(以TOGAF標準來說是B.D.A.T — Business/Data/Application/Technology)建立架構願景和設置原則。
我們還探討了使雲端環境架構在可用性、可擴展性和互操作性方面非常具體的主題。如果我們設計了架構，我們就必須管理它。如果我們在架構下作業，我們需要在嚴格的進行變更管理。最後，讓來自不同CSP的同行和專家對我們的架構工作進行驗證是一種很好的做法。
有了這個，我們通過查看建立架構的不同階段，了解瞭如何在不同的雲端平台中定義企業架構。我們還了解到，我們應該在各個領域定義原則，這些原則決定了我們的架構應該是什麼樣子。現在，我們應該很好地理解，我們架構中的一切都是由業務驅動的，並且對我們的架構進行驗證是明智的。
