作为服务方法的软件拥有连续机构，可以确保服务之间的互操作性。监管XML和WSDL以及OASIS标准的万维网联盟(W3C)为WS-*标准设置了课程。这些类似的措施缓和了客户和供应商遇到的风险。因为应用并没有锁入某个具体的技术，其鼓励软件作为服务范式。但是，直到最近只有一个和服务相联系的领域没有得到解决，这个领域和部署以及扩展服务有关。

　　一旦将软件即服务启用的障碍交织在一起，语言互操作性就不成问题了。但是仅仅发生一次的软件服务就无法利用原始硬件规定解决需求吗？这就让我们无法避免的要分析数据中心基础设施——或者主机供应商。

　　即便是非服务设计，以及创办时期之后应用部署和扩展，参杂着硬件和软件技术的，要求所有虚拟化操作系统和集群中间件产品载入平衡器以及客户应用修改，所有这些都要满足日益增长的需求。

　　在作为服务模型的软件中，制定这种类型的基础设施对于大型机构来说应该是不被准许的。但是供应商却准许小型机构根据需要，按照“用多少付多少”的效用模式扩展应用能力。有些供应商包括Amazon公司EC2服务、Google的APP引擎服务、专门制作软件的3Tera公司、RightScale以及Elastra，这里仅举几个例子。

　　这里蕴藏部署和扩展云计算标准的重要性。一个软件服务可能从所有确保应用互操作性的标准获益，这样就会产生供应商锁定。

　　目前这种锁定是无法避免的，因为这种“使用即付款”的模型要求软件和硬件出现在不同层面，而不是标准的操作系统或者标准服务应用。这种轮流的或者“固定费用”模型——在目前为止是最受欢迎模型——得到标准化，主机供应商提供相同类型的操作系统和硬件，让客户有更多选择，寄存自己的服务。而“使用即支付”这个方法却无法做到这点。

　　最早针对这个领域标准的措施是开放式虚拟机格式规范（OVF），该标准于2007年9月由分布管理任务组创立，Dell、HP、IBM、Microsoft、VMware以及enSource等公司为其提供支持。该标准准许开发商安装事先配置的应用并轻松的将其复制——生成了一个可扩展解决方案——而不会受到专有硬件和软件架构的威胁，只有某些主机供应商为这些架构提供支持。

　　虚拟器这个概念深深扎根于虚拟化技术，正是依靠这个概念多层操作系统才能在相同的服务器上运行。尽管许多“使用即支付”供应商在他们的架构中使用的是相似的理念。很多和OVF相关的措施像Kensho，就是一套能够将实例进口和出口到虚拟设备的开放资源工具。这些虚拟设备就是建立在这个标准基础之上。

　　云计算另一个更为完整的标准就是由3Tera设计的Cloudware。但是OVF只关注虚拟机器，Cloudware则关注云计算中像数据库集成和复制这样简单的事物。

　　尽管Cloudware还处于开发的最初阶段，却吸引了众多“使用即支付”供应商的注意。这些供应商可以帮助人们更好了解每个人使用的零散方法。例如，Amazon公司的EC2服务使用的是“Amazon Machine Image(AMI)”这个理念，而Google公司的App Engine使用的是由3Tera设计的特定硬盘CPU和数据配额。RightScale和Elastra在客户部署和扩展应用的方式上也有明显的不同。

　　尽管上述的这些问题都不会影响供应商或者解决方案的工作效率，但是却导致了卖主的锁定。如果一个应用是围绕现今流行的“使用即支付”云计算供应商所设计，就没有改变的余地了。因为每一个供应商的硬件和软件架构都是不同的，你的应用对服务价格和层次的敏感性会降低——没有转变成“固定费用”供应商那么简单，这些供应商提供相同的操作系统。

　　如果你的服务应用标准和从这些“使用即支付”云计算供应商那里获得了收益，切记要观察一下他们的标准究竟如何。否则，如果你的应用仅仅依靠一个单一的供应商，一旦供应商的服务质量低下，或者服务价格上涨，你选择的余地就会很少。