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

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

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

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

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

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

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

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

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

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

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

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

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

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