将应用程序迁移至云端？ 请先阅读此内容。

云计算环境如今已成为 IT 领域的主导特征，各组织正越来越频繁地将传统的本地应用迁移到云端。 但是将应用迁移到云端不仅仅需要将应用移动到云提供商的虚拟机上。 不同的组织对云迁移有不同的动机，但每个组织都应该考虑一些关键因素，并且肯定有最佳实践来帮助确保云迁移工作的成功。 为了从云迁移中获得最大收益，请提前规划——包括应用架构以及从内部到云的过渡。

云环境的行为与本地环境不同。 这两种环境之间的一些区别是显而易见的，例如计算资源由另一家公司拥有和管理，而不是由内部拥有和管理。 然而，几个最重要的区别并不是技术的功能。 一般而言，云提供商提供的任何技术也均可在现场使用。 云提供的是一种替代的消费模式，而不是一种替代的技术。 换句话说，迁移到云提供商的优势在于计算资源的使用方式，而不是计算资源本身。

云提供商不一定能够复制所有内部部署功能，例如为内部部署硬件设计的数据审计合规性策略。 由于云组件在地理上分散，因此云部署中的延迟通常更严重。 云提供商也面临其他限制。 由于提供商遵守跨客户的标准，因此计算环境的定制存在真正的限制。 例如，很少有云提供商会提供稀有且奇特的计算设备。

但如果一家公司能够在这些限制内运营，云提供商就可以提供大多数公司无法企及的消费能力。 云提供商可能在全球范围内运营数据中心，为企业提供在哪个数据中心定位计算资源的选择。 云提供商还可以吸收固定成本，使得公司只需为实际使用的资源付费。 由于云提供商拥有大多数公司无法比拟的规模经济，因此它可以在系统上进行大量投资以管理和自动化部署。 请注意，这些好处都不是技术性的；相反，云提供商的优势在于消费者可以选择的选项和成本结构。

为了减轻限制并利用云提供商的优势，IT 部门必须改变其部署应用的方式，改变工作流程以充分利用云提供商的相对优势，同时避免依赖云环境处于不利的属性，例如延迟。

节省成本通常被认为是迁移到云端的主要驱动力，但真正的原因往往更加微妙。 大多数动机可分为三类：确定性、生产力和敏捷性。

公共云提供商通过打包技术使其更易于使用来提高确定性，并在此过程中吸收部分 IT 运营风险。 由于提供商维护并负责基础设施，因此组织可以忽略这些问题。 同样，云提供商通常提供工具来洞察 IT 运营，从而提高可视性。 由于公共云成本通常由消费决定，因此组织可以将应用的优势（如收入）与该应用的运营成本更紧密地结合起来。 随着应用的使用范围越来越广，成本也随之增加，但收益也随之增加。 通过将费用从资本转移到运营，就不再需要为采购决策中的未来增长留出空间。 在云提供商级别管理这些不确定性可带来可衡量的利益。

采用公共云的另一个原因是提高生产力。 供应商提供的协作和自动化工具是市场上最先进的工具之一。 此外，不管理基础设施可让 IT 员工专注于业务战略工作，而可以从任何地方管理的精简运营可提高 IT 员工的工作效率。

采用公共云的最后一个原因也许是最引人注目的：敏捷性。 由于云提供商创造了随时可用无限资源的假象，业务努力的速度和方向不再受到 IT 配置限制的约束。 资源可以在几秒或几分钟内部署。 一个项目可以在短时间内使用复杂的计算环境，而不必担心项目结束时硬件的退役。 可以快速部署、扩展和删除applications，而无需担心硬件资产。

虽然云迁移有很多好处，但迁移工作也面临着一些挑战。 障碍和风险因迁移过程发生的阶段而异：迁移之前、迁移期间和迁移后。 提前解决这些障碍和风险可以增加迁移成功的可能性。

迁移前的规划可能是迁移过程中最关键的部分。 由于无法重新构建应用以利用云功能，迁移工作可能会失败。 这也是评估并开始管理应用程序复杂性的好时机。 IT培训也应该在工作开始时就进行。 云部署倾向于孤立的执行和工具激增，早期阶段的规划可以帮助顺利完成迁移过程。

将应用迁移到云端往往比最初计划的花费更长的时间并且更为复杂。 为了尽量减少问题，请从一个小型且相对独立的应用开始，这样遇到的问题的影响就会最小。 从小型应用首次迁移中获得的经验教训可以应用于未来的迁移。

