保持簡單
 避免過度設計架構設計、應用程式程式代碼和作業。 |
|---|
這通常是您移除的專案，而不是您新增的，導致最可靠的解決方案。 簡單性可減少控制介面區，將效率低下和潛在的設定錯誤或非預期的互動降到最低。 另一方面，過度簡化可能會造成單一失敗點。 維持平衡的方法。
範例案例
Contoso Travel 正在購買並整合一家小型初創公司與熱門的 Web 型旅遊應用程式。 應用程式的受歡迎程度是由於其商業模式與連鎖店和航空公司談判深層折扣，並使用社交媒體進行激烈和高度有針對性的營銷活動。
現有版本的啟動產品是在 nodejs 中開發，且是在內部部署數據中心與 AWS 之間裝載的 VM 上執行。
將工作負載元件最小化
只有在元件可協助您達成目標商務值時，才能將元件新增至您的架構。 讓關鍵路徑保持精簡。
針對商務需求進行設計可能會導致簡單的解決方案，以便實作和管理。 避免有太多重要元件，因為每個元件都是重大失敗點。
Contoso 的挑戰
- 新取得應用程式的其中一個元件有助於在使用者提出保留之後，直接在網站上收集意見反應。 此功能很少使用，因為大部分使用者只是略過此功能。 用戶有強大的意見反應循環機制，可透過公司的社交媒體帳戶運作，而該帳戶主要用於營銷用戶互動。 此機制比網站的意見反應功能更頻繁地使用。
套用方法和結果
- 在 Contoso Travel 品牌版應用程式的初始版本中，小組決定移除工作負載的網站意見反應元件。
- 較小的程式代碼基底可降低維護和作業的成本。 在此案例中，對商務需求沒有任何影響。
標準化軟體開發生命週期
在程式代碼實作、部署和程式中建立標準，並加以記錄。 使用自動化驗證來識別強制執行這些標準的機會。
標準提供一致性，並將人為錯誤降到最低。 標準命名慣例和程式代碼樣式指南等方法可協助您維護品質，並讓資產在疑難解答期間更容易識別。
Contoso 的挑戰
- 來自新創公司的開發小組未定義許多開發和程序標準。 有許多連結庫會與功能重疊、不會強制執行程式代碼樣式，而且發行管線缺少使用自動化測試的正式發行網關。
- Contoso 工作負載小組意識到新程式代碼基底的維護成本太高，因為樣式缺乏一致性，而且使用連結庫和設計模式不一致。
- 生產環境中主要更新之後經常發生事件，有時需要復原更新或中部署熱修正程式。 這些類型的部署問題頻率會強制小組在發行生產環境的更新時使用全手操作支援模型。 為了更糟，常見問題會透過不佳的用戶體驗對 Contoso 的聲譽造成負面影響。
套用方法和結果
- 小組接管新應用程式的支援，藉由強制執行編碼樣式、標準化一組常見的連結庫和設計模式，以及根據自動化測試正規化發行網關的使用，來努力達到更高的一致性。
- 實作這些變更時，工作負載小組會遵守其標準檔需求。 採用的所有新工具、設計模式和樣式都會經過徹底記載，讓小組能夠更有效率地瞭解和維護工作負載。 小組現在可以在執行程式代碼檢閱時更輕鬆地識別標準中的偏差。
將作業和開發負擔降到最低
利用平臺提供的功能和預先建置的資產，以協助您有效地達成商務目標。
這種方法可將開發時間降至最低。 它也可讓您依賴已搭配類似工作負載使用的已嘗試和測試做法。
Contoso 的挑戰
- 針對 Contoso Travel 商標下的初始版本，nodejs 解決方案會從 VM 移轉至 App Services，以利用服務所提供的許多原生可靠性功能。
- 部署在 VM 上的版本包含大量檢測所需的自訂程式代碼。
套用方法和結果
- 在初始移轉至 App Services 期間，小組能夠在 App Services 中實作 App Insights 自動結構來移除所有自定義檢測程式代碼。
- 小組也能夠利用其他數個原生 App Service 函式，例如自動調整、金鑰保存庫 整合和區域性備援。