考虑将企业应用转移到公有云的企业，应确保将其应用所依赖的应用交付服务转移到数据中心。此外，云迁移还提供了一个机会来组织安全和访问并使其合理化，获得基于云的应用流量的可见性，并可以构建一个强大的灾难恢复计划。

对于许多企业来说，将企业应用转移到公有云上是一个极具吸引力的提议。迁移到云可以让企业免除运行大规模 IT 基础设施所涉及的固定成本和资产，包括昂贵的数据中心，其中挤满了不同年代和不同支持水平的设备。当这些服务器在运行企业应用时，它们也在消耗电力，产生热量，并需要昂贵的支持合同。管理 IT 基础设施的生命周期、维护和物理空间需要投入技能、时间和预算，这可能有悖于 IT 团队的总体任务，即提供运行业务的应用。

摆脱这种运营上的负担和财务上的消耗，迎来一个用便捷的 API 调用（常常兼具财务和运营意义）即可让陈旧的服务器或应用退役的全新环境。如果不再需要管理运行 IT 的基本基础设施，则企业可以更专注于应用的安全性、性能和可用性，这才是 IT 真正的价值所在。

但在实现这个虚拟化、免于维护基础设施的理想环境之前，企业必须找到一种将应用转移到新位置的最佳方式。将应用迁移到公有云涉及一些选择：可以为云环境完全重新设计应用架构，这可以带来顺畅的用户体验，但往往耗时耗力。或者，直接将运行于数据中心的应用放到公有云中，免去大规模的设计或平台更改。

探索这种“平移”模式是出于各种合理原因：据估计，它的成本要便宜 10 倍¹，而且速度更快。在某些情况下，重写一个寿命有限的应用根本得不偿失。不过，如果要成功地进行“平移”迁移，企业应该遵循几项规则，还要打破一项规则。

我们先从打破说起。像牛一样对待服务器这种概念常常被视为云架构的内在因素。如果一个服务器实例的功能不正确，不要浪费时间去修复它，要做的是舍弃它并重新部署。不要升级操作系统或软件；只要部署新的实例并终止旧的实例。这是个可靠的建议。但是，如果是试图将一个在数据中心这种安稳环境中创建和开发的应用转移到公有云这种变化多端的情况，这种想法可能会适得其反。

大多数企业应用在设计时并没有考虑到云架构和方法理论。它们在本地保持运作，在底层服务器启动后上线提供服务，而突然发生关机可能会导致数据不一致。您需要将它们视为要精心呵护的宠物，而不是牛。

移植到云环境中的企业应用需要得到与在数据中心相当的照顾、管理和应用交付服务（安全性、可用性和性能）。即使是这些应用所需的基本负载均衡服务，也会比在云中设计和产生的应用所需的服务更复杂。如果想让应用在云中安稳发展，则需要将应用的支持性基础设施也一起转移。好在大多数基础设施组件现在可以在您选择的公有云中使用，而且还可以在云中重新使用系统化知识、技能、甚至是策略。

大多数企业 IT 的演变遵循一条类似于配线架的路径。就是大家心中所想的，起初很顺利，设计很周全，执行得也不错。（在 reddit.com/r/cableporn 中了解一些真正鼓舞人心的配置。）然而，在一年之内，由于时间和紧迫性的需要，这里走了捷径，那里使用了错误的颜色（“糟糕！红色是用于 DMZ。”）。在短短的三年里，这个机柜已经退化成了一个没有标签、颜色杂乱的以太网布线的死结，拆除所有电缆并重新配置是唯一出路。

迁移到云端是摆脱杂乱无章的配线架并夺回安全和访问权限管理控制权的机会。虽然需要将一些基础设施服务与应用一起转移，但也应该利用这个机会来合理化、可见性和组织应用和网络访问策略。

可以实施的最重要控制措施是要在云环境中管理用户身份。将一些应用转移到云，让一些应用退役，转而使用软件即服务 (SaaS) 产品，或者完全重写一些应用时，需要对用户身份管理做出几个关键决策。

运行多个身份服务可能繁琐、有风险且低效，而且会带来复杂性，而这点本来是企业试图避免的。身份管理需要集中化，但访问必须联合到所有需要的位置。与身份服务（通常是 Microsoft Active Directory）集成的技术，使用 SAML 和 OAuth 等协议将其扩展到云和 SaaS 服务中，使应用能够通过单一来源对用户进行身份验证，而不是依赖本地身份。

但正如应用变得更加分散一样，用户也变得如此。增加识别用户位置和设备的控制措施，结合双重身份验证和一次性密码选项，可以抵御社会工程和类似的有损于企业信息安全的企图。

