定义云的互操作性

　　和“云计算”这个词一样，互操作性对于不同的人来说也有着不同的意义。一些人可能会理解成把应用从一个环境迁移到另一个环境的一致性能力——比如把应用从Savvis迁移到亚马逊，互操作就是要让应用在两个不同环境中精确的一致。另一些人则可能理解成应用在不同的云中运行，应该能够彼此共享信息，这就意味着需要一些通用的接口集。

　　而对其他人来说，比如对思科的市场战略师James Urquhart来说，云的互操作性就是用户可以跨不同的云计算提供商和不同的云平台使用同样的管理工具、服务器镜像和其他软件的能力。

　　这一问题的实质在于，每家厂商的云环境都支持一个或多个操作系统和数据库。每个云环境都包含有多种hypervisor、流程、安全、存储模式、联网模式、云API、许可证模式及其他。很少会出现两家厂商以完全相同的方式，完全相同的迁移策略来实施其云服务的情况。

　　沙丘集团的云计算咨询专家Kamesh Pemmaraju说，和传统的软件和硬件环境一样，云的互操作性会首先出现在堆栈的较底层。在基础设施层有OVF(开放虚拟化格式)，当然还有针对XML、HTML和其他协议的标准。

　　但是在堆栈中越往上走，厂商的锁定程度就会越来越强。

　　在平台这一层，厂商的锁定是最强的，Pemmaraju说。“我们现在到处都可以看到一些不同厂商的垂直PaaS堆栈，每个堆栈彼此之间都是不兼容的。”

　　假如你只把某个应用的某些部分迁移到目标云中，那么当这些部分需要交换数据或者调用API时，它们还不得不“返回”原来的云。于是有关安全、性能和延时的问题就都会出现。假如你要把某个应用整体迁移——将数据库、中间件、用户界面等等全带上——那就不必担忧这些问题了。

　　操作系统版本和hypervisor版本的不匹配也会造成一些不易解决的冲突。云提供商在定义服务器和存储之间的关系时，会施加一些在源应用中并不存在的限制。源应用可以会使用一些存储技术来实现某些性能目标——结果在目标云中，这些存储技术却因为定义上的限制而无法使用。

　　几乎每个云都有着少有的基础架构，可在服务器与应用之间、服务器与存储之间提供网络服务。每朵云都可能在网络寻址、目录服务、防火墙、路由器、交换机、身份认证服务、命名服务和其他资源上有所差异。目标云提供商的网络架构肯定会与源头云的网络架构不同。之所以会如此的一个原因是他们希望支持多租户环境。

　　云提供商还会做出他们自己关于安全策略的选择：谁可以访问什么资源，软件升级的规则，使用数据和磁盘的政策等等。在云安全方面，应用的使用者和所有者通常都没有多少可选择余地。有些应用需要在特定的安全域中运行，但是云提供商却有可能不支持这类安全域，或者说他们所做的改变可能会破坏该应用所需的安全环境。

　　在源头云中的一些熟知的管理工具在目标云中通常无法使用，或者只能在某种限定条件下使用。驱动程序、工具、操作系统配置或者操作系统版本在两种云环境下也都可能发挥不同的作用。在源头云中所使用的软件升级工具必须进行改写以适用于目标云。密钥管理必须成为连接源头云和目标云桥梁的组成部分，在目标云中对密钥的管理必须十分谨慎小心。

　　Gartner的Skorupa解释道，即便云的互操作性问题随着时间的进展而得到了解决，在各种云之间迁移大型的数据集合仍然会出现问题，这是因为延迟的问题依然存在，迁移数据依然需要时间。因此当你想要迁移一个应用时，你还通常还不得不把与之相伴随的存储也进行迁移。

　　Xsigo公司的I/O Director正在努力使数据和应用在单一云中的不同主机之间的迁移变得更为便利，但是该公司似乎还没有推出能够解决跨云迁移应用相关存储的类似产品。

　　IT研究公司Ideas国际的分析师Tony Iams称，很多人都在考察数据在云之间的往复传送成本，但结果让他们很沮丧。

　　在云间迁移一个应用，意味着首先要将其从原来的生态系统中剥离。你必须搞清楚这么做是否合适。很有可能你还需要根据目标云所提供的组件/部件重新设计该应用。那么，为了让这个应用在目标云中也能够像其原来的形式那样运行良好，你是否愿意对其重新改写呢?

　　重新改写就意味着原来所使用的一些服务可能不能再使用了，或者说源应用不能再用了。源头云和目标云之间的这些差异还有可能触发一系列的集成问题。