企业应用直接迁移上云：应遵循的5条规则（以及可打破的1条）
考虑将企业应用迁移到公有云的组织，应确保同时迁移这些应用在数据中心所依赖的应用交付服务。此外，云迁移也为组织梳理和优化安全与访问机制、提高云端应用流量的可见性，以及构建可靠的灾难恢复计划提供了契机。
简介
对许多组织而言，将企业应用迁移到公有云颇具吸引力。这样可以摆脱运行大规模IT基础设施所产生的固定成本和相关资产，包括部署了不同代际、可支持性各异的设备且成本高昂的数据中心。这些服务器在支撑企业运营的同时，也会消耗电力、产生热量，并需要成本高昂的支持合同。管理IT基础设施的生命周期、维护和物理托管需要投入专业技能、时间和预算，可能会分散IT组织对其总体使命的关注，即提供支撑业务运营的应用。
摆脱这些运营难题和财务负担，转而采用只需一次简单的API调用即可停用旧服务器或应用的新模式，通常在财务和运营方面都更为合理。如果不再需要管理支撑IT运行的基础设施，就能将更多精力投入应用的安全性、性能和可用性，而这些应用正是IT为企业创造实际价值的载体。
但在实现虚拟化、免维护基础设施这一理想状态之前，需要先确定将应用迁移到新环境的适当方式。将应用迁移到公有云时，有多种方案可供选择。可以针对云环境彻底重新设计应用架构，从而打造简洁流畅的用户体验，但这一过程通常需要投入大量时间和人力。也可以直接将数据中心内运行的应用迁移到公有云，而无需对设计或平台进行大幅更改。
探索这种“直接迁移”模式有很多充分的理由：据估算，其成本可降低约90%，1而且几乎总能大幅缩短迁移时间；对于生命周期有限的应用，在某些情况下，重写并不划算。不过，要成功完成“直接迁移”，需要遵循几条规则，同时还必须打破其中一条。
规则1：将服务器视为牲畜，而非宠物
我们先从一条需要打破的规则说起。“像对待牲畜一样对待服务器”这一理念通常被视为云架构的固有原则。如果某个服务器实例运行异常，不要浪费时间修复，直接将其终止并重新部署。不要升级操作系统或软件，只需部署新实例并终止旧实例。这是一条可靠的建议。但如果要将一个在数据中心的精心呵护下成长起来的应用迁移到严酷的公有云环境中，这种做法可能会适得其反。
大多数企业应用在设计时并未考虑云架构和云方法。它们在本地保存状态，底层服务器启动后需要一段时间才能上线，而突然关机很可能导致数据不一致。您需要像对待备受呵护的宠物一样对待它们，而不能像对待牲畜一样。
迁移到云环境的企业应用仍需要与在数据中心时大致相同的维护、管理和应用交付服务（安全性、可用性和性能）。即使是这些应用所需的基本负载均衡服务，也比专为云环境设计并在云中构建的应用所需的服务更复杂。要让应用在云中顺利运行，还需要将其配套基础设施一并迁移。好在大多数基础设施组件目前已可在所选的公有云中使用，而且组织现有的知识、技能乃至策略也可以在云中复用。
规则2：迁移应用，而不是把混乱一并带走
大多数企业IT的演进过程，就像配线架上的布线一样。您一定见过：起初整洁美观、设计合理、实施到位。（不妨看看reddit.com/r/cableporn，其中有一些非常值得借鉴的布线方案。）然而，不到一年，迫于时间和紧急需求，人们开始在这里走捷径，在那里用错颜色（“红色是DMZ专用的，真是的！”）。短短3年后，机柜里就会塞满没有标签、五颜六色的以太网线，乱成一团，唯有全部拆除并重新布线。
迁移到云端，是摆脱杂乱配线架、重新掌控安全和访问管理的良机。虽然需要随应用一起迁移部分基础设施服务，但也应借此机会梳理应用和网络访问策略，使其更合理、更直观、更有条理。
规则3：牢牢掌控身份
在云环境中管理用户身份，可能是可以实施的最重要控制措施。将部分应用迁移到云端、停用部分应用并改用软件即服务（SaaS），或彻底重写部分应用时，需要就用户身份管理做出几项关键决策。
运行多个身份服务可能会带来沉重负担、风险和效率问题，还可能重新引入原本应消除的部分复杂性。身份管理需要集中化，但访问权限必须通过联合身份机制扩展到所有必要位置。相关技术可与身份服务（通常为Microsoft Active Directory）集成，并使用SAML和OAuth等协议将其扩展到云和SaaS服务，使应用能够通过单一身份源对用户进行身份验证，而不必依赖本地身份。
但随着应用日益分散，用户也变得更加分散。通过增加可识别用户位置和设备的控制措施，并结合双因素身份验证和一次性密码选项，可以帮助防范社会工程攻击及其他类似的组织信息安全入侵企图。
规则4：通过监控消除“云焦虑”
云环境对多层基础设施进行了抽象，使您无需直接关注这些层面。这是一件好事，因为您不再需要维护和支持物理基础设施。不过，在将相关责任外包的同时，也会让渡直接控制权。
为应对这一问题，需要更密切地监控应用性能。加强监控并提供相关且可操作的信息，有助于简化故障排除和容量规划。
另一个潜在好处是可以消除企业内部的一些顾虑。对云中安全性和性能的担忧，部分源于公有云的多租户特性及其与公共网络连接的特点，也源于企业认为自身失去了控制。加强对企业应用和行为的监控，可以显著推动这一迁移进程，并消除采用云服务时的心理障碍。
规则5：始终聚焦灾难恢复和业务连续性策略
灾难恢复和业务连续性（DR/BC）是构建良好数据中心基础设施和应用设计的关键要素。使用公有云并不意味着无需再承担保障应用持续、安全运行的责任，但确实可以降低采用DR/BC服务的门槛。
在公有云服务出现之前，建立物理灾难恢复站点可能需要投入大量成本，并经历较长的准备周期。如今，只需几分钟，即可访问位于另一大洲、由其他供应商采用不同底层技术提供的基础设施。不过，尽管基础设施更易于获取，构建高可用性应用仍需要进行大量规划和配置。
尽管有关灾难恢复和云基础设施的文档非常丰富，但用于规划和设计灾难恢复与业务连续性（DR/BC）的有效框架可以归纳为几个关键决策和关注事项。
首先，需要考虑风险和投资回报率（ROI）。采用覆盖多个区域和多个供应商的全面解决方案，是否值得投入相应的时间和成本？虽然云服务可以降低采购成本，但维护稳健的灾难恢复和业务连续性（DR/BC）服务仍会产生运营成本。
其次，需要考虑如何存储和分发事务数据，并确保数据一致性。这个问题已有成熟的认识，但可能仍是构建跨地域高可用应用最困难的环节。许多解决方案要求各地点之间具备高带宽、低延迟的连接，或者采用更为复杂的设计，例如企业应用很少采用的最终一致性模型。大多数企业尚不具备在不同云提供商之间建立低延迟连接的能力，但一些可行方案正逐渐出现。
第三个关键挑战是管理应用访问。对于大多数双活或主动灾备设计，使用DNS根据可用性、距离或性能将流量定向到合适的数据中心，通常能较好地兼顾简便性和功能性。尤其是在考虑采用多云模式，并使用不同云服务商来承载应用时，更是如此。使用BGP等网络协议也可能是一种选择，但通常会增加复杂性和一定风险。另一种选择是使用部署在云外但邻近云环境的位置中的设备或服务，直接对跨云网络流量进行负载均衡或切换。这就引出了最后一条规则。
规则6：更贴近云端
大多数将企业应用迁移到云端的中大型组织都希望在云基础设施中构建安全的私有访问。虽然通过公共互联网运行VPN解决方案可能适合部分组织，但许多组织会采用更直接的专用连接来接入云提供商。由服务提供商交付的这些专用链路可提供隐私保护、带宽保障，并且延迟低于公共互联网连接，但成本也更高。
如果需要与多个云建立弹性连接，就必须配置多条链路。或者，如果需要将云连接到某些基础设施组件，但现有数据中心在地理位置或逻辑上距离云网络对等互连点太远，又该怎么办？
越来越多的组织开始考虑将设备托管在云连接环境（通常称为云交换中心）中，以便高速连接多个云提供商。这样可以将部分IT资产部署在非常靠近云虚拟基础设施的位置，从而在云中运行的应用与托管在共置数据中心的存储或安全设备等基础设施组件之间建立专用的低延迟连接。此外，这种部署方式还可充分利用现有IT设备，并将网络和安全控制扩展到云基础设施。
最后，将设备托管在云交换中心，可在企业数据中心、云基础设施与公共互联网的交汇处部署控制措施。您可以扩展或创建业务所需的安全策略，增强对应用数据流的控制和可见性，从而改善整体安全态势，并有助于优化和标准化访问与安全服务。
结论
将企业应用直接迁移到公有云，可以帮助组织节省成本、提高灵活性，并快速进入云环境。但要成功完成迁移，关键在于认识到企业应用仍需要配套基础设施。
确保应用所依赖的安全、性能和可用性服务部署在云中，有助于传统企业应用持续运行，并为用户提供满意的体验。内置监控功能可帮助快速发现问题，并缓解应用所有者在服务迁移到云端时可能产生的顾虑。
直接迁移还可以成为契机，帮助重新建立稳健的控制机制、优化访问权限并改善业务连续性，从而提高迁移的整体投资回报率。最后，如果您使用多个公有云，可考虑将资源托管在云交换中心。这样有助于提升性能，并通过单一控制点统一安全和访问策略。
1 Knapp, Kristin，《实现目标的手段》，Modern Infrastructure，2015年7月/8月， http://docs.media.bitpipe.com/io_12x/io_125304/item_1181222/MI_JULY.pdf
发布于2016年11月29日