考虑将企业应用迁移到公共云的组织应确保也将其应用所依赖的应用程序交付服务迁移到数据中心。 此外，云迁移提供了组织和合理化安全性和访问、了解基于云的应用流量以及设计强大的灾难恢复计划的机会。

对于许多组织来说，将企业应用迁移到公共云是一个非常有吸引力的提议。 它使他们能够处理运行大型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 服务的运营成本仍然存在。

其次，您需要考虑如何存储和分发交易数据并保持其一致性。 这是一个很好理解的问题，但也许是构建地理分散、高可用性应用最困难的部分。 许多解决方案需要不同位置之间的高带宽、低延迟连接，或者更深奥的设计，例如企业应用很少采用的最终一致性模型。 在不同的云提供商之间建立低延迟连接超出了大多数企业的能力范围，但一些选择正在变得可用。

第三个关键挑战是管理对应用的访问。 对于大多数主动-主动或主动-DR 设计，使用 DNS 根据可用性、接近度或性能将流量引导到最佳数据中心代表了简单性和功能性的最佳平衡。 当您考虑采用多云模型，为您的应用使用不同的云供应商时，尤其如此。 使用 BGP 等网络协议也可能是一种选择，但这通常会增加复杂性和一些风险。 另一种选择可能是使用放置在云外部但靠近云的位置的设备或服务简单地在云之间进行负载平衡或切换网络流量 - 这将我们引出最后一条规则。

大多数将企业应用迁移到云的中型到大型组织都希望在其云基础设施中建立安全的私人访问。 虽然通过公共互联网运行 VPN 解决方案对某些人来说可能是合适的，但许多组织将使用更直接、专用的连接到云提供商。 服务提供商提供的这些专用链接提供了隐私性、保证的带宽和比公共互联网连接更低的延迟，但需要付出代价。

如果您需要与多个云建立弹性连接，则必须配置多个链接。 或者，如果您需要将云连接到某些基础设施组件，但现有的数据中心在地理上或逻辑上距离云网络对等点太远，该怎么办？

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

最后，通过在云交换中进行共置，您可以将控制置于企业数据中心、云基础设施和公共互联网的连接点上。 您可以扩展或创建业务所需的安全策略，并对应用数据流进行更好的控制和可视性，从而改善您的整体安全态势并帮助您合理化和标准化访问和安全服务。

将企业应用迁移到公共云可以帮助组织节省资金、提高灵活性并快速进入云环境。 然而，认识到企业应用仍然需要周围的基础设施对于成功迁移至关重要。

确保您的应用所依赖的安全性、性能和可用性服务存在于云中，将使您的传统企业应用保持运行并使您的用户满意。 内置监控将使您能够快速发现问题区域，并有助于减轻应用所有者在其服务迁移到云时可能感受到的焦虑。

提升和转移的行为还可以作为重新建立强大控制、合理化访问和提高业务连续性的催化剂，这将提高迁移的总体投资回报率。 最后，如果您正在利用多个公共云，请考虑在云交换中进行共置的好处，这可以提高性能并允许您从单一控制点标准化安全性和访问策略。

¹ Knapp, Kristin，《达到目的的手段》，《现代基础设施》，2015 年 7/8 月， http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf 。