十年前，面向服务架构突然出现在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，因此给后者假定前者的经验教训是有风险的。认真探索此问题，而且在做出生产承诺之前一定要彻底试运行测试。
