准备将应用迁移到云端？请先阅读本文
简介
云计算环境如今已成为IT领域的重要组成部分，越来越多的组织开始将传统的本地应用迁移到云端。但应用上云并非只是将应用移至云服务提供商的虚拟机。不同组织迁移上云的动因各不相同，但都需要考虑一些关键因素，并遵循有助于顺利完成云迁移的实践。要充分发挥云迁移的优势，应提前规划应用架构以及从本地环境向云端的过渡。
概述
云与本地部署：主要区别
云环境的运行方式与本地环境不同。这两种环境之间的某些差异显而易见，例如，计算资源由其他公司拥有和管理，而不是由企业内部拥有和管理。然而，几项最重要的差异并非源于技术。一般而言，云提供商提供的任何技术也可部署在本地。云提供的是另一种使用模式，而不是另一种技术。换言之，迁移到云提供商的优势在于计算资源的使用方式，而不在于计算资源本身。
云服务提供商必然无法复制本地环境的所有功能，例如专为本地硬件设计的数据审计合规策略。由于云组件分布在不同地理位置，云部署的延迟通常更高。云服务提供商还面临其他限制。由于服务提供商需要对不同客户采用统一标准，计算环境的定制确实存在限制。例如，很少有云服务提供商会提供罕见的特殊计算设备。
但如果企业能够在这些限制条件下运营，云提供商就能提供大多数企业难以自行实现的资源使用能力。云提供商可能在全球各地运营数据中心，让组织可以选择将计算资源部署在哪个数据中心。云提供商还可以承担固定成本，使企业只需为实际使用的资源付费。云提供商拥有大多数企业难以企及的规模经济，因此可以大力投资用于管理和自动化部署的系统。需要注意的是，这些优势都不属于技术层面；云提供商的优势在于为客户提供更多选择和更灵活的成本结构。
为了减轻这些限制并充分利用云提供商的优势，IT部门必须改变应用部署方式并调整工作流，以充分发挥云提供商的相对优势，同时避免依赖云环境中的劣势属性，例如延迟。
云迁移的驱动因素
节省成本通常被视为迁移到云端的主要驱动因素，但实际原因往往更为复杂。大多数动因可归为三类：确定性、生产力和敏捷性。
公有云提供商将技术打包，使其更易于使用，从而提高确定性，并承担部分IT运营风险。由于提供商负责维护基础设施并承担相关责任，组织无需再为这些问题分心。同样，云提供商通常会提供用于深入了解IT运营情况的工具，从而提高可见性。由于公有云成本通常取决于使用量，组织可以更紧密地将应用的收益（如收入）与其运营成本关联起来。应用使用量增加时，成本会随之上升，但收益也会增加。将资本性支出转为运营支出后，组织在制定采购决策时，无需为未来增长预留过多空间。由云提供商统一管理这些不确定性，可以带来可衡量的收益。
采用公有云的另一个原因是可以提高工作效率。云提供商提供的协作和自动化工具在市场上较为先进。此外，无需管理基础设施，IT人员便可专注于支持业务战略的工作；而且，简化后的运维可随时随地进行管理，有助于提高IT人员的工作效率。
采用公有云的最后一个理由或许最具吸引力：敏捷性。云提供商营造出可随时使用近乎无限资源的体验，因此，业务推进的速度和方向不再受IT资源配置限制。资源可在数秒或数分钟内部署。项目可在短期内使用复杂的计算环境，项目结束时无需考虑停用硬件。应用可快速部署、扩缩和移除，无需顾虑硬件资产。
云迁移的障碍
虽然云迁移有诸多优势，但迁移工作也面临一些挑战。迁移前、迁移期间和迁移后各阶段的障碍和风险各不相同。提前应对这些障碍和风险，有助于提高迁移成功的可能性。
迁移前的规划可能是迁移过程中最关键的环节。如果未能重新设计应用架构以充分利用云功能，迁移工作可能会失败。此时也适合全面评估应用的复杂性，并着手加以管理。IT培训也应在迁移工作开始时开展。云部署往往会导致执行孤立和工具泛滥，而在早期阶段做好规划有助于让迁移过程更加顺畅。
将应用迁移到云端通常比最初计划耗时更长，也更为复杂。为尽量减少问题，建议先迁移一个规模较小且相对独立的应用，以尽可能降低所遇问题的影响。首次迁移小型应用时积累的经验可用于后续迁移。
迁移完成后，迁移带来的长期问题会逐渐显现。由于云环境中的安全边界通常更难界定，可能会引发安全和合规方面的担忧。如果新旧系统不仅处于不同环境，而且是在不同的开发文化下构建的，旧系统的支持工作可能会更加困难。一些组织对云锁定表示担忧，尤其是在容器日益普及的背景下。最后，预算也可能成为问题，因为每季度的可变云成本可能难以预测。
如何选择要迁移的应用
评估应用的一种方法是使用成熟度与部署位置矩阵。审视各个应用，确定所需的成熟度。能够形成差异化竞争优势或面向细分领域的应用，可能更适合部署在本地。另一方面，低成本或具备成本领先优势的应用（尤其是变更成本较低的应用）通常很适合部署在云环境中。可扩展性也是需要考虑的因素。假设一个新应用已经部署，最终负载可能会扩展到当前的100倍。为了满足本地部署的增长需求，基础设施需要大幅超额配置，从而因资源闲置而产生额外的资本成本。但如果将同一应用部署在云环境中，成本会随业务增长而增加，无需超额配置。
在决定将哪些应用迁移到云环境时，网络问题也可能是考虑因素。如果某个应用有大量分布式用户，例如覆盖范围广泛的经销商网络，或数量众多的远程电子邮件用户，那么本地部署会将所有这些流量汇聚到数据中心。由于这些流量本来就需要通过互联网传输，因此这些应用对延迟并不敏感。将此类应用部署到云环境后，网络延迟不会发生变化，但可以释放本地数据中心原本会被分布式用户占用的带宽。
与此同时，也有理由将部分应用保留在本地。对于剩余生命周期较短的应用，迁移带来的风险和成本可能并不值得承担。有些应用依赖低网络延迟和存储速度，在云环境中的性能可能会大幅下降。合规性和安全问题也往往是将应用保留在本地的原因。某些审计程序需要通过物理方式访问系统和数据以验证数据，另一些则要求应用和操作系统在裸机上运行（即不能在虚拟机上运行）。随着时间的推移，合规程序将逐步适应云环境，但目前在许多情况下尚未实现。与其将应用迁移到云端并承担无法通过合规审计的风险，现阶段将这些敏感应用保留在本地可能更为合理。有些应用需要支持旧有系统和流程，因此无法切实可行地重新设计架构以在云端运行。这些应用也可以考虑继续保留在本地。基于这些原因，与更适合云环境的应用相比，部分应用的迁移优先级应当更低。
更适合保留在本地的应用
- 生命周期较短的应用
- 需要低延迟的应用
- 存在合规问题的应用
- 支持旧版系统的应用
过渡注意事项
许多组织在迁移过程中都必须克服各种挑战。其中一个需要解决的主要问题是：如何执行实际切换？一种方法是，在云应用经过全面测试之前，使用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 Application Connector，一组领域专家即可管理所有应用，无论这些应用位于何处。通过使用现有的BIG-IP®硬件或软件设备，组织可以在任何应用前部署完整的高级应用服务，无论应用位于何处，从而为所有应用提供一个由同一组领域专家管理的战略控制点。此外，Application Connector通过消除所有可见的公共IP地址来增强安全性，从而缩小攻击面。加密密钥集中存储，而不是存储在云实例中，因此组织可以确信其关键加密信息仍受到保密。最后，Application Connector支持代理实例自动发现新的工作负载节点，从而提高云部署效率。
慎重考虑存储方案
本地应用与云应用之间的一大区别在于应用状态的存储方式。绝大多数本地应用设计都使用本地块存储，例如硬盘或固态硬盘。云应用也可以使用块存储，但此类存储位于实例本地，因此在设计时应预期实例可能发生故障。如果组织将应用迁移到云端时不打算调整应用设计的其他方面，至少应改变状态的处理方式。
一种常见的云存储类型是对象存储，其中每个对象本质上都是一个文件，但通过名称进行寻址。通常，这种存储最多只有一个层级（即文件夹或目录），因此将传统文件系统映射到对象可能会遇到问题。由于对象无法编辑，只能创建、读取和删除，因此对象存储适合存放图像等静态内容，但不适合存储状态。许多应用都假定文件可以修改，因此无法使用对象存储。
其他存储选项包括键值存储和传统事务型数据库。它们并非文件系统式的存储，但确实可以存储数据，并作为附加服务提供。通过合理设计，可以将状态存储在键值存储服务或数据库服务中。
要点：迁移前做好准备
云计算环境可以带来诸多优势，但前提是重新设计关键应用的架构，以充分利用云功能，同时减轻云环境局限性带来的影响。云环境的故障场景有所不同，网络延迟通常也更高，但可以快速扩展，并可在全球范围内选择数据中心。规划云迁移时，需要确定哪些应用应迁移到云端，哪些应保留在本地。
迁移过程本身也需要经过周密思考和规划，并制定回退计划，以应对云应用运行不符合预期的情况。在规划过程中，一些组织会在本地保留应用交付控制器（ADC），将其作为所有应用的战略控制点，无论这些应用托管在何处。最后，应仔细规划云应用存储数据和状态的方式。无论选择以何种方式将应用和业务迁移到云端，都可以考虑与经验丰富的云合作伙伴携手推进。
发布于2017年8月16日