共用方式為

Azure 上 SaaS 工作負載的設計原則

  • 發行項

身為獨立軟體廠商（ISV）提供 SaaS 解決方案， 您負責解決方案的卓越架構，並與客戶共同負責。 它們依賴您的解決方案，而且問題可能會串聯至這些解決方案。 如果您的組織已成熟且擁有已建立的客戶群，可靠性和安全性可能是您最大的顧慮。 停機時間和安全性缺口可能會對貴公司的收入和信譽產生負面影響。

但是，許多ISV，尤其是啟動的ISV，都以有限的資源運作，以將成本降至最低。 如果您的組織處於啟動階段，您可能必須做出積極的取捨，才能繼續進行下一階段的成長。 您可能沒有專用的治理、安全性或部署自動化小組，但請記得規劃未來的成長。 如果您必須冒險，請做出計算決策。

如何設計以低規模運作的解決方案，與大規模解決方案不同。 為了支援快速成長，您應該 設計具有彈性和適應性的 SaaS 工作負載架構。 本文將討論這種成長演變的基本原則。 一起考慮所有五個架構完善的架構支柱，包括取捨。 所有要素都有最低標準，因此請考慮每個要素。 如果您未套用這些原則，您可以引入財務損失並減少客戶信任。

可靠性

設計原則 考量
排定可用性的優先順序。 您的解決方案 是 您的業務。 盡可能保持高可用性。 如果您的解決方案發生中斷，影響不僅會影響您的客戶，也會影響客戶。
明確說明您為客戶提供的服務等級協定（SLA）。 當您為客戶建立財務支援的 SLA 時，請確定您可以符合它們，以及您相依的元件與其相容。 檢閱基礎 Azure 服務的複合 SLA，作為 SLA 設計程式的一部分。 不要進行假設。 在 SLA 中反映您的共同責任模型。

取捨：可靠性和成本。 若要達到高可用性，您通常需要部署額外的資源。 例如，您可以將資源分散到多個可用性區域或區域。 某些 Azure 服務提供內建異地複寫或區域間復寫，但這些功能通常具有很高的成本。

針對預算允許的復原層級做出明智的決策。 如果工作負載中某些元件或流程的可靠性沒有財務影響，請考慮低成本的機會來改善復原能力。 例如，您可以使用平臺服務的可用性區域、定期將數據備份到另一個實體位置，並使用基礎結構即程序代碼 （IaC） 快速重新部署資源。

安全性

設計原則 考量
建立控管作為安全性的基礎。 從頭開始建立良好的治理做法，而不是稍後解決問題。 許多因素會影響安全性，例如您管理角色的方式、組織資源及實作原則。 如果沒有健全的治理，安全性控制不會保護系統。
遵循第一天起的雲端安全性基準。 預期客戶的安全性稽核。 在設計初期納入稽核線索。
隔離您的客戶，並隔離您的區隔。 使用您的租用模型作為數據隔離的策略。 分割您的部署和環境。
從 零信任 開始，並提供最少的存取權。 默認為沒有存取權的位置。 僅在必要時才引入最低存取權。 使用此策略進行身分識別管理和網路流量。 定期檢閱流程，並針對異常情況採取行動。
盡可能避免認證。 如果您必須使用認證，請加以保護。 將認證視為責任。 使用信譽良好的識別提供者和技術，將認證記憶體降到最低。 當無法避免時，請使用安全的雲端原生方法保護認證。 盡可能小心處理客戶認證和秘密。
採用安全性作為進行中的程式。 持續重新評估您的安全性狀態。 請考慮不斷演變的威脅環境、新功能和通訊協定，以及更新的合規性或法規需求。

取捨：安全性和成本優化。 設計和操作安全解決方案的成本很高。 但是，您可以達成重要的安全性步驟，例如良好的治理，並遵守安全性基準，而不需要花費最少的費用。 判斷成本效益與理想安全性狀態之間的平衡。

成本最佳化

設計原則 考量
只需支付您所需的費用。 利用Microsoft成本管理功能來瞭解您的整體支出。 優先處理最昂貴的資源類別，以進一步檢閱。 識別您可能會過度加支的區域。
使用您支付的費用。 將您支付的資源價值最大化，但可能不足。
為您的成本建立模型。 追蹤您銷售的商品成本。 瞭解將解決方案提供給客戶的成本。 此程式類似於製造實體產品。 若要通知您的決策制定，請監視每位客戶相對於其產生的營收的成本。 若要快速瞭解和匯總您的 Azure 支出，請實作治理程式，例如良好的資源組織和標記。
瞭解您的成本和營收如何相關。 避免在沒有相應增加營收的情況下增加成本的情況。 例如，如果您新增提供無限制免費記憶體的新功能，成本可能會增加。 同樣地，如果您根據用戶數目向客戶收費，請確定您將功能與用戶系結。

取捨：成本優化和可靠性。 若要建立可靠的解決方案，您通常需要部署額外的元件、傳輸更多數據，以及使用更具彈性的關鍵元件 SKU，這一切都會增加成本。 新增的可靠性通常值得花費，但您必須做出明智的決策。 若要抵消這些成本增加，請確定您有效地使用其他元件並最大化其價值。

卓越營運

設計原則 考量
瞭解共同責任模型。 清楚定義雲端提供者、您的客戶和組織的責任。 確定每個人都知道誰負責哪些工作。
準備代表您的客戶操作解決方案。 設定您的組織、小組、程式和工具，以支援大規模運作 SaaS。
採用一致的程式。 使用部署戳記。 在戳記組態和架構之間驅動一致性。 自動化或標準化程式。
將例外狀況或差異正規化。 定義不同的 SKU 以符合不同的需求。 使用此方法可避免不同客戶的自定義部署、組態或程序代碼。
安全地推出變更。 實作安全部署程式，您可以在發生問題時用於漸進式暴露、持續監視和復原。 針對程式代碼、基礎結構和組態變更使用一致的程式。 控制您在任何指定時間部署的解決方案版本數目。

取捨：卓越營運和複雜度成本。 自動化管理作業可以增加解決方案的複雜性，並花點時間建置。 一開始，自動化的成本可能超過優點，尤其是小型客戶群。 但是，隨著客戶數目的增長，自動化的成本會得到回報，而權益也會增加。

效能效益

設計原則 考量
實作全域規模以啟用全域效能。 透過多區域部署或加速流量路由，為全域客戶提供良好的體驗。
量化您的預期規模。 建立最佳、平均和最差案例成長案例的模型。 分析趨勢，並洽詢您的銷售小組以取得實際預測。 規劃彈性調整策略，以因應各種成長可能性。
瞭解縮放點。 找出您可能需要彈性的位置。 常見的觸發程式包括每位用戶的客戶或租使用者、使用者和交易數目。 了解這些因素在業務成長時如何變更，以及它們如何影響您的架構。
相應放大的設計。 相應增加有限制，但相應放大允許更大的擴充。 並非所有專案都會相應放大，因此請考慮使用部署戳記將解決方案調整為單位，以避免相應增加資源的限制。

取捨：效能效率和可靠性。 可靠的系統通常需要跨整個地理區域的數據復寫。 視您的復寫設計而定，此設定可能會導致更高的延遲和較低的輸送量。 例如，如果您在兩個相隔數百英里的 Azure 區域之間同步複寫重要數據，您可以因為即時複寫而將數百毫秒新增至回應時間。

後續步驟

藉由優化客戶的計費和成本管理策略，開始學習旅程。

設計區域：Azure 上 SaaS 工作負載的計費和成本管理