Azure 架構完善的架構要件

已完成

雲端改變了組織解決其業務挑戰的方式,以及設計應用程式與系統的方式。 解決方案架構師的角色不僅是要透過應用程式的功能需求來提供商業價值。 同時也必須確保解決方案的設計具備可調整、復原性、高效率及安全等特性。

解決方案架構與技術系統的規劃、設計、實作及持續改進有關。 系統的架構必須以執行業務需求所需的技術能力來平衡及符合那些需求。 完成的架構是整個系統與其元件之風險、成本及功能的平衡。

Azure 架構完善的架構 \(部分機器翻譯\)

Azure Well-Architected Framework 是一組指導方針,用於協助租用戶在 Azure 上建置高品質的解決方案。 雖然設計結構沒有一體適用的方法,但不論結構、技術或雲端提供者為何,的確有一些適用的通用概念。

雖然這些概念並不詳盡,但是將焦點放在它們之上,可協助您為應用程式建置可靠、安全且有彈性的基礎。

Azure 架構完善的架構由五大要件組成:

  • 成本最佳化
  • 卓越營運
  • 效能效益
  • 可靠性
  • 安全性

An illustration that shows the pillars of the Azure Well-Architected Framework.

成本最佳化

您想要設計雲端環境,使其以符合成本效益的方式運作及開發。 找出雲端費用的濫用和浪費,以確保您所花費的金錢得以充分利用。

An illustration that shows increasing quality, speed, and efficiency while maintaining decreasing costs.

卓越營運

透過利用現代化的開發實務 (例如 DevOps),您就能加快開發及部署週期。 您需要有良好的監視架構,才能在失敗和問題發生之前,或至少在客戶察覺之前,先偵測到它們。 自動化是此要件的重要層面,可移除變異數與錯誤,同時提高作業的靈活性。

效能效益

架構應該適當地比對資源容量與需求,才能執行正常並可調整。 傳統上,雲端架構會根據應用程式中的活動,動態擴縮應用程式規模來達成此平衡。 對服務的需求會變更,因此您的架構必須能夠根據需求進行擴縮。 在設計結構時考量效能與可擴縮性,將能為客戶提供絕佳體驗,同時符合成本效益。

An illustration that shows how resources in the cloud scale dynamically based on demand, resulting in highly efficient usage. When resources are implemented at a fixed level, it results in inefficient usage during low demand and shortage during high demand.

可靠性

每位架構師的最大惡夢就是架構故障,完全沒辦法復原。 成功的雲端環境設計要能夠預期所有層級的失敗。 預期失敗的一部分是設計一個系統,可在專案關係人與客戶所要求的時間內從失敗中復原。

An illustration that shows two virtual machines in a virtual network. One of the machines is shown as failed, while the other is working to service customer requests.

安全性

資料是組織技術足跡中最有價值的部分。 在此要件中,您將著重於透過驗證來保護對結構的存取,以及保護應用程式與資料以免受到網路弱點的影響。 您也應透過加密等工具來保護資料完整性。

您必須思考應用程式整個生命週期 (從設計和實作到部署和運作) 的安全性。 雲端提供各種威脅的防護,例如網路入侵和 DDoS 攻擊。 但您仍然需要在應用程式、程序與組織文化中建置安全性。

An illustration that shows the types of security threats and attacks that might affect your data in the cloud.

一般設計原則

除了上述每個要件之外,您還必須在整個架構中考慮一些一致的設計原則。

  • 能夠進行架構演進:沒有架構是靜態的。 利用新服務、工具與技術的優點,讓您的架構演進。

  • 使用資料進行決策:收集資料、進行分析,並用來進行有關架構的決策。 從成本資料到效能,到使用者負載,使用資料能夠引導您在環境中做出正確的選擇。

  • 教育並賦能:雲端技術發展迅速。 教育您的開發、營運與業務小組,協助其作出正確的決策,並建置可解決商務問題的解決方案。 記錄並分享組織內的設定、決策與最佳做法。

  • 自動化:將手動活動自動化可降低營運成本、將手動步驟造成的錯誤降到最低,並提供環境之間的一致性。

共同責任

移至雲端會導入共同責任模型。 在此模型中,雲端提供者將管理您應用程式的某些層面,讓您承擔其餘的責任。

在內部部署環境中,您需負責處理一切。 當您移至基礎結構即服務 (IaaS),然後移至平台即服務 (PaaS) 與軟體即服務 (SaaS) 時,雲端提供者需承擔這其中大部分的責任。

此共同責任會在架構決策中扮演重要角色,因為這些決策可能會影響成本和安全性,以及應用程式的技術與營運功能。 透過將這些責任轉移給提供者,您即可專注於為自己的業務提供價值,且無需再處理非核心業務功能的活動。

An illustration that shows the level of shared responsibilities in each type of cloud-service model.

設計選擇

在理想的結構中,您會建置可能最安全、高效能、高度可用且有效率的環境。 不過,所有事情都有所取捨。

若要建置所有要件均為最高等級的環境,就要付出代價。 該代價可能是金錢、提供時間或運作靈活度。 每個組織都有不同的優先順序,而這些會影響在每個要件中所做的設計選擇。 當您設計結構時,必須判斷可接受與不可接受的取捨。

建置 Azure 架構時,有許多考量要牢記在心。 您希望您的架構是安全、可調整、可使用且可復原的。 為此,您必須根據成本、組織的優先順序及風險進行決策。