過去幾年，我們見證了中間件操作執行方式上的一次真正變革的開始。首先是發布了 IBM WebSphere CloudBurst Appliance 版本，然後推出了 IBM Workload Deployer 和 IBM PureApplication System 的後續版本，引入了基於模式的部署方法，這些已幫助客戶在 IBM 中間件的計劃、部署和管理方式上實現了根本改變。我們親眼看到，此方法已改變了系統操作形勢，還對采用它的公司中的開發和操作之間的關系產生了重大影響。這些基於模式的方法與 PureApplication System 中提供的全面的系統集成相結合，已徹底改變了采用它們的 IT 組織的運作方式。
但是，我們還發現，為了實現這些改變的全面收益，這些公司還需要采用一組有組織的、可操作的最佳實踐，最大限度地發揮 PureApplication System 的潛力。本文記錄了其中一些最佳實踐，提供了證據證明您可以采用 PureApplication System 對組織效率和總體擁有成本產生重大的積極影響。
解釋這些最佳實踐之前，我們首先需要簡短討論一下 PureApplication System 中存在的資產類型，並介紹一種分類模式來幫助您理解我們建議為這些資產應用的不同管理技術，從而實現您可從 PureApplication System 獲得的最大收益。
從非常籠統的層面講，PureApplication System 中有兩種類型的資產；出於本文的用途，我們將它們稱為共享資產和瞬態資產。
共享資產是供多個團隊或個人使用的長期存在的資源。這些資產包括物理雲資產（ITE 硬件、存儲和網絡交換機），以及虛擬雲資產（環境配置文件、雲組、IT 組）。這個類別還包含軟件資產（比如鏡像和腳本包），重要的是還包括虛擬系統模式。我們將虛擬系統模式分類為共享資產，因為它們應以能最大化重用潛力的方式來構建。這直接關系到最適合創建和管理這些資產的生命周期的組織結構。
如果共享資產是長期存在的資源，那麼相反，瞬態資產就是存在時間相對較短的資源。瞬態資產包括虛擬系統模式實例和卷分配。另一種重要的瞬態資產類型是虛擬應用程序模式。一般的虛擬應用程序模式（和具體的 Web 應用程序模式）包含在構建模式時其中包含的具體的可部署資源。在這些 “以雲為中心” 的應用程序類型中，拓撲結構是一種瞬態資產；實際拓撲結構可能在運行時基於執行的策略（比如可伸縮性策略）而更改。模式的定義也是一種瞬態資產，因為您在虛擬應用程序模式中指定的所有內容都是特定於應用程序的。這包括需要的資源（應用服務器、數據庫等），還包括描述應如何使用這些資源的策略。在此情況下，EAR 文件或 DDL 是另一種特定於應用程序的資產，它們具有與這個特定應用程序的所有其他方面相同的相對壽命。
PureApplication System 中的每種資產，無論是共享資產還是瞬態資產，都將有自己的生命周期和該生命周期你的特定監視點。要最大化 PureApplication System 的效用，IT 組織需要考慮設置一個機構來負責以下一般性的資產管理方面：
維護可用資產的目錄或列表。
圍繞資產生命周期的管理設定適當的策略。
跟蹤資產各自的生命周期並在適當時轉移它們。
我們不會給出您需要制定的治理策略類型的完整列表，下面是一個涵蓋一些最常見場景的代表性列表。
一些常見的共享資源策略包含：
您保持虛擬系統模式版本可使用多長時間？
您對以前的或不推薦使用的模式版本提供多長時間的支持？
虛擬系統版本的命名約定是什麼？
一些較常見的瞬態資源策略包括：
您允許為每種模式實例使用的每種資源（存儲、CPU、網絡）的量
如果不使用，您保持模式示例（虛擬系統和虛擬應用程序）運行多長時間？
如果當前未使用，您保持模式實例多長時間內可用？
考慮圍繞物理和虛擬雲資產（不僅僅是模式）的管理的策略時，該列表將變得更長。例如，如果客戶擁有多於一個 PureApplication System，那麼跨兩個實例的模式目錄管理將成為一種有缺且重要的考慮因素。在每個 PureApplication System 機架的軟件目錄中定義哪些模式，將哪些模式部署到每個 PureApplication System 機架上，這需要結合一些因素來確定，比如支持特定模式的高可用性和災難恢復配置的需求，每種模式的使用（例如，一個具有類似 MDM 的批處理行為的模式僅在一天的某系時間具有高利用率），以及平衡開發需求（比如負載測試）與生產需求的需要。一般而言，可以將這些機架同時用於生產和開發/測試，只要使用 用於隔離的雲組和環境配置文件 設置了合適的分區。
本節列出我們認為有助於有效采用 PureApplication System 的主要最佳實踐。我們首先討論誰創建要對其執行策略的資產，以及需要哪些自動化技術來執行所描述的資產策略。
IBM PureApplication System 附帶了許多現有的虛擬應用程序系統模式，它們代表著 IBM WebSphere Application Server 和其他中間件（比如 IBM DB2）的標准配置。但是，在大多數環境中，您需要以某種方式自定義這些模式，或者需要組合來自 IBM 和其他供應商的中間件來構建自己的模式。無需讓每個項目都從頭創建自己的模式，更好的方法通常是讓一個公共內容團隊創建一些標准模式（這些標准模式代表了您整個組織中的常見用法），然後由每個應用程序團隊對這些模式稍加定制。因此，您需要讓組織中的一些人廣泛審查組織中的所有不同項目，以便他們能夠執行拓撲結構抽象，首先確定需要創建哪些模式，然後構建它們。
類似地，IBM 發布了一種稱為虛擬應用程序的更籠統的抽象方法，為開發人員提供了一種指定描述期望成果的策略的方法，讓系統動態地確定如何生成 正確的中間件拓撲結構來滿足這些成果。許多業務合作伙伴還通過 IBM PureSystems Centre 為自己的應用程序提供了虛擬應用程序模式。但是，高級客戶可能還希望構建為滿足其需求而定制的虛擬應用程序模式組件。出於此目的，IBM 提供了 Plugin Development Kit 來幫助開發人員構建這些組件。這需要經過一定的思考和規劃，確定如何最好地滿足您組織的需求，所以同樣地，這項工作通常由一個集中化的內容團隊來完成。
我們發現，如果沒有深謀遠慮地從一開始就開發一些可重用的模式，此最佳實踐（讓每個開發團隊創建自己的模式）的備用方案會帶來更低的重用率。讓每個開發人員或項目團隊構建自己的模式，所產生的大型的、結構混亂的目錄也更難管理。只要正確地實施，這個基本的最佳實踐會為後面的許多最佳實踐實施奠定堅實的基礎。
前面已經討論過，PureApplication System 包含兩大類資產：瞬態資產和共享資產。瞬態資產，特別是虛擬系統模式實例，有一個特殊的生命周期，該生命周期由（生產環境中）操作團隊或（開發環境中）開發團隊來管理，或者由另種環境中一個聯合的開發/操作團隊來管理。值得一提的是，此生命周期中的大多數步驟都可以自動化。我們看看一個虛擬系統模式的簡單的生命周期，如圖 1 所示。
查看本欄目
在這個簡單示例中（我們未考慮為正在運行的虛擬系統實例打補丁的可能性），一個新置備的模式實例（假設處於開發/測試環境中）最初處於 Started 狀態。在任何時候，管理員都可以停止虛擬系統實例，不會釋放雲中保留的資源，但會終止組成虛擬系統的虛擬機。然後，它們可以 “存儲” 虛擬系統，這會釋放這些資源，但讓虛擬系統實例隨時可用於重新部署。所有這些功能都通過工作負載控制台中的 Instances > Virtual Systems 菜單提供。
前面已經討論過，IT 組織應針對以下方面設定策略：一個實例應該處於每個狀態多長時間，以及它們應在哪些條件下從一個狀態進入另一個狀態。所以，如果一個實例在一段時間內未被使用（例如，這可以通過查閱 HTTP 服務器的 Web 日志來驗證），則應該停止它。在所有者重新啟動該實例之前，它會在固定的時間段內保持該狀態，或者應該進入 stored 狀態。最後，如果某個實例處於存儲狀態而且已有一段時間未被啟動，則可以刪除它。
設定這些策略並經過一段時間的驗證後，我們的最佳實踐建議是，應該將它們自動化。這可保證以一致的方式執行策略，PureApplication System 的共享資源將得到最高效地利用。PureApplication System 命令行接口和 REST API 包含查詢虛擬系統模式實例的功能，以及啟動、停止、存儲和刪除該實例的功能。您可以編寫腳本來自動化這些功能，並實施既定的策略，或者可以編寫程序，通過 REST 接口管理這些操作。
雖然上一個示例中沒有涉及到，但 CLI 和 REST 接口實際上也包含自動化虛擬系統的修補和修復應用程序流程的功能。這是一種更復雜的情形，應謹慎處理，在許多情況下，可能會將實例替換為另一個具有更高補丁級別的實例。
我們已經了解了通過利用不同的技術，使用不同客戶端來自動化這些生命周期步驟的一些不同方法。在某些情況下，自動化離不開數據中心中已使用的現有系統自動化工具；特別是在組織在虛擬化使用方面已經非常成熟而且已經有了以瞬態資產形式管理虛擬鏡像的策略的時候。但是，在組織不那麼成熟並且沒有這些策略和工具的某些情況下，在結合使用自定義 Web 門戶和在 WebSphere Application Server 內編寫的批處理程序上實現全新的自動化方面，我們看到一些公司非常成功。
最後一點，我們認為最有潛力實現這種自動化的一種新興方法是 IBM SmartCloud Orchestrator。可將這些策略的實施視為使用 SmartCloud Orchestrator 構建的不同工作流。盡管與 PureApplication System 集成的 SmartCloud Orchestrator 的采用仍處於早期階段，但我們很容易為使用 SmartCloud Orchestrator 構建的不同 PureApplication System 資產生命周期策略實現構建一個標准庫。
實質上，在構建一種虛擬系統模式時，您要描述一個您可以適當地部署瞬態應用程序資產的通用拓撲結構。如果構建一個集群化的 WebSphere Application Server 模式，該模式連接到一個獨立的 IBM DB2 Enterprise Edition 實例，那麼可以將它用於許多需要同一種拓撲結構的不同應用程序。每個特殊應用程序的不同之處在於詳細的應用程序配置信息，比如 JVM 配置（堆大小等），以及非常重要的應用程序資產，比如 EAR 文件和 DDL。在一個具有許多應用程序的大型組織中，如果每個應用程序都構建了自己的模式，那麼最終會在庫中得到幾乎同樣多的模式。從資產管理角度講，管理、維護和跟蹤所有這些模式可能很有挑戰性。我們親眼看到，在采用這種使用 IBM Workload Deployer 和 PureApplication System 的方法後，結果會得到一個很快變得無法管理的模式目錄。
我們鼓勵當作最佳實踐的一種做法是，虛擬系統模式不應在它們執行的腳本中包含純粹以應用程序為中心的信息。相反，這類特定信息應由部署過程中運行的腳本讀取，作為來自某個共享信息存儲庫或來自部署過程中指定的特定於實例的位置的配置。另一種可能性是使用外部部署自動化工具，在外部事件（比如完成一個新構建版本）觸發該工具時，將這些特定於應用程序的配置項部署到實例中。這可以促進重用每個虛擬系統模式，並減少必須管理的虛擬系統模式的總數。這也適用於大多數開發和操作團隊已擁有的處理應用程序構建和自動化部署的工具和策略。然後要做的事情是獲取 IT 部門已經可以高效使用的工具，將它們集成到 PureApplication System 結構中。
作為一個詳細的示例，可以考慮 PureApplication System 中的腳本包的情形。在下面的最佳實踐中，未在腳本包中包含對依賴於應用程序的信息的直接引用（比如 JDBC 數據源、JMS 資源或 JVM 屬性），或者在腳本包中包含特定應用程序 JAR 或 EAR 文件。相反，將會從一個外部位置引用這些信息。這支持將應用程序生命周期與腳本包的生命周期分開，使您能夠使用相同腳本包將相同模式部署到多個環境中（比如開發、測試和生產環境），甚至在每個環境中的 JDBC 數據源、JMS 資源或 JVM 屬性的細節不同時也可以這樣做。
IBM 在 PureApplication System 中提供了一些工具（Advanced Middleware Configuration 工具）將配置信息與特定的部署本身分開。類似地，IBM 提供了一個名為 IBM SmartCloud Continuous Delivery 的工具（它與 PureApplication System 全面集成），幫助開發團隊以一種直觀、可重復的方式在類似生產的環境中部署和測試軟件。另一種可能性是使用 IBM Urban{code} uDeploy 自動化模式實例中的工件部署。
我們遇到的一個常見問題是，一個模式應為多大，應用程序范圍應是什麼（例如，是否所有應用程序都應包含在一個模式中，或者是否一個應用程序應分散在多個模式中）。一般而言，此問題沒有單一的答案，因為術語 “應用程序” 對不同的人和組織具有不同的意義。對於某些組織，一個應用程序可能只包含一個在應用服務器實例上運行的 EAR 文件。在其他組織中，一個應用程序可分散在多個運行時上，包含數據庫運行時、應用服務器運行時、門戶服務器一年行駛和 ESB 運行時。更確切地說，我們應將該問題重新描述為 “您如何確定一個虛擬系統模式的正確范圍？” 以及 “您如何確定一個虛擬應用程序模式的正確范圍？”對於這些具有更嚴格范圍的問題，我們可應用一些基本原則。
基本而言，我們可將建議描述為：一個模式應僅包含彼此直接相關的組件，不應包含模式外部的任何組件共享的組件，除非所有組件都是共享的。我們將通過一個示例對此進行解釋。
假設您有兩個應用程序，一個 Web Banking 應用程序和一個 Wealth Management 應用程序。每個應用程序都有部署在應用服務器上的 EAR 文件。二者共享一個共享數據庫（Customer Accounts 數據庫）中的一些相同信息。但是，Wealth Management 應用程序還依賴於另一個數據庫（Portfolios 數據庫）中的信息，而 Web Banking 應用程序未使用該數據庫。在這種情況下，最好將這些應用程序沿以下線路劃分為 3 種模式：
模式 1：Web Banking 應用服務器和 Web 服務器
模式 2：Wealth Management 應用服務器、Web 服務器和 Portfolios 數據庫
模式 3：Customer Accounts 數據庫
現在，對各個應用程序執行的任何更改都本地化到受這些更改影響的特定模式中。如果需要對 Web Banking 應用程序執行更改，Wealth Management 應用程序應該繼續不受阻礙地運行，反之亦然。
前面已經討論過，在虛擬應用程序中實現最高重用率的一種方法是，將它們之中任何特定於應用程序的信息與分散在整個應用程序種類的與拓撲結構相關的一般信息分開。然後，將在部署時從外部來源讀取特定於應用程序的信息，最有可能從一個像 Git 或 Subversion 這樣的外部源代碼存儲庫讀取這些信息。同樣的原則也可以並且應該擴展到一般性的共享資源，比如虛擬系統模式的定義、腳本包和虛擬鏡像。
PureApplication System 提供了在機架之間和從機架向外部存儲導入和導出這些共享資產的廣泛能力。舉例而言，在一個 PureApplication System 機架可用於所有開發/測試環境，而另一個機架用於所有生產環境時，這種能力很有用。但是，您真正想要做的是，將獨立於應用程序的資產與您資產中依賴於應用程序的部分資產一起存儲在通用的外部存儲庫中，以便可以將它們作為單個組合資產進行跟蹤管理。這一原則將保證，如果在更改期間發生了任何意外（比如寫得很差的腳本導致升級故障，或者發現了某個有必要回滾到較早狀態的重大應用程序錯誤），應用程序拓撲結構（通過虛擬系統模式表示）、它的鏡像、腳本包和特定於應用程序的信息（比如 JDBC 數據源和應用程序 EAR 文件的特定版本）都可以采用以前經過測試的、證明是穩定的形式進行使用。
除了作為一條要遵守的一般性的不錯做法之外，這條具體的最佳實踐甚至有助於解決當前的 PureApplication System 版本中的一些具體問題。例如，對於腳本包，IBM Workload Deployer 和 IBM PureApplication System 沒有（截至 1.1.0.0 版）提供版本控制。同樣地，腳本包的命名是任意的，未實施任何約束；盡管通過一條一致的、強制執行的命名策略來表明版本號是一種最佳實踐，但僅在外部存儲庫中對腳本包的所有版本進行源代碼控制的情況下，才能保證它們得到全面追蹤和適當的管理。
這然後引出了兩種應對版本控制目前尚未得到全面支持的情況的額外方法。這兩種方法是：
對名稱中的所有內容都使用版本控制
這是最常見的方法。所有模式和腳本包的名稱都應包含一個版本。為了方便持續集成，構建系統可在 cbscript.json 和 pattern.json 文件中采用某種形式的令牌，然後可將結果模式導入到雲提供程序中。此方法很有效，但可能導致一個擴大的目錄；因此，建議構建系統內置一種刪除方法（如本文中所述），或者對目錄和實例執行其他某種類型的定期清理。
在模式之上進行分層，以便通過一個理解構建版本和版本控制的外部系統來處理快速移動的部分
如前面所述，團隊應構建一個標准的 “最佳模式” 集，這些模式更改的頻率相對較低。然後可以將腳本包層疊在基本模式之上。腳本包的工作是在基本模式之上應用某個包的特定版本。腳本包通常應獲取包的版本作為參數。腳本包然後可從媒體庫、構建系統或存儲庫動態地檢索該內容。這與我們前面將拓撲結構與虛擬應用程序中的配置分開的建議是一致的。這是完成其他一些目標的極好方式，比如與現有系統集成來實現構建和自動化，以及維護不受雲限制的自動化或部署工作。此方法的不足之處在於，模式不再是完整的包，需要借助外部構建系統或存儲庫才能正常運行。但是，我們相信為這一權衡結果所花的精力是值得的。
第二種方法在 Smart Cloud Continuous Delivery 中被產品化，但它可使用許多具有版本控制和編程接口的外部自動化解決方案來完成。例如，腳本包可獲取一些參數並調用外部系統，比如 BuildForge Projects、Advanced Middleware Configuration Projects 或 IBM Urban{code} uDeploy。也有一些團隊僅使用 IBM Rational Team Concert 和 JazzBuild with Ant 實現了 “對所有功能執行版本控制” 的方法。需要記住的重要部分是，如果需要對這些系統持續投資，並確保模式輸入（比如版本信息）對用戶而言盡可能的簡單，那麼重用成熟的自動化系統是一個不錯選擇。舉例而言，如果您的模式獲取一個構建版本號作為輸入，那麼應該更新該模式來獲得一個不錯的默認值（比如最後提交的值），或者應該獲取 {latest | committed | release} 這樣的值；部署模式的團隊成員應該不需要花費大量的精力來查找模式的任何部署參數的有效值。
許多客戶擁有 WebSphere Application Server 單元和其他壽命非常長的系統環境 - 通常需要執行重大的版本升級或某種類似重量級的工作，才會促使團隊淘汰一個環境並創建新環境。這些工作通常是傳統環境中非常漫長而又復雜的流程。但是，PureApplication System 使得創建新環境成為了一個快速的、無痛苦的過程。這顯著改變了考慮環境的方式，該方式基於創建或重新創建它們所需的工作量。
如果所有重要配置信息都存儲在一個模式中，而不是僅位於單元的配置文件中，那麼在配置發生任何重大更改後（甚至在采用 WebSphere Application Server 或其他中間件的一個新版本時），更容易重新創建該單元。在 IBM PureApplication System 中，兩個單元甚至可並行運行幾天或幾星期，直到能夠確保新單元的正常運行，此時可以刪除舊單元，並且可保證隨時在必要的時候重新創建舊單元。我們看到的另一種改變是，由於創建單元的復雜性，客戶構建了少量的大型單元；當此操作可在 一個模式中輕松完成時，每個項目都可包含在自己的單元中，從而得到更小、更多的單元。
在采用此模式時，操作團隊工作方式的一種主要變化是，他們必須將所有管理工作轉移到腳本中。盡管可以執行管理操作，比如設置調節參數，或者在特定中間件的控制台（比如 WebSphere Application Server 控制台）中安裝一個應用程序，但在最低限度上，您還應該創建一段執行相同操作的腳本，並將其附加到虛擬系統模式定義中。這可在任何時間點依據實際情況來重新創建環境，確保您可以快速適應計劃內和計劃外的故障。
本文演示了將 IBM PureApplication System 集成到 IT 治理策略和數據中心管理戰略中的一些主要最佳實踐。其他特定領域（比如應用程序遷移）還有其他許多最佳實踐未在這裡介紹，我們將在後續文章中介紹它們。類似地，在對資產的討論中，我們曾經暗示為了最佳地利用 PureApplication System 而有必要執行的組織責任和更改類型。文章 調整組織以實現使用 IBM PureApplication System 帶來的集成系統收益 為描述這些更改的過程開了個頭，我們將在另一篇後續文章中非常詳細地介紹此主題。
查看本欄目
