虚拟化是这样的一个术语，用来组件化物理资源，从而促进应用之间或用户之间的共享，包括在云端。面向服务架构（SOA）提供了高度组件化的应用程序，这些程序的功能可以混合及匹配来适应工作人员的需求。这样的结果是，这是应用程序式的虚拟化。随着应用程序和资源虚拟化的同时进行，出现了一个问题是：应用程序生命周期管理 （ALM）原则怎样通过一组合理的实践同时击中这两者，并向着实现操作稳定性的目标前进？

　　在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应该也要测试过渡流程，再一次地在产品准备阶段关注测试。这将会保证可能出现在生产中的情况在变成一个问题之前能充分地解决。