十年前，面向服务架构突然出现在IT舞台上，而且许多公司已经在SOA应用上进行了大量的投资。很明显，云计算的成功取决于它能够给现有的SOA实现增加价值的能力。调查显示，花在基于SOA原则的应用上的企业IT美元比花在单片应用上的要多。不甚清楚的是SOA可能是云的理想伙伴，使之大于它的所有部分的总和。

SOA系统中的应用程序不同于基于模块化和编排组合而成的应用他们建立于模块化元素，这些元素是根据用户，甚至是个别工人的特殊的工作流需求组合而成的。这通常是通过工作流引擎，有时称为消息或服务总线完成的。

SOA应用设计托管在多任务的操作系统上，而且现在的大部分服务或消息总线技术都将会支持服务集群。因此，在企业SOA数据中心中，云计算已经生效这是一个事实，每一个SOA系统组件都是即服务的元素。促使SOA应用真正与云兼容，尤其是与混合云，关系到SOA能做什么与云需要什么之间的平衡关系。

预防基于SOA云的失败

在云中创建SOA的最大问题，是大多数公司希望在混合云应用中的动态负载均衡，尤其是对于核心的，关键任务的SOA应用。有两个元素促使负载均衡工作：当需要时创建额外的组件实例，并随着负载的改变或发生失败，在这些组件中平衡应用流量。

如果负载均衡在数据中心的使用中已经改变，在这些改变之后它有可能创建云实例，使它们看起来像是数据中的扩展。这允许你继续使用现有的负载均衡策略。尽管如此，如果数据中心的能力消失，那么负载均衡的改变也会消失，云中的故障转移也会失效。如果负载均衡做为云或网络服务实施，那么它就可以支持混合云SOA的实现即使数据中失败。

有时候，SOA服务总线或工作流引擎将会在多个主机上动态产生应用组件的额外实例，从而提升性能或对失败做出响应。这种情况下，要与云服务供应商协商，确保服务总线接口与公有云服务兼容。如果不能把服务总线应用实例流程直接连接到云管理接口上，并启动云组件的话，你可能不得不使用开发脚本或DevOps工具，来加速必要的公有云资源，然后让服务总线使用他们。

当使用任何一种云服务来创建弹性扩展的私有SOA资源池时，评估供应商延迟应用的影响很重要。无论公有云资源是直接通过工作流引擎激活的，还是通过DevOps的，都有一个激活的阶段，这时资源将不可用，这将会影响生产率。延迟对工作负载溢出应用的影响较小，因为你可以简单的调整新资源要求的需求水平。然而，这种调整可能会导致加速那些因需求减少而不需要的公有云资源。准备备用的服务或有现成的服务水平协议(SLA)来减少云资源的供应时间可能是最佳解决方案。

选择与SOA兼容的公有云厂商

根据本地用于运行您的SOA应用程序的操作系统和中间件的不同，对于公共云托管组件你可以有多种选择。你惠普、IBM、微软和甲骨文这样的公司有平台即服务(PaaS)的选择，这与他们的服务器和中间件工具相兼容。所以如果你使用来自这些厂商的SOA软件，那么第一件事是评估使用来自同一个公司的云服务的利益和成本。

如果那不可能或你希望探索更广的选择，那么基础设备即服务(IaaS)可能会是一个不错的方向。记住，对IaaS公共云处理你当前的SOA组件，IaaS设备像必须包括你使用的操作系统和中间件。确保你的IaaS云供应商能够支持你的操作系统和中间件，并确保与公有云使用的兼容的许可。

大体上说，管理员需要认识到SOA和RESTful或Web接口是不同的东西。大部分的SOA应用包含编排和工作流、及在基本Web服务中缺席的安全和合规元素。现在大多数云应用更多是基于RESTful接口，而不是SOA，因此给后者假定前者的经验教训是有风险的。认真探索此问题，而且在做出生产承诺之前一定要彻底试运行测试。