首先在云计算中实施SOA是很麻烦的一件事。这是因为没有人知道还有什么别的人有成功实施案例和相关技能，尤其是那些以云计算为目标的案例，最后，“SOA作为一个术语在业内已被过度滥用。”
根据SOA标准(源于OASIS、OMG以及Open集团)，首先SOA是架构。这就意味着，它允许任意的实施，其中可能会或可能不会使用特定的技术，例如网络服务或REST.根据SOA标准导航白皮书(该文件由OASIS、OMG以及Open集团于2009年共同发布)，只使用网络服务或 REST并不构成SOA。此外，一个体系架构可以采用几种不同的方法来实现。
在SOA中，大部分技能位于架构设计范畴而不属于开发范围。因此，任何关于“SOA实施技能的假设都只能是一种炒作。”让我们假设我们有一个可以实施重要但复杂业务逻辑的应用程序。我们需要对新任务使用这个逻辑应用程序，同时我们需要令其成为SOA中的一个服务。有些人(事实上很不幸的是有太多的人)会为这个应用程序添加一个网络服务接口，从而宣称他们实施了SOA。好啦，这并不是真的SOA。
首先，这些人必须验证应用程序能够处理类似于网络流量的请求(如果应用程序并不是真正的多线程?)。其次，即便应用程序能够处理多个并发请求，其网络服务将使用新的网络服务接口创建相同的应用程序，仅此而已，但是这与面向服务无关。这个应用程序仍然不是面向服务的，它并不符合面向服务的原则。
另外，有些了解应用程序行为模式和信息模式的人创建了一个轻量级应用程序，一个真正的服务，它将应用程序作为资源来使用。这才是一个面向服务的解决方案，因为我们在通过资源提供所需业务能力的SOA中有一个服务。但是，所有这些又是如何与云计算相关联的呢?其答案取决于云计算的类型，例如IaaS、SaaS、PaaS等等。
IaaS(基础设施即服务)并不是真正的服务，租赁也不是。客户以在其自有数据中心或其他人数据中心中相同的方式使用基础设施。硬件资源虚拟化并不是服务，而是使用模式。因此，IaaS与基础设施的所有权相关。即便IaaS弹性特性对客户很重要，但是从客户端来看它是无形的，而客户为IaaS支付的成本并没有随资源弹性扩张或IaaS资源收缩而改变;其成本只取决于资源的使用而不是规模的弹性扩张收缩。
与IaaS相比，乍看之下SaaS和PaaS更像是服务。在现实中，从符合面向服务原理中提供某一业务功能和影响真实世界(OASIS SOA RM & RAF)的实体来说，SaaS和PaaS都不是服务。顾名思义，这项服务是基于其他人维护的应用程序和平台的，而应用程序和平台可能是完全没有面向服务的。
如果你习惯于把SaaS视为一种服务，要知道那是一项在你自己的SOA实施中所处理过最困难的服务。这一结论的原因又一次地归咎于所有权。 SaaS是一种外部服务，而你对其的所有影响只限于服务合同。如果你的服务合同中并没有明确指定所提供软件应用程序的某一公共访问接口，那么它也就能够合法地拒绝你对该接口的所有服务请求。你无法调整/修改/修正SaaS,这对于IT人来说真是一个奇怪的现象。因此，你的SOA实施技能仅适用于这里的三个方面：
1. SaaS与你的其他系统之间的语义和实体集成
2. 服务合同，其中包括可访问性、可用性、安全性、恢复以及SLA
3. 交互监控以及测量达成一致的指标
对于PaaS来说，这真是雪上加霜。除了与SaaS可用性相关的关注问题，PaaS通常执行某一云计算客户所必需使用的设计、部署与管理工具。这就产生了受制于特定供应商的问题，这是PaaS供应商最乐于见到的，但对于你来说则必须用尽一切手段避免这种情况的发生。更勿论多租户可能对你的组织所造成的业务问题。
PaaS和SOA技能所特有的另一个关注问题是，你计划在PaaS部署的服务应避免使用任何PaaS的特定功能。如果你使用了它们这些功能，那么你将失去对你服务的控制，从而变得依赖于无监督的PaaS资源(功能)。但是，PaaS工具将尽最大努力去违反你的服务独立性(这纯粹是一个营销问题)。
因此，为了在云计算中使用你的SOA实施，你必须学习和运用在面向服务生态系统中的所有权概念。这是技术的新的一面，但是你能够在OASIS SOA参考架构基础规范中找到所有需要的信息。
