Azure的CAF / WAF / AAC 三種雲端架構設計框架

隨著雲端概念越來越普及，Azure 作為一個雲端平台，已逐漸演變成為一個高度複雜的架構。早期的 Azure 概念是讓使用者在雲端上開啟所需的資源並建立相關的服務，同時也不需要自行建構機房等基礎設施，因此具有相當的優勢。但是隨著時間的推移，雲端的應用也越來越廣泛，因此 Azure 也提供了許多指導方式和架構，讓我們更容易上雲，不過，即便如此，還是有很多企業對於上雲依舊有一定抗拒或是無法進行轉移或是接受。

在 Azure 上，我們可以看到三個重要的框架名詞，分別是 CAF、WAF 和 AAC。這三者是 Azure 平台的框架和學習歷程，有助於大家更快速地轉移到雲端。然而，我需要強調的是，它們任何一個都並不是唯一的解決方案，必須可以根據自身需求和情況，採用不同的框架或框架的部分內容去執行，如果，你聽到只有某一個框架設計模式才是正確方式，往往這將會帶入一些錯誤概念，當然也會讓你的雲端費用增加。

CAF / WAF / AAC

這三種名詞分別定義如下:

CAF全名是Cloud Adoption Framework

適用於 Azure 的 Microsoft 雲端採用架構。CAF 為使用者提供完整的生命週期架構，協助雲端架構設計人員、IT 專業人員和商務決策者實現其雲端採用目標。CAF 提供最佳做法、範本和工具，支援使用者建立及實行雲端的商務和技術策略，並確保其符合企業的需求和目標。

提到CAF，一定就會聽到 Azure 登陸區域（Azure Landing Zone），這是與 CAF 有關的概念架構。Azure 登陸區域是一個範例，協助組織在雲端環境中成功運作，同時維持安全性和治理的最佳做法。每個 Azure 登陸區域的實作選項都提供了部署方法和已定義的設計原則，以幫助使用者建立一個符合其需求的雲端環境。

WAF全名是Azure Well-Architected Framework

是一組指導方針，旨在協助用戶在 Azure 上建置高品質的解決方案。在設計架構時，並不存在一個通用的適用方法。然而，無論是架構、技術或雲端提供者，都有一些通用的概念是適用的。這些概念並不全然相同，但是專注於這些概念可以協助使用者為其應用程式建立可靠、安全且彈性的基礎。Azure Well-Architected Framework 可以幫助使用者理解這些概念，並提供指導方針，以確保使用者在 Azure 上建置的解決方案能夠滿足其需求且符合最佳實踐。

AAC全名是Azure Architecture Center

雲端正在改變應用程式的設計和保護方式。 不同於龐大且單一的體系，應用程式會分解成較小型的非集中式服務。 這些服務會透過 API 或使用非同步傳訊進行通訊。 應用程式可水平調整，以依據需求要求新增執行個體。

大部分人熟知的是Cloud Adoption Framework (CAF)。然而，該架構的目的是為了讓那些對雲端架構與服務不太熟悉、卻又渴望使用雲端概念或技術的人可以更容易地從地端遷移到雲端。CAF架構設計概念很大程度上與地端建置相似，尤其在將虛擬機遷移到雲端時更是如此。CAF是一個引導式的步驟，可確保透過正確的討論和建立正確的技術基礎。需要注意的是，CAF並非一個唯一的架構範本，而僅僅是一種方法論。

三者框架的關係與應用

Azure上的服務日趨多樣化，對於喜好VM的使用者，他們仍然傾向使用VM，然而對於希望將服務作為積木組合的使用者，他們會採用PaaS方式。然而，就整體而言，大多數情況下使用VM作為方案還是比較多，特別是在大型企業中，而這現象通常都是由技術、政治、傳統思維以及分工…等因素導致還必須仰賴這種架構模式。

先前提到CAF並非使用Azure的唯一方案（儘管有些顧問認為這是唯一的解決方案），CAF的早期概念是為客戶提供端對端的協助，包括考慮、規劃、採用和操作Azure環境。組織考慮轉移到雲端的起點，需要指導商業案例、技能等方面的規劃，但也指導用戶執行重要的第一步技術，稱為建立Azure登陸區，也就是zure Landing Zone。然後進行遷移、創新、現代化和操作概念，例如管理、安全和治理。

