在ALM原則中實現穩定性

SOA模型和虛擬化/云計算模型的目標都在靈活性和敏捷性上，而且兩者都打破了過去的傳統的單片應用程序和服務器結構。但是沒有應用程序是部署在真空中，甚至是虛擬的或基于云的應用程序有一個基礎的模型，它定義了他們的組件和托管他們的資源池之間的關系。虛擬世界中的SOA和ALM通過考慮新的虛擬應用程序部署模型開始的，而且真實服務器和虛擬應用程序部署模型之間的最大區別是網絡連接。這是SOA AML需要調解的問題。

在傳統的應用程序中，部署是分配應用程序給服務器這的事情，解析服務器的IP后允許應用程序訪問。服務器通常是網絡上一個數據中心局域網，通過VPN或互聯網進行訪問。當SOA應用程序部署時，主要不同是SOA組件化將會在組件之間創建水平的的通道。在數據中心中，基于虛擬化的數據中心，這種新水平通道仍然是在數據中心局域網中進行的，而且網絡性不太可能是主要的因素。這簡化了應用程序的測試和籌劃。

管理水平通道的挑戰

當虛擬化擴展到多個數據中心時，隨著云的應用，問題就是組件化創建的水平通道有更多的不穩定網絡連接。在真正的云應用程序中，托管的組件可以廣泛的分布，性能的不同會被擴大從而影響工作人員的QoE,甚至會引起應用程序的失敗。這意味著工作分配必須在部署中首先優化，然后在所有的ALM中進行測試，這樣軟件的版本經過驗證后，可以進行下一階段的更高級的產品。

當使用高速鏈接(比如光纖，或100G的以太網)在數據中心創建云時，性能風險會因為組件托管不同而不同，將會變小。當云計算是私有和公有的混合云，涉及到了多個公有云，或者是托管在地理位置不同的資源測試流程將會在性能上反映出潛在的大的變化。最大的不同將會出現在沒有連接到共同的虛擬局域網上，而且每個獨立IP子網絡都有不同的廣域網的云中。

除了云網絡的本質外，SOA將要在水平通道上創建變量的范圍與組件之間的工作流的范圍有關。廣泛使用消息和服務總線的應用程序更有可能受組件托管的位置的不同的影響，而不是那些有少量的組件，但是集成而不是編排的應用程序。

當SOA應用程序更有可能對水平通道性能敏感時，那么第一個目標就是在網絡層減少這種敏感，作為項目設計的一部分。這可以通過確保SOA組件之間相互托管在本地完成，這意味著有共同的數據中心。集成的和共同托管的兩個SOA應用程序的位置不實際，那么就試圖把組件分配到數據中心去，通過避免不同位置之間的高容量水平通道的方式。這要通過使用提供的工具和可靠的策略完成，不管是從商業的腳本包還是DevOps工具。

驗證策略限制條件

一旦組件化的托管計劃完成，ALM流程必須驗證這一計劃每一層次的策略限制條件，但這也不能足夠確保應用程序的穩定性。應用程序測試與變量連接延遲從而建立一個合理的向上邊界的性能問題是很重要的，實際的應用程序條件測試來違反這一邊界，來作為ALM周期的一部分。隨著應用程序進入最后階段這尤其的重要。網絡QoS可以用不同的工具測試，而且在一些情況下，一些手邊的應用程序或管理系統可能允許它被監測。使用簡單的管理工具來解析記錄組件地址路徑，從而研究當IP子網絡不匹配的情況。這將是一個暗示，云計算已經轉移組件的主機到了一個新位置，這時性能可能是一個問題。

廣泛的分布式SOA應用程序可能在用戶到應用程序的連接中也承受著大量的不確定性。這相當的真實，當應用程序托管在地理位置不同 的公有云資源上。例如，為也確保主機從一個位置到另一個位置的過渡，并且通過在移動到新位置時擱淺一些組件在某個地方，而不影響性能，ALM應該也要測試過渡流程，再一次地在產品準備階段關注測試。這將會保證可能出現在生產中的情況在變成一個問題之前能充分地解決。