迁移完成后，迁移的长期问题就会显现出来。 可能会出现安全性和合规性问题，通常是因为在云环境中安全边界更难定义。 当新旧系统不仅处于不同的环境中，而且还是在不同的文化中开发时，对传统系统的支持可能会更加困难。 一些组织对云锁定感到担忧，尤其是随着容器的兴起。 最后，预算问题可能是一个问题，因为每个季度变化的云成本很难预测。

评估应用的一种技术是成熟度与位置矩阵。 检查您的应用以确定您需要多少成熟度。 提供竞争差异化或利基的应用可能最好在现场提供。 另一方面，低成本或成本领先的应用（特别是在变更成本方面）通常非常适合云环境。 其他需要考虑的因素包括可扩展性。 假设已经部署了一个新的应用，并且最终可能会扩展到当前负载的 100 倍。 为了保持领先于内部部署的增长，基础设施将需要大幅超额配置，从而为闲置资源引入额外的资本成本。 然而，如果将同一个应用部署在云环境中，成本将随着增长而扩大，并且不需要过度配置。

网络问题也会在决定将哪些应用迁移到云环境时发挥一定作用。 如果应用拥有大量分布式用户，例如广泛的经销商网络或大量远程电子邮件用户，那么内部部署会将所有流量汇集到数据中心。 由于流量已经在互联网上传输，因此应用对延迟并不敏感。 当此类应用放置在云环境中时，网络延迟不会改变，但它会释放本地数据中心的带宽，否则这些带宽将被分布式用户消耗。

与此同时，也有理由将一些应用程序保留在现场。 预期寿命较短的应用可能不值得承担迁移的风险和成本。 一些应用程序依赖于低网络延迟和存储速度，在云环境中的表现可能会更差。 合规性和安全性问题常常是将应用程序保留在本地的原因。 一些审计程序假设需要对系统和数据进行物理访问以验证数据，而其他审计程序则要求应用和操作系统在裸机上执行（即，它们不能在虚拟机上运行）。 随着时间的推移，合规程序将适应云环境，但在很多情况下这还没有发生。 与其承担云中应用合规性审核不合格的风险，不如暂时将这些敏感应用程序保留在本地更有意义。 一些应用程序需要支持传统系统和流程，因此无法重新构建以在云中运行。 这些应用程序也可能是留在本地的候选应用程序。 由于这些原因，某些应用程序的迁移优先级应该低于更适合云环境的应用程序。

applications最好留在本地

• 预期寿命较短的应用程序
• 需要低延迟的应用程序
• 存在合规性问题的应用程序
• 支持旧系统的应用程序

许多组织必须在迁移过程中克服挑战。 需要回答的一个主要问题是如何进行实际的切换？ 一种方法是使用 DNS 解析到本地应用，直到云应用经过彻底测试，然后再更改 DNS 记录以解析到云应用。 DNS 包含一个生存时间 (TTL) 值，允许客户端在一段时间内缓存 DNS 响应。 在转换之前，设置一个较低的 TTL 可能是有意义的，也许只有几秒钟，以便在切换后客户端可以快速解析新的应用。 但这种方法确实存在一些风险。 降低 TTL 会显著增加 DNS 流量以及服务器的负担。 组织可能会忽略 TTL 并缓存比指定时间更长的时间，导致一些用户在切换完成后很长时间仍解析到内部部署应用。 在使用此方法之前，请考虑测试 DNS 基础设施的稳健性。

过渡过程还可以暴露新应用中未在测试中发现的问题。 防范有问题的应用的一种方法是制定后备计划，该计划使得处理在出现问题时能够恢复到内部部署应用。 不幸的是，双向转换使数据同步变得复杂，因此需要更多的前期规划和测试。 一种更复杂的方法是使用称为金丝雀测试的部分转换，即在监控的同时将一部分用户转换到云应用。 随着对应用的信心不断增长，更多的用户（最终是所有的用户）都可以进行转变。 相反，如果出现问题，转换后的用户可以重新使用内部部署应用。 可编程应用交付控制器 (ADC) 可以通过 F5® iRules® 执行金丝雀测试，从而最大限度地降低风险，同时增加过渡期间可供运营团队使用的选项数量。

企业在迁移应用时犯下的最大错误之一就是未能针对云重新构建应用程序。 分配时间来改变应用的结构，以便它可以利用云环境中的差异，从而带来显著的效益。

例如，与内部扩展相比，在云环境中的扩展是微不足道的。 不要设计应用并针对最坏情况负载进行测试，而是将应用设计得精简但可扩展。 当应用的使用范围跨越很广时，没有必要维持较大的占用空间的开销。 相反，先从小处着手，准备扩大规模。 类似地，某些故障（例如电源故障）在云环境中发生的可能性较小，因此不需要为这些故障进行架构设计。

