Azure 登陸區域的設計準則

已完成

Azure 登陸區域概念結構通用於任何登陸區域流程或實作。 架構的基礎是一套核心設計準則,跨重要技術領域指引後續的設計決策。

準則可協助您努力設計出目標結構的最佳設計。 如果您選擇部署 Azure 登陸區域加速器,或任何版本的企業級登陸區域程式碼基底,請套用此處所述的設計準則來建立結構。

實作時以這些準則為準,有助於發揮雲端技術的優點。 這種雲端導向方式通常稱為「雲端原生」,為組織提供有效的技術選項,彌補舊版技術方法的不足。

設計偏差的影響

偏離準則或許有其正當理由,就像 Tailwind Traders 的例子。 設計 Azure 環境時,組織需求可能明訂具體成果或方法。 在這類情況下,請務必了解偏離對設計和未來作業的影響。 仔細考慮各準則的利弊。

一般而言,需求和功能應該平衡。 在打造概念結構的旅程中,一切隨著需求變化逐漸演進,您也會從實作中學到經驗。 例如,利用預覽服務並依賴服務藍圖,可去除採用期間的技術障礙。

訂用帳戶大眾化

以訂用帳戶為管理單位並調整,進而加速移轉應用程式和開發新的應用程式。 使訂用帳戶與業務需求和優先順序達成一致,以支援商務領域和產品組合擁有者。 提供訂用帳戶給業務單位,以支援設計、開發和測試新工作負載,以及移轉現有工作負載。

為了讓組織大規模有效運作,要有適當的管理群組階層來支援訂用帳戶。 此支援能讓您有效率地管理和組織訂用帳戶。

偏差的影響

  • 實作此準則的方法之一是將作業分散,轉移給業務單位和工作負載小組。 此方法可讓工作負載擁有者在平台基礎的保護範圍之內,對其工作負載有更多控制權和自主性。

    如果客戶需要集中式作業,但不想將實際執行環境交由工作負載小組或業務單位來控制,則可能需要修改資源組織設計,並偏離此準則。

  • Azure 登陸區域的概念結構設計,會假設所有作業管理訂用帳戶都有特定管理群組和訂用帳戶階層。 此假設可能不符合您的作業模型

    此偏離會隨著組織成長和演進,可能讓您的營運模型改變。 這項變更可能會導致資源在複雜的技術移轉後,再次移轉至不同的訂用帳戶。 在決定採取某個方法之前,請先檢閱遵守指導。

原則導向的治理

使用 Azure 原則來提供保護,確保組織的平台及其中部署的應用程式持續合規。 Azure 原則也讓應用程式擁有者獨立自主,安全邁向雲端。

偏差的影響

不利用 Azure 原則在您的環境中建立護欄,您會增加維護合規性的作業和管理額外負荷。 Azure 原則有助於限縮和自動達成您在環境內希望的合規性狀態。

在設計考量之中,請檢閱如何在登陸區域實作內使用 Azure 原則

單一控制和管理平面

避免依賴抽象層,例如客戶開發的入口網站或工具。 在集中作業和工作負載作業方面,最好都有一致的體驗。

Azure 提供統一又一致的控制平面,遵循角色型存取和原則導向控制。 這適用於所有 Azure 資源和佈建通道。 您可以使用 Azure 來建立一組標準化的原則和控制,以治理整個企業資產。

偏差的影響

選擇多廠商方法來操作控制和管理平面,可能會讓整合和功能支援變複雜。 即使更換個別元件來獲得「同類最佳」設計或多廠商作業工具,亦可能受限,還會因固有的相依性,造成非預期的錯誤。

如果客戶在作業、安全性或治理方面引進現有的工具投資,建議檢閱 Azure 服務和任何相依性。

以應用程式為中心的服務模型

著重以應用程式為中心的移轉和開發,而不僅止於單純直接轉移基礎結構,例如移動虛擬機器。 選擇設計時,新舊應用程式、基礎結構即服務 (IaaS) 應用程式或平台即服務 (PaaS) 應用程式之間不該有所區別。

不論何種服務模型,對於部署在 Azure 平台的所有應用程式,都要努力提供一個安全的環境。

偏差的影響

以不同於管理群組階層實作選項的方式切割工作負載,治理環境所用的原則和存取控制結構可能變得更複雜。 例如,偏離組織階層結構或 Azure 服務分組。 這項取捨帶來了意外的原則重複風險和例外狀況,這會增加營運和管理的負荷。

客戶考慮的另一個常見方法,是針對開發/測試/實際執行工作負載使用登陸區域。 如需詳細資訊,請參閱常見問題:如何在企業級結構中處理「開發/測試/實際執行」工作負載登陸區域?

遵守 Azure 原生設計和藍圖

盡可能運用 Azure 原生平台服務和功能。 讓此方法遵守 Azure 平台藍圖,以確保新功能可在您的環境內使用。 Azure 平台藍圖應該有助於了解移轉策略和 Azure 登陸區域概念軌跡。

偏差的影響

將協力廠商解決方案引進您的 Azure 環境中,可以建立這些解決方案的相依性,以提供功能支援,並與 Azure 服務整合。

在環境中引進現有的協力廠商解決方案投資,有時無可避免。 為了配合需求,請仔細考慮此準則及其利弊。

建議

不可能開頭就需要一切,請做好功能取捨。 使用預覽服務並仰賴服務藍圖來消除技術障礙。

當您使用此方法時,並非所需作業模型的所有層面都會正式發行。