试图减少锁定、提高云计算互操作性并最终为自己的企业选择最佳的解决方案，众多云计算用户一直以来都在极力寻求实现云到云的无缝迁移功能。令人遗憾的是，上述需求还未能得到满足，因为目前的应用程序迁移还只能执行简单的将一个应用程序迁移至一个新云中之类的功能。

　　到目前为止，云中的云计算应用程序迁移一直都集中在虚拟数据中心之间或私有云与公共云环境之间进行应用程序的迁移，如Amazon的弹性计算云、Rackspace公司以及Savvis公司。还有一些基于公共云服务的公司，他们正致力于将应用程序迁移至私有云或虚拟数据中心以达到节省成本的目的。还有一些公司则致力于实现在公共云之间的应用程序迁移，以实现在较低成本代价下的更好服务水平协议和/或性能。

　　那么在不同云计算环境中迁移应用程序都有着哪些隐忧？

　　在传输过程中的数据迁移和加密问题，以及何时数据到达目标云环境中。建立网络以便于在源云环境中保持某种关系，并准备连接至由目标云环境所提供的不同网络选项。

　　在本身即是一个完整系统的应用程序周围，也充斥着各种各样的工具和流程。当应用程序迁移至目标云时，你可能需要根据目标云所提供的组件、资源对应用程序的架构重新进行设计。

　　可采用各种各样不同的平台即服务产品来构建应用程序，其中包括Windows公司的Azure，Google公司的应用程序引擎以及Force.com。除了个别Windows Azure的特例之外，你使用大多数平台所开发的应用程序基本不支持跨平台兼容性。如果你在Google公司的应用程序引擎上进行开发工作，那么你的应用程序就必须基于Google应用程序引擎而正常运行。

　　而诸如Amazon之类的公共云也允许你开发应用程序。这类似于在你的数据中心或私有云中进行开发工作，但是公共云对你在开发过程中所使用的资源和组件添加了一定的限制。当你试图将应用程序迁移至数据中心的生产状态或另一个云计算环境中时，这就有可能增加测试工作的难度，同时产生无法预知的问题。

　　在数据中心中开发的应用程序可能会、也可能不会很容易地迁移至目标云环境。大量的应用程序使用了第三方软件，如数据库应用程序和生产力应用程序。如果无法访问应用程序的源代码，当需要进行变更时，专用的第三方应用程序就很难迁移至云计算环境中。

　　云计算应用程序迁移的并发症为什么在云中的应用程序迁移是如此的困难？在传统的应用程序开发中，我们的开发人员完全掌控了他们所需的一切资源和信息：一台物理服务器、一个操作系统、所需的内存空间、磁盘存储系统、网络配置、补丁以及运行时系统（如Java）。一切皆在掌控中。

　　但是当服务器整合出现时，我们对应用程序环境的概念就有所改变。我们拥有一个仍在开发人员掌控中的应用程序环境，个人物理服务器。管理程序为我们提供了硬件和该环境中所有其他的一切资源与信息，这样我们的操作系统、中间件以及应用程序仍旧拥有着他们所需的一切。

　　但是，当我们来到了云计算时代时，都是由云计算供应商来选择操作系统、管理工具、网络架构、存储系统以及虚拟机配置。所有这些都是你进行开发工作的最基本条件，而你对进行应用程序开发工作和部署工作的环境失去了大部分的控制。如果你想要把你的部分应用程序迁移至一个云环境，那么你就必须让它们能够在另一个环境中正常工作，而这个新环境往往与这些应用程序上一次所部署和开发的环境大相径庭。

　　由云计算供应商所作出的决定往往会影响你在其云计算环境中的所能实现的功能。例如，一个云计算供应商可以决定采用廉价的磁盘驱动器，在虚拟层使用大NFS共享或iSCSI共享，而这恰恰就为你的虚拟机的性能、保护等级和原始存储容量设置了瓶颈。通常情况下，作为用户的你是无法对此说三道四且必须忍受。