另一方面，云环境引入了在现场通常不会遇到的新限制。 云架构师指出，设计应该将任何虚拟机实例随时发生的故障作为常规处理的一部分进行规划。 在云设置中存储也不同。 内部部署设计通常使用本地块存储。 相同选项在云环境中可用，但不能共享。 本地未共享状态和实例故障的结合可能会导致灾难。 还存在其他存储范例，例如基于对象的存储或键值存储服务。 可以通过重新设计应用来克服云环境的局限性。

某些应用或控制系统保留在现场是有意义的。 许多组织将在内部保留 Active Directory，同时采用联合将身份扩展到云环境。 类似地，ADC 提供许多安全服务来支持应用交付，例如防火墙、Web应用防火墙、DDoS 保护和 SSL/TLS 拦截以及服务链。 ADC 还提供高级流量管理和可编程代理以及身份和访问权限管理。

组织通常将这些应用服务合并到应用外部，因为这些服务不是业务逻辑的一部分，而是操作问题。 为了实现独立于应用发布计划的运营变更，许多企业集中可应用于所有应用的领域专业知识，使用 ADC 作为战略控制点。 然而，云环境改变了这种模式。

云环境中应用交付的早期方法是使用每个云环境中的本机工具复制 ADC 服务。 很快，人们发现云提供商并没有提供相同级别的本机功能，这让组织面临一个选择：要么在云和本地环境之间维护异构应用交付标准，要么将所有应用重新设计为最低公分母。

随着企业扩展到多个云环境，这两种选择都变得越来越不可取。 假设一个组织利用三个云提供商并且还维护一个内部数据中心。 该组织要么必须维护四套 SSL/TLS 专业知识、四套 DDoS 专业知识等等，要么必须对日益脱节（且有限）的基本服务进行标准化。 在额外的云环境中部署一个新应用会产生很大的边际成本，要么需要另一组领域专家，要么需要一套适用于所有现有应用的新标准。

但还有第三种选择，可以在所有环境中提供一致的服务。 F5应用连接器使一组领域专家能够管理所有应用，无论这些应用位于何处。 通过使用现有的 BIG-IP® 硬件或软件设备，组织可以在任何应用前面注入完整的高级应用服务，无论其位于何处，从而为所有应用提供战略控制点，并由一组领域专家进行管理。 此外，应用连接器通过消除所有可见的公共 IP 寻址来提高安全性，从而减少攻击面。 通过将加密密钥集中存储而不是存储在云实例中，组织可以确信其关键加密信息的私密性。 最后，应用连接器允许代理实例自动发现新的工作负载节点，从而提高云部署的效率。

本地应用和云应用之间最大的区别之一是应用状态的存储。 绝大多数情况下，内部部署设计使用本地块存储，例如硬盘或固态硬盘。 云应用也可以使用块存储，但存储对于实例来说是本地的，并且设计应该预料到实例会失败。 如果组织在将应用程序迁移到云端时没有对应用设计进行任何其他调整，那么他们应该改变状态的处理方式。

一种常见的云存储类型是对象存储，其中每个对象本质上是一个文件，但使用名称来寻址。 一般来说，存储最多只有一层层次结构（即文件夹或目录），因此将传统文件系统映射到对象可能会有问题。 因为对象不能被编辑（只能创建、读取和删除），所以对象存储对于静态内容（例如图像）来说是一个不错的选择，但对于状态来说不是一个好的选择。 许多应用假定文件可以被修改，因此这些应用将无法处理对象。

其他存储选择包括键值存储和传统事务数据库。 它们不是像文件系统那样的存储，但它们确实存储数据并作为附加服务提供。 通过有效的设计，状态可以存储在键值或数据库服务中。

云计算环境确实带来了好处，但只有重新设计关键应用才能充分利用云的特性，同时减轻云限制的影响。 云环境具有不同的故障场景，并且通常会增加网络延迟，但允许快速扩展和选择全球数据中心。 云迁移的考虑因素包括确定要迁移哪些应用以及将哪些应用程序保留在本地。

还应该仔细考虑和规划过渡过程本身，并制定退出计划，以防云应用未按预期运行。 作为规划过程的一部分，一些组织将 ADC 保留在现场作为所有应用的战略控制点，无论它们托管在何处。 最后，仔细规划云应用如何存储数据和状态。 无论您选择如何将您的应用和业务迁移到云中，请考虑引入一位经验丰富的云合作伙伴。