云环境可以让企业不必直接关注多层基础设施。这是一件好事，因为如此一来，企业如今便不需要为物理基础设施提供服务和支持。然而，这种责任的外包也伴随着直接控制权的让渡。

为了应对这种情况，企业需要做的事情之一是更仔细地监测应用性能。添加更好的监控方法，提供相关和可操作的信息，可以更容易地进行故障排除和容量规划。

另一个好处是可以消除企业内部的一些担忧。关于云安全和性能的问题部分来自于公有云的多用户和公共连接方面，但其中也牵扯对控制权丧失的担忧。对企业应用和行为进行更有利地监控，可显著利于这种迁移，并消除对于云采用的担忧。

灾难恢复和业务连续性 (DR/BC) 是良好数据中心基础设施和应用设计的主要内容。使用公有云并不意味着企业可以不负责应用的运行和安全。然而，它确实降低了 DR/BC 服务的准入门槛。

在公有云服务出现之前，创建一个物理灾难恢复地点可能涉及大量的成本和筹备时间。现在，企业可以在几分钟内使用不同的底层技术从不同的供应商访问另一个大陆的基础设施。不过，尽管可以更加容易地获得基础设施，但创建一个高可用的应用仍然需要大量的规划和配置。

虽然有大量的文件专门讨论灾难恢复和云计算基础设施问题，但一个良好的 DR/BC 规划和设计框架可以简化为几个关键的决策和关注点。

首先，需要考虑风险和投资回报 (ROI)。所追求的终版多区域、多供应商解决方案是否值得投入时间与成本？虽然云服务可以降低购置成本，但维护强大的 DR/BC 服务的运营成本是无法避免的。

第二，需要考虑如何存储和分发交易数据并保持其一致性。这是一个众所周知的问题，但也许是建立地理上分散的高可用应用的最难部分。许多解决方案需要在不同地点之间建立高带宽、低延迟的连接，或有着更深奥的设计，如企业应用很少接受的最终一致性模型。在不同的云供应商之间建立低延迟的连接不在大多数企业的能力范围之内，但目前已有一些选择。

第三个关键挑战是管理对应用的访问。对于大多数 active-active 或 active-DR 设计来说，使用 DNS 来引导流量到基于可用性、邻近性或性能的最佳数据中心，代表了简单性和功能的最佳平衡。当考虑采用多云模式，为应用使用不同的云提供商时，这一点尤其正确。使用 BGP 等网络协议也可能是一种选择，但这通常会增加复杂性和一些风险。另一个选择可能是简单地使用放置在云外但靠近云位置的设备或服务进行负载均衡或跨云交换网络流量，由此便引出我们的最后一项规则。

大多数将企业应用迁移到云中的中型到大型企业都希望在云基础设施中建立安全的专有访问。虽然在公共互联网上运行 VPN 解决方案对一些企业来说可能是合适的，但许多企业将使用更直接的专用连接与云提供商进行连接。这些由服务提供商提供的专用链接可以提供隐私、有保障的带宽和比公共互联网连接更低的延迟，但凡事有利便有弊。

如果需要弹性连接到一个以上的云，则必须预配多个链接。或者，如果需要将云连接到一些基础设施组件，但现有的数据中心在地理上或逻辑上离云网络对接点太远，又该如何？

越来越多的企业正在考虑将设备放在与云连接的环境中（通常称为云交换），这些环境提供与多个云提供商的高速连接。这使企业可以将一些 IT 资产托管在离云虚拟基础设施非常近的地方，让云中运行的应用和基础设施组件（如存放在主机托管中心的存储或安全设备）之间有专用的低延迟连接。此外，这种安排能够利用现有的 IT 设备，并将网络和安全控制扩展到云基础设施。

最后，在云交换中联合定位可以在企业数据中心、云基础设施和公共互联网的交界处进行控制。企业可以扩展或创建业务所需的安全策略，实现对应用数据流的更大控制和可见性，改善整体安全态势，帮助合理化和标准化访问和安全服务。

将企业应用平移到公有云可以让企业节省资金，提高灵活性，并迅速进入云环境。然而，认识到企业应用仍然需要外围基础设施，对于成功迁移至关重要。

确保云中存在应用在安全、性能和可用性方面所依赖的服务，将使传统企业应用保持运行和维持用户满意度。构建监控将能够迅速发现问题所在，并在服务转移到云中时，利于缓解应用所有者的焦虑。

平移行为也可以作为一种催化剂，重新建立强大的控制，合理化访问，并提高业务的连续性，这将增加迁移的整体投资回报率。最后，如果企业正在利用多个公有云，请考虑在云交换中心联合定位的好处，这可以提高性能，并允许从一个控制点标准化安全和访问策略。

¹ Knapp, Kristin，“达成目的的方法”，Modern Infrastructure，2015 年 7/8 月 http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf.