適用於建構流程的 Azure 技術
在本單元中，您將瞭解創新流程與產業中部分技術之間的關聯性，可協助您在應用程式中建立新功能。
DevOps
在您開始進行建構階段以驗證您的創新假設之後，所需的開發、整合和部署週期應盡可能地簡化。 這個階段便是 Azure DevOps 派上用場的時候。 您可以將 DevOps 定義為「快速且可靠傳遞軟體功能的流程和工具」。以下是此定義的詳細內容：
流程和工具：Azure DevOps 和創新流程本身都是以鼓勵變更的文化模式為基礎。 Azure 和 GitHub 提供有關 Azure DevOps 的絕佳工具，但單單購買授權並不足夠。 您的流程和組織文化都必須演進才能採用變更和創新。
快速傳遞軟體功能：Azure DevOps 流程和工具採用快速檢錯的概念。 建立 MVP 或原型以快速驗證您所處理的功能是否朝著正確的方向是 Azure DevOps 概念的核心。
可靠地傳遞軟體功能：規避改變的組織通常會將快速變更與停機連結在一起。 不過，Azure DevOps 的承諾完全相反：快速的變動率和高度的可靠性。 這種可靠性可以藉由在開發週期初期階段，在稱為「左移」的流程中進行整合測試。
如果一段時間內的功能開發顯示為從左至右的線條。 那麼，舊版開發程序就會在開發週期結束時，執行使用者驗證和品質控制。 在該行的「右」端。 Azure DevOps 建議您儘早於該時間表的「左側」進行測試並驗證。
Azure DevOps 具有良好創新文化的相同核心概念。 採用它的方法是進入敏捷創新週期的關鍵。
微服務架構
模組化是已知的技術，可降低架構複雜系統的複雜度。 如果系統是由許多無法分開的部分 (通常稱為「單體」) 複雜互動，那麼緊密的元件相依性會讓系統改善變得很困難。 每項變更都需要使用系統的其他部分進行驗證，因此測試流程很複雜。
如果是模組化的系統，則可以將其分成較小的子系統，透過定義完善的介面讓彼此互動。 為其中一個子系統導入變更很容易，因為只要其介面與其他模組保持不變，整體系統就能繼續運作。
微服務架構是利用開發模組化的應用程式模式。 應用程式會細分為個別的小型元件，而這些元件可以獨立開發，甚至可能使用不同的程式設計語言。 每個元件 (或微服務) 都可以自行操作。 您可以視需要加以調整，可以將其疑難排解為單一單位，也可以獨立於其他微服務進行修改。
組織通常會問的問題是，如果應用程式是整合型的，該怎麼辦。 在導入創新之前，組織應該將應用程式重新設計成微服務架構，還是可以同時執行創新和重新設計程式呢？ 這個問題沒有單一的標準答案。 這取決於所考慮應用程式的複雜度和商務相關性。
在 Tailwind Traders 準備在其電子商務平台中導入創新時，他們面對了這個問題。 有鑑於應用程式的商務重要性，公司決定啟動專案，將電子商務應用程式重新設計成微服務架構。 沒有模組化應用程式可能會嚴重影響 Tailwind Traders 回應線上市場變化趨勢的能力。
不過，Tailwind Traders 已決定同時處理其平台中的一些主要缺口。 等待應用程式重新設計專案完成，意味著公司會因為爭相進入電子商務市場的新創公司而失去大量市場占有率。
專案間會互相影響，並以創新的商業價值為導向。 重新設計工作會將重點放在最重要的應用程式領域中，而其中改善客戶體驗的修改需求是最重要的。
容器
容器化的技術並非專門用來微服務架構，但這些概念可妥善搭配運用。 容器是一種封裝應用程式程式碼和其相依性的方法，可讓您輕鬆地將其部署到任何平台。
傳統的應用程式部署需要組織先安裝軟體，例如應用程式執行時間、程式庫或外部元件。 這種方法通常會導致「它可在我的電腦上運作」的問題：很難在開發、測試、預備和實際執行環境之間複製相同的環境。 在安裝應用程式相依性過程中的小差異可能會導致應用程式在測試時正常運作，但在部署到實際執行環境時卻是失敗的。
容器改變了遊戲規則。 應用程式相依性會在自主部署單位 (稱為容器映像) 的應用程式程式碼中一同封裝。 無論應用程式的容器是部署在開發人員的筆記型電腦或是具有數百個節點的生產叢集網路中，相依性處理都是一樣的。 容器的運作方式完全相同，因此應用程式測試更可靠且更值得信任。
自從 Docker 於 2013年中以開放原始碼的形式釋出程式碼，容器的運用已經有了長足的進步。 容器現在支援 Linux 和 Windows，以及不同的 CPU 架構。 Azure 中有許多可讓容器型工作負載執行的供應項目。 在本單元中，您將了解其中的一些。
Kubernetes 和 Red Hat OpenShift
容器執行階段是在電腦上啟動容器的技術，但在實際執行環境中需要更多的邏輯。 如果需要更多的效能，誰會部署更多容器？ 如果容器有問題，誰會是將其重新啟動的人員？ 如果有多部電腦可用，誰會決定哪些電腦應啟動特定的容器？ 這些工作和其他工作是容器協調流程平台的責任。
Kubernetes 的第一個版本在 2015 年發行，而且很快就成為容器協調流程的實際標準。 Kubernetes 叢集是由數個背景工作節點所組成。 每個背景工作節點都有一個容器執行階段，因此其可以執行容器，其中 Kubernetes 控制平面會安排容器化應用程式的部署。 此控制平台通常於一組核心節點中執行。 它負責讓應用程式正確執行、縮放應用程式規模，並執行任何必要的更新。
Kubernetes 之所以熱門的主要原因之一，就是容器所提供的硬體獨立性。 因為容器型應用程式可以可靠地部署到任何容器執行階段，所以您可以在使用各種 Hypervisor 的雲端中執行 Kubernetes。 部署的應用程式應該以類似的方式運作 (假設基礎硬體資源也類似)。 許多組織都採用 Kubernetes 作為抽象層，讓內部部署和公用雲端中的應用程式部署程式都能一致。
在 Azure 中執行 Kubernetes 很簡單。 Azure Kubernetes Service 易於部署且符合成本效益，因為只有背景工作節點的費用會向客戶收費。 Microsoft 會承擔包含核心元件的控制平面成本和作業。 Microsoft 會修補並更新背景工作節點的作業系統，進一步降低管理 Kubernetes 叢集執行 Linux 和 Windows 容器的作業複雜度。
OpenShift 是以 Kubernetes 為基礎的應用程式部署平台，並且是由 Red Hat 開發及支援。 其包含許多其他功能。 因為這些額外的功能和 Red Hat 提供的支援，所以部分組織會選擇在 OpenShift 上執行其應用程式。 同樣地，在 Azure 上執行 OpenShift 也很簡便。 Azure Red Hat OpenShift 是由 OpenShift 叢集所組成，其中 Microsoft 會管理許多層面，包括叢集的整個生命週期。
Azure App Service
Azure App Service 是一個平台，可讓組織在不需要管理任何協調器或基礎作業系統的情況下，執行其網頁型工作負載。 唯一的要求是透過許多可用的部署方法之一，將應用程式程式碼上傳至服務。 Azure 便會執行其餘作業：縮放應用程式規模、修補和維護基礎虛擬機器等等，而不需要 Kubernetes 的學習曲線。
Azure App Service 支援以容器為基礎的工作負載，因此您可以上傳您的容器映像，而不用上傳應用程式程式碼。 其同時也支援 Linux 和 Windows 工作負載，以及許多不同的應用程式執行階段。
Azure App Service 支援各種不同的計價模式，包括稱為 Azure Functions 的無伺服器選項。 在 Azure Functions 中，只會收取應用程式使用量的費用。 沒有固定成本。
對於創新而言，無伺服器模型很有趣，因為其可讓您部署新的微服務，就算不受市場接受也不會產生高額的每月帳單。 這個模型是速錯機制 (Fail-fast) 策略的另一個範例，創新不一定代表高費用。
Azure App Service 也提供支援 Azure DevOps 導向部署的功能，例如 Web 應用程式位置。 位置是暫存區域，您可以在其中部署新功能，不會影響實際執行環境。 從創新的觀點來看，插槽是很好的選擇，因為您可以將一小部分的客戶重新導向到這個新版的應用程式。 然後，驗證您的創新假設是否正確。 最終，如果您想將新的程式碼升階到生產環境，便可以「交換」位置，讓預備環境成為實際執行版本。
摘要
在此單元中，您已瞭解技術能夠如何支援創新：
- Azure DevOps 流程和工具可讓您的開發和營運小組快速可靠地提供新功能。
- 您可以將應用程式重新架構至微服務，允許對個別元件進行創新，而不會影響其餘部分。
- 容器可讓您跨多個平台和環境進行可靠的應用程式部署。
- Kubernetes 是一種無雲端限制的協調流程平台，可執行容器化應用程式。
- Azure App Service 可以執行具有最低管理額外負荷的網頁型工作負載。 它提供許多功能，例如無伺服器或應用程式位置，以加速創新週期。
Tailwind Traders 決定開始將其電子商務應用程式重新設計成微服務架構。 與「整合型架構」分開的第一個應用程式子系統是付款服務，因為您認為其能為客戶提供更佳價值的關鍵領域。
在付款子系統之後，會有更多應用程式元件轉換成獨立的微服務。 微服務會透過 REST API 進行通訊。 每個微服務的應用程式程式碼將會容器化，而開發和作業組織將採用 Azure DevOps 的最佳做法。
由於 Tailwind Traders 不希望依賴任何特定的公用雲端，因此決定在公司內部建立 Kubernetes 的專業知識，並將應用程式部署在 Azure Kubernetes Service 叢集上。 如果需要開發新的微服務，公司會選擇將 Azure Functions 視為 MVP 部署的平台，以降低開發成本。
下一步
此單元中的許多概念都會在雲端採用架構文章＜以數位發明實現採用＞和＜在雲端採用架構中的 Kubernetes＞中進一步說明。