當有使用雲端一段時間後，需要更具體的指導來建立工作負載，包括設計/構建階段以及在運行期間進行優化。因此，有Azure Well-architected Framework（WAF），通常是針對架構師角色在使用。WAF通過5個支柱（可靠性、安全性、成本優化、操作優化和性能效率）來考慮如何建立的雲端工作負載。這是比Cloud Adoption Framework更深入的特定於工作的架構指引，而兩個框架都是幫助組織中的不同角色學習雲端相關的知識並完成與其角色相關的任務。至於，哪種架構必須誰先誰後，我認為這沒有一定標準

Azure Architecture Center (AAC) 是一個提供深入架構指導的平台，其主要關注參考架構和實作方法等內容。AAC 提供解決方案的想法，幫助我們快速成功並減少設計架構所需的時間。在這個平台中，大多數指導原則是基於 Well-architected Framework 的原則。

這三個框架共同構成了架構指導的核心，提供更好的雲端設計。通常這些框架是相互搭配使用，以幫助組織中的不同角色了解雲端，並完成與其角色相關的任務。我認為，只有透過三者的互相搭配組合，才能建構適合的雲端系統架構。尤其當大量使用 PaaS 組合時，透過 WAF 和 AAC 的架構內容就非常適用，而 CAF 則可在部分治理與管理上發揮作用。

雖然，近年來強調雲原生的概念，但並非所有問題都可以用雲原生解決，尤其像是將 ERP 遷移到雲端或是將包袱系統遷移到雲端，就無法直接採用雲原生的概念。此時，採用 CAF 方式建立雲架構就非常合適。但如果整體架構都採用雲原生方式建置，CAF 只能是一種輔助，無法全盤採用。

看法

這三個框架其實都是非常的龐大，如果，今天你是一個完全還沒有碰觸過Azure的使用者，可以從CAF這部分開始學期，如果，已經是在Azure運用一段時間的人使用者，可以先看AAC或是WAF讓自己原有的架構或治理達到更完整的程度。那是否要轉移到CAF，我覺得如果在現有管理上或是安全性已經有一定的程度，倒是不需要急著轉移到CAF，還有就是規模程度是否夠大。就以目前企業來說，有些已經完全是Cloud的應用架構(就是捨棄地端的建置)，這樣使用CAF或許是一個不錯選擇。如果只是部分或是某些情境財運用雲端，可能AAC或是WAF情境會比較適合。為什麼會先用這樣初略的劃分?主要在於其實這些框架的設計與建置，不外乎附帶的就是雲端費用的成本，當你設計架構所帶來的商業價值遠小於付出成本，就必須要考量是否有需要。若是從資安角度上，這三種框架其實都有提到資安設計，在CAF比較多會是像VNET方式進行建構，VNET串聯確實是相對安全也類似我們在地端機房的網路設計模式，但它不是唯一的資安解決方案。所以，還是要看情境去設計

那到底雲端架構設計或是治理，從企業角度來看到底是誰需要負責或是主導，就我看來如果都採用IaaS方式，則這個責任落在傳統的Infra Team會比較多一點。如果採用PaaS的方式，這個主導設計將會若在管理商業或是Applcation應用層級的團隊會多一點。不過，我想這條路還是需要一段要走才能做分隔。

總而言之，這三種框架絕對需要依照現有情況與解決方案設計，如果，有人只告訴只有某一個框架是最重要的，那樣，就必須考慮說出這個話的人是真的了解企業想透過雲端帶來的成效是甚麼嗎?還只是讓企業花過多的金額在雲端費用而得不到實質的商業效益。

參考資料

• Introduction to hybrid and multicloud — Cloud Adoption Framework | Microsoft Learn
• Microsoft Azure Well-Architected Framework — Azure Architecture Center | Microsoft Learn
• Cloud management — Cloud Adoption Framework | Microsoft Learn
• How to adopt the cloud — Cloud Adoption Framework | Microsoft Learn
• Prepare for cloud adoption — Cloud Adoption Framework | Microsoft Learn
• Transition existing Azure environments to the Azure landing zone conceptual architecture — Cloud Adoption Framework | Microsoft Learn
• 檢閱和比較常見的雲端作業模型 — Cloud Adoption Framework | Microsoft Learn