不同于传统的位于单位组织内部的 IT 基础设施，云计算的诞生给单位组织的 IT 资源供给带来了前所未有的灵活性——可以瞬时增加、转移或者减少计算资源来快速响应动态的资源需求变化，能在几个小时而不是几周内部署一个新的应用来满足业务需求。

    为了达到这种更具弹性的计算能力，在设计任何云系统时必须要考虑互操作性与可移植性。
    互操作性规定，IT 系统中应用软件层以下各层采用开放的通用型组件，杜绝使用云服务提供商各自内部的封闭组件。
    可移植性规定，IT 系统中应用软件层和数据信息层应采用开放的通用数据格式和软件运行环境，保证同一个应用和数据能随意迁移到其他地方。

    一方面，互操作性与可移植性能让你把服务扩充到多个由不同云服务提供商提供的云端，在操作层面就像一个系统；另一方面，互操作性与可移植性能在不同平台或者不同云端之间轻松移动数据和应用。

    互操作性与可移植性不是随云计算出现而产生的新概念，也不只是在云计算环境中人们才考虑互操作性与可移植性，只不过与传统 IT 系统相比，具备开放和共享处理能力的云计算更需要考虑互操作性与可移植性。多租户意味着多个单位组织的数据和应用并存，并且不排除能通过共享平台、共享存储和共享网络访问（有意或无意）他人机密数据的可能性。

    下面重点介绍在设计互操作性与可移植性时必须考虑的关键因素。
互操作性
    互操作性是云计算生态系统中各个协同工作的组件应具备的特征，这些组件可能来自各种云端和传统 IT 系统。互操作性使得我们可以随时使用新的或者来自不同云服务提供商的组件来替换已有的组件，而不会中断云中的任务，也不影响数据在不同系统之间进行交换。

    单位组织在使用云服务的过程中可能会考虑更换云服务提供商，常见的原因如下：
        续签合同时，云服务提供商的报价令消费者难以接受。
        消费者发现有价格更便宜的同类型云服务产品。
        云服务提供商停止了业务运营。
        云服务提供商在没有给出合理的数据迁移计划之前，关停了企业正在使用的服务。
        云服务提供商的服务质量难以令消费者满意，如未能达到服务水平协议（SLA）中规定的一些关键性能指标。
        云服务供/需双方之间存在商业纠纷。

    如果缺少互操作性（与可移植性），就会出现消费者被云服务提供商捆绑的现象，最终会损害消费者的利益。

    一个云端互操作性的优劣程度往往取决于该云服务提供商是否使用开放的或者公开发布的架构和标准协议及标准的 API 接口。许多云服务提供商（如 Eucalyptus）喜欢在标准组件的基础上添加非公开的钩子和扩展，以及一些增强功能，显然这些都会降低互操作性与可移植性。
可移植性
    可移植性是指能把应用和数据迁移到其他地方而不用理会云服务提供商、平台、操作系统、基础设施、地点、存储、数据格式或者 API 接口如何。

    在选择云服务提供商时，可移植性是需要考虑的一个重要方面，因为可移植性既能防止云服务提供商锁定客户，又允许我们把相同的云应用部署到不同的云服务提供商那里，如建设灾备中心、同一应用全球分布式部署等。

    如果未能妥善解决云迁移中的可移植性与互操作性，那么可能会无法实现迁移到云计算后的预期效益，并可能导致成本上升或项目延期，这是因为本该避免而未能避免的如下因素：

    1）云服务代理商或提供商锁定——一个特定的云解决方案的选择可能会限制以后转移到另一个云服务提供商。

    2）处理不兼容和冲突造成服务中断——云服务提供商、云平台和应用的差异可能会引发不兼容性，这种不兼容性会导致应用系统在不同的云基础架构中发生不可预料的故障。

    3）不可预料的应用系统重新设计或者业务流程更改——当迁移到一个新的云服务提供商时，可能需要重新审视程序的功能或者要求修改代码，以确保其最初的执行行为。

    4）高昂的数据迁移或数据转换成本——由于缺乏互操作性与可移植性，当迁移到新的云服务提供商时，可能会导致计划外的数据变化。

    5）数据或应用程序安全的丧失——不同的云服务提供商可能采用不同的安全控制、密钥管理或者数据保护策略，当迁移到一个新的云服务提供商或云平台时，可能会暴露原先未被发现的安全漏洞。

    把应用迁移到云端是外包的一种形式，而外包的金科玉律是“了解前期并做好如何退出合同的计划”。因此，可移植性（和在一定程度上互操作性）应该是任何单位组织计划迁入云端时必须考虑的关键标准，同时开发好一个切实可行的退出方案。

下一篇：大数据预测

上一篇：H3CNE及H3CSE-RS下线通知