規劃現代化應用程式平台
雲端採用架構的計畫方法可協助建立整體雲端採用計畫，以引導與雲端式數位轉型相關的程式和小組。 本指南會提供您建立待辦項目所需的範本，以及建立所有小組所需技能的方案，相關的需求都會根據您在雲端中所要執行的作業而定。
規劃方法的應用會著重於合理化數位資產的 5R 策略。 邁向雲端最常見的路徑以移轉和現代化流程的速度、效率及重複性為重點。 依據 5R 策略，在規劃時通常會優先處理重新裝載選項，並需兼顧重新架構和重新建置選項提供有限的平行支援。
數位資產
在規劃數位資產時，您會想要收集詳細目錄資料，並合理化資產。 在容器採用方案中，將所有資產 (例如 VM、資料和應用程式) 依照其所支援的工作負載予以分組是一個重要步驟。 一旦完成分組和基本的合理化之後，您就可以評估這些工作負載來決定封裝和重新裝載或重新架構的各個選項。
標準的雲端採用方案範本適用於一般雲端採用工作所需的工作類型。 但是，您會需要將工作新增至方案，以便將工作負載封裝到容器中，並協調容器的佈建。
警告
本文假設讀者已遵循在 Azure DevOps 中建立雲端採用方案文章系列中所述的最佳做法。 如果您在試算表或其他專案追蹤工具中追蹤您的雲端採用方案，下列各節仍然適用，但會需要調整新增資料至方案的可操作步驟。
警告
將現代化應用程式平台策略合併至標準移轉程序 (或移轉 Factory) 中時，會需要先完成與在移轉前設計工作負載架構建立關聯之工作的實作。 如果沒有那些工作就繼續進行本策略，將會延誤移轉工作，並可能導致部署的容器主機和支援工作負載的架構決策不良。
識別候選的工作負載
在現代化應用程式平台案例中，除了獲得較長期的回饋 (需要較大量的前期投資) 之外，會比更有效率的移轉程序得更加重要。 較長期的投資會在方案中以特定部分表示，以提升對特定工作負載群組啟用創新和簡化作業的焦點。
若要開始對策略和計畫進行調整，請找出雲端採用策略中可能會因增加現代化應用程式平台而影響的所有工作負載。 這些假設都會在實作任何技術變更之前加以驗證。 若要協助識別潛在的候選項目，請在您的工作負載組合中尋找下列準則：
- 主動開發或 DevOps 投資：部分生產工作負載會置在主動開發下進行。 有些部分甚至可以透過進行中的 DevOps 實務來管理。
- 工作負載可攜性：某些工作負載會受合規性、資料保護或作業條件約束的影響，而可能會需要具備可跨越私人雲端、邊緣或甚至多個公用雲端服務提供者的可攜性。
- 工作負載彙總：許多工作負載 (尤其是使用率徧低的工作負載) 可能是在容器主機上導致伺服器/VM 變少及營運成本降低的彙總候選項目。
- 舊版工作負載：舊版工作負載可以封鎖作業系統的更新，甚至會阻止移轉至雲端。 與 Azure 功能不相容的舊版工作負載，可以當作是要在容器主機上進行移轉的候選項目。
記錄候選工作負載
注意
下列考量清單應該只針對依照上述準則所識別出的移轉候選項目進行記錄。
在建立雲端採用方案時，每一個工作負載都要遵循定義和設定工作負載優先順序中的指導方針來記錄。 任何屬於現代化應用程式平台案例候選的工作負載，都需要引導方案執行的額外資訊。 該篇文章強調了記錄商務和技術輸入以定義工作負載的重要性。 針對現代化應用程式平台的候選項目，應將下列資料點新增至工作負載的定義中。
商務方面的考量要項
以下是商務相關資料點，可能會影響新式應用程式平臺策略中的工作負載納入決策。
- 合規性驅策因素：在私人雲端中裝載此工作負載所需考量的特定合規性準則有哪些？
- 資料保護驅策因素：在私人雲端中裝載此工作負載所需考量的資料保護措施有哪些？
- 作業的條件約束：在私人雲端中裝載此工作負載所需考量的作業條件約束為何？
- 新式應用程式平臺成果： 下列哪一項是評估此工作負載作為容器候選項目的驅動程式？ DevOps、可攜性、彙總、舊版或以上多項。
- 作業模型：這項工作負載將會以集中式 (中央 IT/CCoE) 管理、分散式 (由工作負載小組) 管理，或是透過企業營運 (集中式支援及工作負載特定作業) 的方式進行管理？
技術方面的考量要項
下列是來自技術小組的資料點，可能會影響在現代化應用程式平台策略中包含工作負載的決策。
位置考量：
與工作負載裝載位置相關的考量。
- 公用雲端裝載的需求：是否有與公用雲端需求建立關聯的特定技術條件約束？
- 私人雲端裝載的需求：是否有與私人雲端需求建立關聯的特定技術條件約束？
- 邊緣裝載的需求：是否有與邊緣需求建立關聯的特定技術條件約束？
- 可攜性的需求：是否有與雲端可攜性需求建立關聯的特定技術條件約束？
作業考量：
與平台、主機和工作負載作業相關的考量。
- 主要雲端平台：組織應定義主要雲端平台，以提供作業管理工具。 部分組織可能會有一個以上的主要雲端平台用以管理各種類型的作業。 操作此項工作負載的主要雲端平台為何？
- 其他作業平台：是否將有任何其他的作業平台也會管理此工作負載？
- 雲端裝載需求：這項工作負載是否需要特定的雲端裝載策略？ 公用雲端、私人雲端，或雲端可攜性
- 標準化協調流程平台：如果該公司擁有適用於容器協調流程的標準解決方案，請將該標準化平台的名稱納入考慮。 範例： Azure Kubernetes Service (AKS)、AKS 引擎，或 Kubernetes。
- 自訂協調流程考量：是否有非標準容器協調流程平台的需求？ 如果有的話，請說明這項需求。
- 標準化主機作業：假設工作負載為安全無惡意，且可以裝載於由標準化主機作業所支援的共用容器中。 這項工作負載是否與此方法相容？
- 自訂主機作業考量：如果工作負載與標準化作業不相容，則在為這項工作負載建立主機作業做法時應考慮哪些特定的需求？
應用程式考量：
應用程式特定開發方式，以及未來發展方向的考量。
- 平台即服務 (PaaS) 執行階段：公用雲端服務提供者會產生一致應用程式執行階段，通常稱之為「平台即服務」(PaaS) 供應項目。 在 Azure 中，PaaS 執行階段是由 Azure App Service 所提供的。 這個應用程式可在 PaaS 執行階段上運作嗎？ 最具相容性的執行階段為何？
- 標準化的執行階段：如果應用程式與 PaaS 執行階段不相容，組織是否有提供標準化的執行階段？ 會將這個工作負載建置於哪一個執行階段？
- 自訂執行階段的考量：針對這個工作負載，自訂執行階段會需要特別考慮的項目有哪些？
- 執行階段的條件約束：所選擇的執行階段是否會有條件約束強加於應用程式？
- 應用程式的相依性：此工作負載是否與特定位置 (像是公用或私人) 中任何現有系統存在有相依性？ 例子包括 ERP 系統，像是執行於特定解決方案中的 SAP。
- 資料引力：此工作負載是否與特定位置 (像是公用或私人) 中的資料來源存在有相依性？ 例子可以包括與 SAP 或其他集中式資料來源中的資料存在有相依性。
- 核准清單考量：自訂作業的考量是否已獲核准可用於您的雲端平台內？ 哪些核准的服務項目必須包含於部署之中？
初始容器的考量
將工作負載封裝於容器中，是必須要排程和處理的第一個工作主體。 第二個工作要項是規劃那些容器的裝載。
適用於標準化的執行階段、協調流程和作業所需的 PaaS 解決方案
部分工作負載是高度獨立的，且未必會受益於大型平台 (例如 Kubernetes) 所隨附進階控制項和基礎結構的需求。 只因為您工作負載已容器化，並不意味著它必須部署至 Kubernetes。 Azure 提供了多種不同的解決方案，可在您的組合內部執行工作負載，而不需要 AKS 所需的管理和基礎結構層級。 下列解決方案均會遵循此方法來規劃：
如果您不想要增加複雜性，同時又要符合這些解決方案的用途與限制，請考慮對具有工作負載的容器使用較輕量解決方案。
在公用雲端中使用自訂執行階段和作業的標準化協調流程
對於那些無法在完全受控的 PaaS 平台中執行的工作負載，且必須依賴基礎結構層級的控制項，想要使用像是由容器協調器所提供的進階部署功能，或預期模組化複雜度會增加的工作負載，請改用 Azure Kubernetes Service (AKS)。 AKS 可以同時解決這兩個容器的裝載，但也提供廣泛的架構、SRE、安全性、部署、監視及基礎結構等選項。
平台的功能集會要求要同時可以學習叢集操作員層級和工作負載層級上的平台。 請將營運小組、架構小組和工作負載工程小組的教育訓練需求納入移轉時間表中。 同時，由於 AKS 是一個平台，請確保工作負載小組了解此平台內責任與目前裝載安排之間的區隔。 這兩者可能在某些方面很相似，但在其他方面卻又截然不同。
公用雲端中自訂的協調流程、執行階段及作業
針對每個特製化的工作負載或特定的組織需求，Azure 在容器協調流程空間中提供了兩個其他的主要平台。
- Azure Red Hat OpenShift
- Azure Service Fabric
如果有理由要探索其他替代方案，請確定已配置足夠的時間了解平台所有選項的優點以及需要取捨之處。 Azure 的預設解決方案是 AKS，而這份文件也假設 AKS 是您會選用的技術。
跨雲端平台的標準化作業
客戶通常會在私人雲端、邊緣和公用雲端環境中部署不同的容器協調器。 為了將跨越不同雲端平台的作業標準化，客戶可藉由將其雲端作業工具延伸至多個雲端平台，以合併成一個統一的作業方法。
在 Azure 中，組織可將不同的容器主機上線至適用於 Kubernetes 的 Azure Arc，進而對跨越不同協調器的作業進行標準化。 這項工具可確保跨越每一個容器主機之間的監視、作業和治理都能保持一致。
私人雲端和邊緣環境中的應用程式執行階段
當工作負載必須在私人雲端或邊緣環境中執行，但 PaaS 執行階段最能支援該工作負載時，有一些工具可讓開發人員使用 Azure App Service 在一致性的 PaaS 執行階段之上進行建置：
- Azure Stack HCI：允許在 Azure Stack 上以原生方式裝載由 Azure Stack 操作員所管理的 Azure App Service。
- 適用於 AKS 的 Azure Stack HCI：允許在 Azure Stack 中裝載由 Azure Stack 和 AKS 操作員所管理，且可在 AKS 上執行的自訂執行階段，以提供可用於其他 Kubernetes 解決方案的可攜性。
- Kubernetes 上的 Azure App Service 與 Azure Arc：允許任何 Kubernetes 主機在 Azure 中提供應用程式服務。 所有的主機都成為 Azure App Service 的小型執行個體。 由於每一部主機也都會上線到 Azure Arc 中，因此那些主機也可以透過一致的雲端型主機作業來管理。
新式應用程式平臺整備計畫
除了雲端採用技能方案之外，雲端採用小組可能還需要具備與容器和 Kubernetes 相關的開發技能，才能執行您的方案：
請確定已配置工作負載小組用來記錄和執行移轉計畫所需的時間。 現有的應用程式或外部系統 (兩者同為依賴此工作負載的相依性和系統) 可能會需要加以修改，新增支援移轉工作所需的彈性。 這對生產前和生產時期的環境均可適用。
下一步：檢閱環境或 Azure 登陸區域
下列文章清單會針對雲端採用旅程中的各個特定主題提供指引，以協助您順利完成雲端採用案例。