针对遗留应用的云实施方法

遗留应用迁移

专注于遗留应用的云实施方法假设了两件事情：公司的业务运行在应用上，其次，它已经这样运行了很长一段时间——因此遗留是重点。

将遗留应用迁移到云的常见方法，是根据单个应用的需求做出云实施决策。然而，单个应用的评估无法脱离现实进行。还必须考虑用户和企业的需求。例如，在没有充分考虑用户与应用是如何交互的情况下，将客户端—服务器应用迁移到云端，用户的焦虑将会很高，生产力可能会受到影响，这可能导致未来的应用迁移面临风险。在理想的情况下，应用迁移项目将在很大程度上对用户不可见。

应用架构

虽然应用架构是技术考虑因素，但是当将这些应用迁移到云时，对用户也是有影响的。例如，一个传统的基于客户端-服务器的ERP系统在许多公司中仍然在使用。简单地将该应用推送到云--有时称为“直接迁移”操作——如果迁移的同时，没有适当的连接决策，可能会给用户带来灾难性的后果。大多数数据库应用无法应对网络延迟，仅将客户端-服务器应用的服务器端迁移到云，将增加延迟，通常超出可容忍的级别。

为了解决这个问题，你可以考虑在云供应商环境中部署远程应用访问工具，比如Citrix或Microsoft的远程桌面服务，这样所有的运营都保持本地化，至少从应用的角度来看。这样做确实会增加云迁移的成本和复杂性，因此你需要评估云总体TCO成本，以确保这些附加的服务不会导致开支的净增。

要明确的是，只有当有明显的好处时，我才建议将遗留应用移动到云。这些类型的应用是使用私有数据中心设计的，一般来说，在云中重建这么多的周边基础设施的需求，往往会抵消成本和简易化的好处。 也就是说，对许多人来说，仍然有好处——从可操作性经济，简化的提高，到即时的可扩展性——因此，你需要明确你的流程。

决定迁移流程

要将遗留应用迁移到云，你可以简单地复制和粘贴现有的应用环境，也可以从云供应商处，全面重建环境。如果部署速度是你的主要关注点，将本地虚拟机复制到云端，并在供应商处重新启动它们，会带来最佳结果。再强调一次，由于周边基础设施，可能会带来额外的复杂性。

然而，遗留应用的迁移通常也是很好的清理机会，确保应用操作环境符合当今的最佳方案，而不是部署应用时的最佳方案。

你应该在云中重建应用服务，还是将其从本地环境中复制出来，哪个更有意义。预算和企业目标将帮助你明确此步骤是否有意义。

迁移到云或不迁移到云

任何云实施方法都需要你决定哪些应用要迁移到云，以及迁移的顺序。很少有企业能够简单地将所有应用一次性迁移，因此必须有一些优先级排序。那么，应该从哪里开始?

容易实现的目标

从对企业影响不大的容易实现的目标开始。找到不经常使用或仅很少使用的，且不是任务关键型的服务。先迁移这些，来帮助你和你的员工了解这个流程，并学习可应用于更关键工作负载的经验。通过此过程，你将了解云供应商是如何支持你的工作负载，这样你可以在下一步的应用迁移时，做出适当的调整。

考虑SaaS

尽可能地向SaaS供应商迁移合适的服务。例如，如果你使用Exchange，请考虑迁移到Office 365或类似的供应商。对于许多公司来说，运营本地协作环境不再有意义。但是，也有例外。如果你正在运行高度自定义的环境，确保你执行功能分析，明确可能会丢失的功能，然后再决定公司是否可以失去这个功能。如果不行，找到变通方法或留在本地。

同样的，你也可以考虑用云替换部分的本地数据分析服务。由于许多基于云的报表服务能够扩展到几乎无限的容量，所以你不用担心本地计算和存储资源。

什么应该留在本地

最后，你的云实施战略必须考虑哪些应用需要留在本地环境中。基础设施支持服务，比如DNS、DHCP(动态主机配置协议)和打印服务器需要保留在本地，你需要至少在本地保留一个或两个域控制器来进行身份验证。

不过，除了这些基本应用之外，考虑将特别任务关键型、敏感或高度监管的应用保留在本地。即使你能够找到一个有能力的云供应商，也有许多企业倾向于将这些服务作为风险管理战略的一部分在本地控制。然而，随着云供应商持续部署越来越强大和安全的环境，这也开始发生改变。随着时间的推移，与云部署相关的安全性，数据位置和监管问题将成为过去。

一般的问题都能在这里解决。

一般的问题都能在这里解决。