　　再让我们来看看Amazon。这一公共云计算的引领者已决定了你的虚拟机的每一个接口都要配有一个网络适配器。它也不支持第2层连接或广播和多点传送。当你进入这些类型的环境中，你的应用程序设计受限于云计算环境的资源，当然你也可以访问在这种情况中的网络。另外一个例子则进一步说明了在不同层次上各种功能是如何影响你将应用程序迁移至云和在云之间进行应用程序迁移的能力。你已选择MySQL作为你应用程序的数据库系统。你可以使用MySQL实现的功能之一就是数据库复制——即两个数据库实例保持同步。MySQL的复制过程使用了多点传送作为低层次以太网的一部分，以实现两个数据库实例之间的通信。如果你希望在Amazon上运行你的应用程序，并复制数据库，那么你就遇到了一个棘手的问题：Amazon在其网络层不支持多点传送。

　　所以您该如何解决这个问题？

　　你可以在你的应用程序中使用一个不同的数据库，或者你也可以采用不同的复制功能，但是那可能会影响到MySQL或需要通过应用程序处理该问题。无论采用哪种方法，如果你正考虑互操作性和在云之间迁移应用程序，你还必须考虑你整个软件栈在目标云计算环境中由顶至底的集成。

　　目前的挑战在于你可能不知道你应用程序栈组件和云环境本身部件之间的依赖关系。使用云计算服务本身就蕴含着巨大的价值。但是如果你要花费大量的精力、如果它需要你承担大量的维护和支持任务，那么你因为使用云计算而获得的收益就将大打折扣。

　　便于在云中进行应用程序迁移的工具鉴于环境间的差异，有些客户可能不希望在目标云环境中通过艰苦卓绝的过程而使其应用程序能够正常工作。但是如果我们能为新的云环境中的虚拟机提供正好是它所需要的东西——独立的管理程序、云计算环境，那么应用程序迁移的工作就会比较容易了。这正是CloudSwitch和Racemi所提供的产品。

　　CloudSwitch的云分离技术有助于实现多应用程序的迁移工作，该技术是一个在云计算供应商管理程序和最终用户操作系统之间自动运行的虚拟技术层。该虚拟层为虚拟机提供了它所需要的信息——无需向云计算供应商提出任何特殊要求——并以客户的名义运行以保护和隔离云中的环境。当使用CloudSwitch时，无需对应用程序做特殊的修改；它对应用程序进行映射就如同它在目标云计算环境中运行一样，而事实上它维持了与源云环境中完全一致的配置。

　　与CloudSwitch相比，Racemi则另辟蹊径以实现应用程序迁移。其方法是占据一台在某一环境中（数据中心或云环境）的物理或虚拟的服务器，然后将其部署在一个目标环境中（数据中心或云环境）。Racemi应用程序迁移产品的一个重要组成部分是一个管理设备，它可访问之前所占据的服务器环境和目标服务器环境，并开始这两者之间的映射过程。一旦这种映射过程完成后，占据-部署工作也完成，而应用程序也已被迁移至目标环境。

　　云计算应用程序迁移服务应用程序迁移在混合云中也是一个相当大的问题，而当你希望将一个应用程序从你的数据中心迁移至公共云时，这可能就不再是一个问题了。但是，你可能仍然会遇到上面所讨论的一些问题。

　　与处理潜在不兼容的云计算应用程序编程接口相比，应用程序迁移所涉及的内容要更为广泛。如果你的源云环境和目标云环境在管理程序、操作系统、存储系统和网络配置以及驱动器等方面存在着差异，那么在应用程序栈的每个层次都存在着潜在的问题。

　　当你试图进行应用程序迁移和创建云计算环境时，你需要对云计算环境间的差异做一次彻底的调查，审查你的应用程序架构以确定它们是否可以合理匹配。在本系列云计算应用程序迁移的第二部分中，我们将为那些困难的迁移实例提供一些可能的解决方案。