企业把应用迁移至云已成为业界的一种常态，当然为什么不这么做呢?在一个数据中心内，运行的应用会疯狂吞噬掉存储空间和网络带宽等资源，而云(如阿里云)往往是一个能够减少部署重量级服务器且更具成本效益的替代解决方案。一些应用(例如电子邮件以及其它的通信应用)是很容易就实现云计算迁移的。但是，云并不是一个万能的平台。

　　首先，企业用户应当非常谨慎地对待那些包含敏感数据的应用程序。此外，管理员们还需确保应用程序在云中的运行性能与它们在内部部署中的表现基本一致。最后，应当明确谁拥有启动一个新的虚拟机的权限，这将有助于确保云成本处于企业的可控范围内。

　　为云迁移选择正确的应用程序，在应用程序在云中启动运行之后正确地管理它们，这两者是同等重要的。当把应用程序迁往云平台的候，为了确保稳固的云应用管理，有五个重要的问题要问。

　　1、云应用的最新发展趋势是什么?

　　容器技术占据了云技术发展的主导地位，而Docker容器则更是走在了这个队伍的前列。原来的dotCloud(Docker)是一个开源容器平台，它可用于开发和运行应用程序。它的应用程序可移植性已经引起了众多供应商的注意，其中包括了谷歌、AWS、微软等等。Joyent公司于近期推出了Docker，并将其基于容器技术的基础设施与Docker容器进行组合。谷歌还进一步推动了其Docker与谷歌容器引擎测试版的协作关系。该公司之前发布的Kubernetes就是一个开源的容器管理器。随着谷歌推出了最新的容器开发技术，云用户们正期待着AWS能够紧随其后。希望在云上开发新应用程序的企业应当关注Docker的技术创新以确定它们是否满足他们的需求。

　　2、我是否需要为云重新设计我的应用架构?

　　并不是所有的应用程序都适合云的。在应用程序正常运行在云平台上之前，企业可能需要对原有的应用程序进行重新架构设计。为云化而进行应用程序的重新架构设计可以让那些企业充分利用云敏捷性、弹性和可扩展性的优势。云的本质灵活性可以有助于提高应用程序的性能和投资回报。

　　但是为云化而对应用程序进行重新架构设计并不像在公园里散步一样。有些应用程序可能从一开始就没有被好好设计，它们可能由于糟糕的编码而会表现得不稳定。通常情况下，企业会被迫重写代码和重新开发应用程序以便于让应用程序能够在新的环境中稳定运行。

　　3、我应当如何对云应用性能进行监控?

　　对于任何的云应用来说，性能监控都是必不可少的。连续监控可允许管理员们立即处理任何的问题或中断，从而避免发生进一步的灾难事件。很多公共云供应商都提供了他们自己的监控工具。谷歌云监控就是一个可以帮助管理员找到谷歌云中性能问题的一个选择。亚马逊网络服务的CloudWatch则是监控AWS应用性能指标的另一款工具。另外还有无数第三方的应用程序监控和管理工具可对原生工具进行功能上的拾遗补缺。除了监控工具以外，管理员应当定期测试应用程序并研究其运行性能趋势。

　　4、云应用迁移的关键是什么?

　　理解企业把应用程序迁至云的原因是很容易的。但是，在迁移应用程序之前，企业的IT部门必须确定应用程序已经做好了云化的准备。为了把风险降到最低，可首先选择迁移更适宜的应用程序，其中包括了非关键任务的工作负载。

　　实现成功云应用迁移的下一步工作就是选择应用程序在云中的位置。而这最终取决于应用程序的用例以及管理员是如何想要使用它。把应用程序迁往软件即服务是否是最合适的?在其中，SaaS供应商可以托管整个应用程序。或者，一个具有周期性或高峰使用时间的面向客户应用程序是否能够被迁往公共云以便于充分利用其可扩展性?

　　最后，企业需要考虑成本和安全性方面的因素。如果你不够小心，云和云迁移很有可能成为你的预算杀手。云供应商所提供的成本计算器将有助于用户确定应用程序的迁移成本，但那并不总是百分之百准确的。对于那些无法实现预期目标的云供应商，所有的企业用户都应有一个供应商备份计划。

　　5、什么样应用程序是适合云的?

　　确定哪些应用程序适合云化最终取决于你计划使用哪一种云平台。在大多数情况下，私有云所具有的更多控制权和更高安全性的优势吸引着那些希望控制关键任务应用程序的管理员。虽然私有云能够确保数据保留在企业组织内部，但是它却不一定能确保数据的安全性。访问和身份管理(例如身份验证和用户授权)是确保只有特定用户才能够访问他们数据的关键，即其它无关人员是无法访问的。综合私有云的控制优势和按需把“突发”或周期性工作负载迁往公共云的灵活能力的混合云正越来越受到企业用户的青睐。

　　但是什么样的应用是适合云的呢?通信和协作服务是固定的选项。企业经常会把电子邮件和协作应用程序迁往云以实现成本节省，从而把他们的时间和管理精力更多地集中在业务的其他方面，例如开发工作。

　　本文出自：http://www.searchcloudcomputing.com.cn/showcontent_86568.htm