云计算的出现不仅在地理上延伸了SOA的愿景，实际上还推动了所有的SOA朝着基于云的应用与资源关系的转变。SOA应用因而变成最容易移植到云端的应用。
尽管它是最容易移植，但移植并非自动完成的。本文研究SOA的基本要素、模块化以及资源类别，可帮助云应用架构师、开发者及开发运营经理简化基于SOA的云迁移工作。
在开发者渴望利用可重用组件创建软件，以及企业利用定制应用行为来优化员工生产力的双重推动下，SOA的概念已经发展了10多年了。
SOA基础设施包括四个基本元素：处理器服务器系统、存储操作系统及中间件、用户到应用的映射，以及负载均衡。显然，这些也是任何其他IT基础设施的四个构成的基础要素，不过SOA改变了企业应当将能力均衡地分配到这四个领域的方式，以便对可用性和性能进行优化同时控制成本的方式。这通常是靠SOA架构模型以及应用模块化和部署方式完成的。
开放计算项目为硬件设计提供了指南，可用作与商业设备进行比较的一般参考，不过这也许并不能为SOA搭建出最合适的平台。
SOA和“原子”应用最显著的区别在于模块化。好的SOA应用可划分为创建应用的功能性组件，这会对基础设施产生重要的影响：
—组件对特定的资源的使用率可能比整个应用更高。对数据库进行分析的SOA应用也可能会将分析和数据库功能拆为单独的组件，这两者一个是高度计算密集型的、一个是高度存储密集型的。这种拆分使得针对特定需求而建的硬件成本很低。
—除了应用与用户间的“垂直”流量以外，模块化应用增加了额外的组件之间的“水平”流量。这一流量模式的变化会影响到数据中心网络的设计，比方说，会促进交换式结构。
—组件可复制来提高整体工作能力，这需要有一组特定的工具，根据某些代价/性能策略组来分配任务给SOA组件群中的其中一个。这就导致了组件间负载均衡机制的引入。
—“靠近用户”的组件，这意味着组件跟用户的GUI相关，是可以与活动点在地理上接近、毗邻的。
这些因素交织在一起，可以让企业以最佳的视角按“资源种类”观察SOA基础设施，那些有效支撑主要SOA组件的若干系统或存储配置。资源种类的数量将取决于SOA组件需求的范围，不过大抵会包括以下这些：
—数据库及查询服务器，旨在利用层次化存储的原则支持大型数据库。可能会拥有大型的RAM、具备闪存、快速磁盘存储I/O接口、高性能网络连接以及适度的计算能力。
—计算及分析服务器，用来执行复杂计算。通常需要具备RAM和许多高速的处理器内核，可能甚至还要有GPU来加速计算功能。
—分布式服务器，用来支持与用户GUI创建或事件处理相关的本地处理。有可能是低成本的基于ARM而非X86架构的微型服务器。
组件的分布，尤其是SOA组件的复制，可创建更多的执行路径，改进性能，这意味着SOA基础设施将需要某种形式的网关。有两种选择：硬设备和“虚拟网关”。硬件网关往往又叫做“负载均衡器”或“三层交换机”，会根据某些调度策略直接将流量引导到现有组件中。虚拟网关使用SOA目录功能根据需要分配组件。最好的办法要取决于组件间的关系性质，尤其是组件是否真的会为了提高能力而进行复制。网关设备是连接应用用户与SOA组件的最流行方式，虚拟网关则是后端交互组件流管理(包括工作流引擎消息传递或服务总线流)的更好手段。
至于SOA基础设施的数据库这一块，也需要考虑“虚拟”和“物理”的问题。允许数据在地理上高度分散的数据网格技术，如Hadoop，往往会将应用分布到多个节点上并行运行，然后收集并关联结果。这对混合计算和存储节点提出了需求。另一方面，今天的许多“大数据”及分析应用都是基于设备或特定目的的节点，通过查询语言访问的。这使得SOA应用组件与数据分析功能分离，减少了对特定数据接口或CPU及GPU分析功能的需求。
这里列举的网关和数据库例子说明，SOA基础设施必须首先从虚拟或逻辑的层次进行考虑，然后才是考虑硬件、软件及中间件。有效的SOA应用设计首先要依赖于应用被模块化并编排进有序的工作流的办法。这一流程创造了必须加载在资源上的软件元素，创造了将应用整合到一起的中间件以及托管每一组件以及组件类的最佳硬件的需求。
至此，大多数人都将意识到所有的SOA应用均演变为基于云的应用对资源的关系，无论是否存在一个明确将应用托管于公有云、私有云或混合云的计划均如此。实际上，“云化SOA”与现代SOA的形式不同之处主要在于对硬件资源分散到什么程度的假设上。今天大部分的SOA应用都是运行在数据中心上的。而云应用则必须假定资源池是跨越数个数据中心的，甚至还可能分布在全球各地。支撑SOA应用集的资源池的范围越广，建立高效网络连接来传输进程间流量的重要性就越强。如果SOA工作流建立的流量模式得以悉心地进行规划和分析，SOA的网络需求就可以轻易升级以支持云迁移，令充分规划的SOA应用成为最容易迁移到云端的应用。
